| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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. |
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?
- What is the rule about request/indicate/response/confirm?
= Annex N of 802.21(c) seems incompatible with ..-2008 Figure 17
- What is the purpose of MIH registration? Wouldn't pre-registration suffice?
- What about 9.2.2.1 Derivation of media independent session keys (MISKs)?
- In section 9.2.2.2, why isn't L included as a "Fixed input value"?
= Changed L to be 512 bits instead of 64 bytes so the arithmetic works.
= We should also specify that Nonce-T and Nonce-N are 32 bits
= The reason for step (b) is not clear
= We should also specify that ID strings are not zero-terminated
= Changed MISK to be MIRK
= The meaning of concatenation is not clear unless each component
has a predictable length in bits (or bytes).
- 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.
- Note section 11.4 is written without consideration of the Media-Independent
messaging.
- Should use PoA or POA consistently, and PoS or POS consistently.
- Why "MiCLSAP" but "MICSAP"? Should use 'I' or 'i' consistently.
- In Figure 11.3, it would be nicer to have MICSAP on top instead of on the side
- 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.
- Why are Annexes A and B red?
- What is the MICF/SRCF port number?
- If the term "SRC frame" is used, it should be defined somewhere. Why not
just use "MICF frame"?
- 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?
--> Shouldn't TPoA be on the right side of TPoS?
--> MN.MAC is not used
--> Are "internal" communications really helpful to understand?
==> Other diagrams use function blocks for such things
(i.e., rectangle with legend such as "Processing")
--> Need to identify various TLVs at each step
--> MSRK should NOT be chosen by SPoS, but instead chosen
by TPoS and sent to TPoA
==> ... and sent to MN also?!
==> ... or alternatively MN must know how to compute.
--> "LL Frames sent to TPoA" is not very informative. How about:
"Set up TPoA to facilitate link establishment with MN"
--> How is MNID different from MNnetworkaccessid?
- 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.
- Suggestion: what about renaming TMGW to be TPoS, etc.
==> and, K_tmgw to be K_tpos, etc.