Re: [6lo] Shepherd's comments on draft-ietf-6lo-nfc-09

[최영환 <[e-mail]>]

Dear Samita,

Thanks a lot for your comments.
I’m going to reflect your comments on the draft (-10), and publish it.
See you in Montreal (QC).

BRs,
Younghwan Choi

From: Samita Chakrabarti <[e-mail]>
Sent: Monday, July 9, 2018 12:42 PM
To: 최영환 <[e-mail]>; lo <[e-mail]>; Gabriel Montenegro <[e-mail]>
Cc: [e-mail]
Subject: Shepherd's comments on draft-ietf-6lo-nfc-09

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.