Dear Younghwan Choi, Thank you for your reply.
Please see inline for EV> for additional comments. The absence of replies means that I agree with the proposed change. You will notice that parts of my DISCUSS ballot are not addressed completely. Regards -éric From: "y...@etri.re.kr" <y...@etri.re.kr> Date: Wednesday, 4 January 2023 at 05:00 To: Eric Vyncke <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, "draft-ietf-6lo-...@ietf.org" <draft-ietf-6lo-...@ietf.org>, "6lo-cha...@ietf.org" <6lo-cha...@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, Samita Chakrabarti <samitac.i...@gmail.com>, Carles Gomez <carle...@entel.upc.edu>, Pascal Thubert <pthub...@cisco.com> Subject: Re: Éric Vyncke's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS and COMMENT) Dear Éric Vyncke, Thanks for your comments. Please see responses inline bellows. Cheers, Younghwan Choi ----------------------------------------------- YOUNGHWAN CHOI, Ph.D. Principal Researcher, PEC, ETRI Tel +82-42-860-1429 Fax +82-42-860-5404 Email y...@etri.re.kr<mailto:y...@etri.re.kr> On Dec 12, 2022, at 7:15 PM, Éric Vyncke via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-6lo-nfc-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-6lo-nfc-19 CC @evyncke Thank you for the work put into this document. It could indeed be useful and it would deserve a high quality specification. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Carles Gomez for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. But, the write-up is incorrect about the downward reference as https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ indicates RFC 3756 is a downref... Please note that Pascal Thubert is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Pascal will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/reviewrequest/16761/ I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Tagging of references I have not checked all references, but at least RFC 3633 should not be normative but only informative. EV> Still need to get the RFC 3633 as normative though Moreover, RFC3633 is obsoleted by RFC 8415 for 4 years. Thanks for your correction. I will put “RFC8415” instead of “RFC3633" ### Section 3.4 As far as I understand the document and its relationship with NFC standards, then it is not up to the IETF to use normative language around MIUX (specified by NFC), so, the "MUST" below should rather be "is". ``` When the MIUX parameter is used, the TLV Type field MUST be 0x02 and the TLV Length field MUST be 0x02. The MIUX parameter MUST be encoded into the least significant 11 bits of the TLV Value field. The unused bits in the TLV Value field MUST be set to zero by the sender and ignored by the receiver. ``` The "MUST" in `The MIUX value MUST be 0x480 to support the IPv6 MTU requirement (of 1280 bytes).` is of course fine. Finally, please add a normative reference to RFC 8200. I will put “RFC 8200” in the next version of the draft. EV> but there is still the issue of normative language in something from NFC specification ### Section 4.2 Is this section normative ? There is no BCP14 words in it. If normative, then how is Network_ID derived from any NFC parameter? The Network_ID is derived from SSAP (NFC Link Layer address) of LLCP (NFC Logical Link Layer). I will revise the sentence, "NFC Link Layer address (i.e., SSAP) MUST a source of the Net_Iface parameter.” In the Section 4.2 ### Section 4.3 While not really a DISCUSS point, what is the link between DHCP-PD and a LLA ? Remove the part about getting a prefix. I will remove the part, "A 6LBR may obtain an IPv6 prefix for numbering the NFC network via DHCPv6 Prefix Delegation ([RFC3633])." What is a `secured and stable IID` ? Do the authors mean a 'random and stable IID'? I revise “ secured and stable IID" to “ random and stable IID”. ### Section 4.4 and 5 In section 4.4: `NFC supports mesh topologies but ...` In section 5: `An NFC link does not support a star topology or mesh network topology` So, is mesh supported or not ? NFC supports mesh topologies. I remove the hanging paragraph in Section 5 before Section 5.1. ### Section 4.5 Is this section normative ? There is no BCP14 terms. Yes It is, I will revise the sentences. OLD: The only sequence currently defined for IPv6-over-NFC is the LOWPAN_IPHC compressed IPv6 header (see Section 4.6) header followed by payload, as depicted in Figure 6. NEW: The only sequence currently defined for IPv6-over-NFC MUST be the LOWPAN_IPHC compressed IPv6 header (see Section 4.6) header followed by payload, as depicted in Figure 6 & 7. Is there a IANA registry for "Dispatch" values ? If so, then please add a reference. I will put the reference like follows: OLD: All IPv6-over-NFC encapsulated datagrams are prefixed by an encapsulation header stack consisting of a Dispatch value. NEW: Section 4.5 All IPv6-over-NFC encapsulated datagrams are prefixed by an encapsulation header stack consisting of a Dispatch value [IANA-6LoWPAN]. Section X.2. Informative References [IANA-6LoWPAN] IANA, "IPv6 Low Power Personal Area Network Parameters", <https://www.iana.org/assignments/_6lowpan-parameters>. It *seems* that the length is 1 octet, please specify the length of the value. It could be more that 1 octet according to payload. For clarification, I will revise the Figure 6 like following. OLD: The dispatch value is treated as an unstructured namespace. NEW: The dispatch value (length: 1 octet) is treated as an unstructured namespace. ### Section 4.6 Possibly due to my ignorance of RFC 6282, but this document refers to TCP (section 4.1) while RFC 6282 only compresses UDP ? I will revise the sentences like following. Section 4.1. OLD: The adaptation layer for IPv6 over NFC supports neighbor discovery, stateless address auto-configuration, header compression, and fragmentation & reassembly, based on 6LoWPAN. NEW: The adaptation layer for IPv6 over NFC supports neighbor discovery, stateless address auto-configuration, header compression, and fragmentation & reassembly, based on 6LoWPAN. Note that 6LoWPAN eader compression [RFC 6282] does not define header compression for TCP. The latter can still be supported over IPv6 over NFC, albeit without the performance optimization of header compression. EV> typo 'eader' Is `6-bit NFC link-layer` the same as the `6-bit SSAP` discussed before ? I guess so but I should not guess but be sure. EV> do not forget to address the above ### Section 4.8 Is this section normative about multicast replication ? For clarification, I will revise sentences like following. OLD: The NFC Link Layer does not support multicast. Therefore, packets are always transmitted by unicast between two NFC-enabled devices. Even in the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot do a multicast to all the connected 6LNs. If the 6LBR needs to send a multicast packet to all its 6LNs, it has to replicate the packet and unicast it on each link. NEW: The NFC Link Layer does not support multicast. Therefore, packets are always transmitted by unicast between two NFC-enabled devices. Even in the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot do a multicast to all the connected 6LNs. If the 6LBR needs to send a multicast packet to all its 6LNs, it has to replicate the packet and unicast it on each link. However, this is not energy-efficient, and the central node, which is battery-powered, must take particular care of power consumption. To further conserve power, the 6LBR MUST keep track of multicast listeners at NFC link-level granularity (not at subnet granularity), and it MUST NOT forward multicast packets to 6LNs that have not registered as listeners for multicast groups the packets belong to. In the opposite direction, a 6LN always has to send packets to or through the 6LBR. Hence, when a 6LN needs to transmit an IPv6 multicast packet, the 6LN will unicast the corresponding NFC packet to the 6LBR. ### Section 5.1 ``` Two or more 6LNs may be connected with a 6LBR, but each connection uses a different subnet. ``` Unsure whether 'subnet' means 'IPv6 prefix' or 'link' ? `the 6LBR MUST ensure address collisions do not occur` how can this goal be achieved. For clarification, I would like to revise sentences as bellowing. OLD: Section 5.1 Two or more 6LNs may be connected with a 6LBR, but each connection uses a different subnet. The 6LBR is acting as a router and forwarding packets between 6LNs and the Internet. Also, the 6LBR MUST ensure address collisions do not occur and forwards packets sent by one 6LN to another. NEW: Section 5.1 Two or more 6LNs may be connected with a 6LBR, but each connection uses a different subnet. The 6LBR is acting as a router and forwarding packets between 6LNs and the Internet. Also, the 6LBR MUST ensure address collisions do not occur because the 6LNs are connected to the 6LBR like a start topology, so the 6LBR checks whether IPv6 addresses are duplicate or not, since 6LNs need to register their addresses with the 6LBR. Section 5.2 (Also, I will put a following new sentence just after Figure 11 in Section 5.2) In multihop (i.e., more complex) topologies, the 6LR can also do the same task, but then Duplicate Address Detection (DAD) requires the extensions for multihop networks such as the ones in [RFC 6775]. EV> the 'subnet' term is still ambiguous ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS ### Shepherd write-up The write-up is incorrect about the downward reference as https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ indicates RFC 3756 is a downref... Unsure whether this reference to RFC 3756 should be normative though. I will move the reference [RFC 3756] from the section of normative reference to the section of informative reference. ### IEEE 802.15.4 Should there be an informative reference to IEEE Std 802.15.4 ? I will put the new reference, [IEEE Std 802.15.4] in the section of informative reference. ### Section 1 `NFC is often regarded as a secure communications technology, due to its very short transmission range.` More explanations or even a reference would be welcome. OLD: NFC is often regarded as a secure communications technology, due to its very short transmission range. NEW: NFC has its very short transmission range of 10 cm or less, so the other hidden NFC devices behind outside the range cannot receive NFC signals. Therefore, NFC often regarded as a secure communications technology. EV> I will let the security AD comment on this part ### Section 3.2 Should 'reliable' be qualified ? E.g., does it mean no packet loss ? NFC LLCP-1.4 provides connection-oriented communications by itself, so For network layer, it can be reliable. EV> 'reliable' is still rather vague as a term ``` The LLCP to IPv6 protocol binding MUST transfer the Source Service Access Point (SSAP) and Destination Service Access Point (DSAP) value to the IPv6 over NFC protocol. ``` Should this be "to the IPv6 over NFS adaptation later" ? You’re right. I will revise that. NEW: The LLCP to IPv6 protocol binding MUST transfer the Source Service Access Point (SSAP) and Destination Service Access Point (DSAP) value to the IPv6 over NFC adaptation layer. ### Section 4.4 There is text for "For sending Router Solicitations and processing Router Advertisements" but what about "receiving RS and sending RA" ? I agree with your comment. NEW: For receiving Router Solicitations and sending Router Advertisements, the NFC 6LNs MUST follow Sections 5.3 and 5.4 of [RFC6775]. ## NITS ### kbit/s or kbps Select one unit and keep using it rather than changing during the document. I will use ‘kbps’ only in the document. ### Hexadecimal presentation Most IETF drafts use 0x3f rather than 3Fh (really cosmetic). Section 3.4 uses 0x02. Suggest to be consistent. I will revise that with “0x3f” in section 3.3. OLD: In addition, address values between 20h and 3Fh are assigned by the local LLC as a result of an upper layer service request. Therefore, the address values between 20h and 3Fh can be used for generating IPv6 interface identifiers. NEW: In addition, address values between 0x2 and 0x3f are assigned by the local LLC as a result of an upper layer service request. Therefore, the address values between 0x2 and 0x3f can be used for generating IPv6 interface identifiers. ### Section 4.2 I do not see the value of figure 2. Consider removing it. Do you mean figure 2 in Section 3.4 (NOT Section 4.2)? If so and I have a choice whether removing it or not, I prefer to NOT removing the Figure 2. There have been a lot of discussions about it from the begining. The Figure 2 was removed in some versions of this draft because of comments from reviewers. However, much more reviewers want to put it back for better understanding. It depicts example for MIUX, I believe the example is useful for better understating NFC characteristics. EV> Sorry, my bad, I meant figure 4 ### Section 4.3 Please use RFC 5952 for IPv6 address format. EV> not really, simple s/FE80::/fe80::/ 😊 Do you mean change the Figure 5 like following? OLD: 0 0 0 1 0 1 6 2 0 0 4 7 +----------+------------------+----------------------------+ |1111111010| zeros | Interface Identifier | +----------+------------------+----------------------------+ . . . <- - - - - - - - - - - 128 bits - - - - - - - - - - - -> . . . NEW: 0 0 1 0 6 2 0 4 7 +-----------------------------+----------------------------+ | 0xfe80 | Interface Identifier | +-----------------------------+----------------------------+ Many thanks for your a lot of comments. It helps a lot. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
