Re: [STDS-802-21] Some questions about 802.21c document
Hi Charles,
some comments on top of Yoshihiro ones.
BR
Antonio
On Fri, Aug 24, 2012 at 10:22 AM, Yoshihiro Ohba
<yoshihiro.ohba@xxxxxxxxxxxxx> wrote:
> I revised my answer in the attached file.
>
> Yoshihiro Ohba
>
> (2012/08/24 3:55), Charles E. Perkins wrote:
>>
>> Hello folks,
>>
>> While revising the document, I have compiled the following list of
>> questions along with a few notes about various editorial changes
>> I have made.
>>
>> Your comments will be greatly appreciated. I really need to
>> have some reality check as I go along, and many things are
>> not really very clear to me.
>>
>> I will post later today an intermediate version with my revisions
>> on a public website and send a URL. The intermediate version
>> is not guaranteed to be in a consistent state. My next task will
>> be to fix up some of the diagrams, but to do that I need to
>> install Visio which will take me a little while (even it is actually
>> possible, which I have not verified).
>>
>> Regards,
>> Charlie P.
>>
>
--
Antonio de la Oliva
Visiting Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749
Questions about 802.21-2008 etc.
- 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 ?gBinary Encoding Rule?h 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.
- 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.
- 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.
- In section 9.2.2.2, why isn't L included as a "Fixed input value"?
[YO] I think L should be included as a "Fixed input value".
= Changed L to be 512 bits instead of 64 bytes so the arithmetic works.
[YO] Agreed.
= 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
= 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?
- In section 11, the term "target radio" refers to a radio on the MN. This
will be confusing if people preconceive the "target radio"
to be part of the target PoA.
[YO] Agreed.
- 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.
- Why "MiCLSAP" but "MICSAP"? Should use 'I' or 'i' consistently.
[YO] Agreed.
- In Figure 11.3, it would be nicer to have MICSAP on top instead of on the side
[YO] It's up to Editor.
[AO] I also think is better
- Sections 11.4.{5-7} seem very repetitive, and basically just say that the MN
can communicate with remote SRCFs if the IP address is known, and shows
various representations of the encapsulation. I'm pretty sure this
is largely unnecessary.
[YO] I fully agree with you that most of these sections are not necessary.
[AO] Agree,
- Why are Annexes A and B red?
[AO] I think this is inherited from a previous version highlighting changes. Just turn them black..
- 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?
- If the term "SRC frame" is used, it should be defined somewhere. Why not
just use "MICF frame"?
[YO] Agreed.
- The terminology in section 11.6.1 should be made to be consistent with the
terminology in the TLVs listed for the MIH_LL_Transfer et al.
message names. I am continuing to do this.
- I have tried to italicize most of the single-character variable names,
but I don't think any of the subscripts should be italicized
- 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)..
--> Shouldn't TPoA be on the right side of TPoS?
[YO] I am ok with either way.
[AO] I am also ok
--> 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
--> 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.
--> 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?
==> ... 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.
--> "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"?
--> 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.
- 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?
- Suggestion: what about renaming TMGW to be TPoS, etc.
==> and, K_tmgw to be K_tpos, etc.
[YO] Agreed.