Hello Antonio and Yoshi,
Thanks very much for your answers. I have made some follow-up
below, prefaced by "[CP]". Very soon, I will send another email about
the revised figure.
- Why is the packet specification repeated between "primitives"
and protocol messages?
= Wouldn't the protocol message specification alone be sufficient?
[YO] There is no packet specification in primitives. Primitives define
parameters but without assuming a specific encoding format. Parameters
carried in MIH protocol messages are encoded using the 'Binary
Encoding Rule' defined in Table F.1 of 802.21-2008.
Also, some parameters that are carried in an MIH message but are not
passed from/to MIH user are not listed in primitives.
[AO] That is the reason that for example in all protocol messages
there is a destination and source, while in primitives in general
there is no source and destination fields.
- What is the rule about request/indicate/response/confirm?
= Annex N of 802.21(c) seems incompatible with ..-2008 Figure 17
[YO] The rule on use of ES primitives are described in Figure 14. The
rule on use of CS pritmives are described in Figure 17. The rule
on use of IS pritmives are described in Figure 20. I could not
find a similar figure that explains the rule for service management
primitves. We first need to determine which service (command service
or service management service?) the MIH_LL_Transfer and
MIH_N2N_LL_Transfer primitives used in Annex N of 802.21(c) belong to.
If these primitives belong to CS, then I think Annex N of 802.21(c)
compatible with Figure 17 of 802.21-2008.
[AO] I have also cross-checked the figures in Annex N and I agree with
Yoshihiro, they are inline with Figure 17 assuming they are CS.
[CP] I must study this. It has never been clear to me. I do understand
that both layer-3 and layer-2 transports must be supported. Thanks
for your patient explanations!
- What is the purpose of MIH registration? Wouldn't pre-registration
suffice?
[YO] Please see 6.2.4 of 802.21-2008. Pre-registration and MIH
registration
are different things.
[CP] I will do so. I can well imagine that MIH registration should not
be mandatory in all cases.
- What about 9.2.2.1 Derivation of media independent session keys
(MISKs)?
[YO] Actual text for 9.2.2.1 is described in 802.21a-2012.
[CP] I must have an outdated version of 802.21a. I'll go look for the
above
version.
= We should also specify that Nonce-T and Nonce-N are 32 bits
[YO] Why does a Nonce need to have a fixed length of 32 bits?
[AO] In .21a there are nonces of 104 bits, just as information
[CP] The Nonces don't have to be 32 bits, but the length has to be
specified so that the concatenation formulas are well-formed.
= The reason for step (b) is not clear
[YO] I think the inequation n > 2v -1 in step (b) is wrong. It sould
be n > 2**v - 1.
= We should also specify that ID strings are not zero-terminated
[YO] Agreed.
= Changed MISK to be MIRK
[YO] Agreed.
= The meaning of concatenation is not clear unless each component
has a predictable length in bits (or bytes).
[YO] Which component has a non-predictable length?
[CP] I was looking at the nonces in the formulas in 9.2.2.2 and 16.6.1.
- Note section 11.4 is written without consideration of the
Media-Independent
messaging.
- Should use PoA or POA consistently, and PoS or POS consistently.
[YO] Agreed, and it should PoA and PoS.
[AO] Not sure what you mean regarding section 11, it seems the MICF
is there
so the media independent messaging is included. The main problem is
that the terminology is not consistent with .21. Agree on PoA and PoS.
[CP] I'll come back later to the point about the inconsistency, and I
have
to think about it some more anyway, and it isn't something that needs to
be fixed immediately.
- What is the MICF/SRCF port number?
[YO] It's 4551. (cf: RFC 5677)
[AO] But only if the standard .21 protocol is use, is not it Yoshihiro?
If the protocol is changed (e.g., header change) this number will
probably change, is not it?
[CP] We can use the same port number if we make different message type
numbers
and leave the existing formats for the existing message types.
- In Figure N.6.1:
--> How to get the caption to actually read N.6.1?
[AO] I would not loose much time on this, at the end everything has to
be moved to other program (not word)..
[CP] I thought that Subir had discovered we could use Microsoft Word.
But also I think that Lucy has volunteered to do a one-time conversion
to Frame, or else a one-time conversion from Frame to Microsoft Word.
I would pick the latter.
--> MN.MAC is not used
[YO] You are right. Some internal communications between MN.MAC and
MN.MIH_user may need to be added.
[AO] In some of the figures it is used, see the last arrow of figure
in page 52 as an example
[CP] Agreed – I’ll keep it.
--> Are "internal" communications really helpful to understand?
==> Other diagrams use function blocks for such things
(i.e., rectangle with legend such as "Processing")
[YO] I think so.
[CP] I think you mean to keep the internal communications, right?
--> Need to identify various TLVs at each step
--> MSRK should NOT be chosen by SPoS, but instead chosen
by TPoS and sent to TPoA
[YO] I don't understand this. How TPoA can compute MSRK prior to
establishing a key hierarchy with MN?
[CP] Well, it could use a simple formula but it would depend on the
particular layer-2 requirement for MSRK, as I understand it.
==> ... and sent to MN also?!
==> ... or alternatively MN must know how to compute.
[YO] If EAP-based authentication is used for MIH service access
authentication between MN and SPoS, then MSRK is computed using
the algorithm defined in 10.2.1.1 of 802.21a-2012.
[CP] Check. I need to study that, as mentioned elsewhere.
--> "LL Frames sent to TPoA" is not very informative. How about:
"Set up TPoA to facilitate link establishment with MN"
[YO] The suggested text looks confusing. How about this: "LL frames are
sent to TPoA to establish a link between MN and TPoA"?
[CP] O.K. But doesn't this also include installing MSRK?
--> How is MNID different from MNnetworkaccessid?
[YO] It is explained in Annex P. MNnetworkaccessid is used for
media-specific authentication. MNID is MIHF-ID of MN and used by the
MIH protocol. The two IDs are different regardless of whether the
MN can directly contact TPoS or not.
[CP] Likewise, I need to review this...
- Note that MN can directly contact TPoS even if TPoS is not the same
as SPoS
It could be that MN was recently in contact with TPoS and has all
the necessary security association, and so forth.
- Suggestion: "MIHF_spos" might be better than "SPoS's MIHF", etc.
[YO] Which part are you referring to?
[CP] Actually, this was my own text in the numbered list below the
"Figure N.6.1". But anyway I hope the way of referring to the
various MIH functions using nodal subscripts will be considered
more concise and clearer.
- Suggestion: what about renaming TMGW to be TPoS, etc.
==> and, K_tmgw to be K_tpos, etc.
[YO] Agreed.
[CP] Thanks! I will do this unless anyone has an objection.