Hi Younghawn:
I have volunteered to take over the shepherding job for this document.
Here are my comments:
Please update -10 with these comments. Let me know if you have any further
questions. Though the -09 draft might expire before the submission gate
opens in the IETF week, I believe you should not have issues to submit
version 10.
Let the chairs know if you do have issues for submission of the next
revision.
Thanks,
-Samita
[CC at my work email for quick attention ]
--------------------------Comments------------------------------------------------
Section 3.2: 2nd para: "an IPv6 packet SHALL be" -- why SHALL? if this is
the mandate this document
requires for implementing the draft -- SHALL should be
replaced by "MUST"
Section 3.4: Typo in the first line - s /an IPv6 packet SHALL passed down/
an IPv6 packet MUST be passed down/
Please refer to RFC 2119 for when to use MUST, SHOULD and MAY
Please check all SHALL references in this section (3.4) and
throughout the document to
appropriately mandate them as per RFC 2119 [i,e if these are
specificed in this document for
the first time].
Comment: Use this text for clarification --
'default MTU value is 128 bytes when no MIUX parameter is
transmitted by the NFC LLC layer'.
CURRENT TEXT:
Otherwise, the MTU size in NFC LLCP SHALL calculate the MIU
value as follows:
MIU = 128 + MIUX.
When the MIUX parameter is encoded as a TLV, the TLV Type
field SHALL
be 0x02 and the TLV Length field SHALL be 0x02. The MIUX
parameter
SHALL be encoded into the least significant 11 bits of the
TLV Value
field. The unused bits in the TLV Value field SHALL be set
to zero
by the sender and SHALL be ignored by the receiver.
However, a
maximum value of the TLV Value field can be 0x7FF, and a
maximum size
of the MTU in NFC LLCP is 2176 bytes.
Samita's Comments:
Otherwise, the MTU size in NFC LLCP SHOULD be calculated from
the MIU value as follows: [ is this correct? Not clear from the draft what
is the relationship mapping between MTU and MIU - please clarify]
MIU = 128 + MIUX.
1) Clarify length of type and len fields. From the value
example (0x02), it appears
that they are both 1 byte fields. THus the 0x02 value in
len field means the value
length is always 2 bytes. Is this what is meant?
2) Please replace the SHALL to SHOULD or MUST appropriately
and then provide a min value
and MAX val (0x7FF). Calculate the breakdown of MTU size
of NFC LLCP(2176 bytes) - does
it include the 128 byte default value of MIU?
Section 4.2:
The last parapgraph in this section and section 4.8 seem to
indicate that this docuemnt
recommends no FAR over NFC link for simplicity and thus
defines a MIUX extension to avoid
any fragmentation and reassembly. But the text is very
ambiguous - this will surely create
interoperability problem.
I would suggest clarify the 3rd paragraph in section 4.2 and
also clarify section 4.8 that at
the time of writing this document does NOT RECOMMEND using
FAR over NFC link due to
simplicity of the protocol and implementation and the
implementation for this specification
SHOULD (MUST?) use MIUX extension to communicate the MTU of
the link to the peer as defined
in section 4.2
Section 4.5:
Comment-1.
Current text:
Unless they are the same (e.g., different MTU, level of
remaining energy,
connectivity, etc.)
Suggested text: When the NFC nodes are not of uniform
category (e.g., different MTU, level of remaining energy,
connectivity, etc.)...
Comment-2.
Current Text:
Also, they MAY deliver their own information (e.g., MTU
and energy level, etc.) to neighbors with NFC LLCP
protocols
during connection initialization
Suggested Text ( with mandatory requirment for avoiding
FAR):
Also, they MUST deliver their MTU information to neighbors
with NFC LLCP protocols
during connection initialization. The router MAY also
communicate other capabilities
which is out of scope of this document.
Comment 3.
Suggestion: Please check with RFC6775-update latest ( and
Pascal) to make sure that the update
supoorts the NFC draft which is classic RFC 6775 compatible.
Section 4.8:
Re-word (if applicable) based on the comments above for
section 4.2
Section 4.10: Does this mapping represent the link-layer
address part (IID) of IPv6 address?
It is not clear. Please provide an example of a
full IPv6 multicast address
when NFC LLC is used.
Section 7:
Please comment about connecting the NFC device over the
Internet. Because of 6bit IID value
the threat for man in the middle attack is multiplied.
Thus the document should caution
about that and recommend using it only over a secured
tunnel or other security mechanism.
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
