Dear Éric Vyncke, I appreciate for your DISCUSS and COMMENT points. I believe my draft, IPv6-over-NFC has been much more mature thanks to all of the IESG review.
I am going to update the draft as soon as the last review from TSVART is finished. I guess it will be done at the beginning of the next week. Best regards Younghwan Choi ----------------------------------------------- YOUNGHWAN CHOI, Ph.D.Principal Researcher, PEC, ETRITel +82-42-860-1429 Fax +82-42-860-5404 Email y...@etri.re.kr mailto:y...@etri.re.kr -----Original Message----- From: "Eric Vyncke (evyncke)" <evyn...@cisco.com> To: "y...@etri.re.kr" <y...@etri.re.kr>; 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 (pthubert)" <pthub...@cisco.com>; Sent: 2023-01-05 (목) 16:00:31 (UTC+09:00) Subject: Re: Éric Vyncke's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS and COMMENT) It seems that all your newly proposed changes will address my DISCUSS and COMMENT points. I will clear my DISCUSS ballot as soon as a revised I-D with the changes is uploaded. Regards and thanks again for your work, -éric From: "y...@etri.re.kr" <y...@etri.re.kr>Date: Thursday, 5 January 2023 at 06:07To: 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, Many thanks for you quick response. Please find my answers bellow: Best regards, Younghwan Choi On Jan 4, 2023, at 6:38 PM, Eric Vyncke (evyncke) <evyn...@cisco.com mailto:evyn...@cisco.com> wrote: 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 mailto:y...@etri.re.kr"; <y...@etri.re.kr mailto:y...@etri.re.kr>Date: Wednesday, 4 January 2023 at 05:00To: Eric Vyncke <evyn...@cisco.com mailto:evyn...@cisco.com>Cc: The IESG <i...@ietf.org mailto:i...@ietf.org>, "draft-ietf-6lo-...@ietf.org mailto:draft-ietf-6lo-...@ietf.org"; <draft-ietf-6lo-...@ietf.org mailto:draft-ietf-6lo-...@ietf.org>, "6lo-cha...@ietf.org mailto:6lo-cha...@ietf.org"; <6lo-cha...@ietf.org mailto:6lo-cha...@ietf.org>, "6lo@ietf.org mailto:6lo@ietf.org"; <6lo@ietf.org mailto:6lo@ietf.org>, Samita Chakrabarti <samitac.i...@gmail.com mailto:samitac.i...@gmail.com>, Carles Gomez <carle...@entel.upc.edu mailto:carle...@entel.upc.edu>, Pascal Thubert <pthub...@cisco.com mailto: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, ETRITel +82-42-860-1429 Fax +82-42-860-5404Email 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 fordraft-ietf-6lo-nfc-19: DiscussWhen responding, please keep the subject line intact and reply to allemail addresses included in the To and CC lines. (Feel free to cut thisintroductory paragraph, however.)Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 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/ https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/----------------------------------------------------------------------DISCUSS:----------------------------------------------------------------------# Éric Vyncke, INT AD, comments for draft-ietf-6lo-nfc-19CC @evynckeThank you for the work put into this document. It could indeed be useful and itwould deserve a high quality specification.Please find below one blocking DISCUSS points (easy to address), somenon-blocking COMMENT points (but replies would be appreciated even if only formy own education), and some nits.Special thanks to Carles Gomez for the shepherd's detailed write-up includingthe WG consensus *and* the justification of the intended status. But, thewrite-up is incorrect about the downward reference ashttps://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ indicates RFC3756 is a downref...Please note that Pascal Thubert is the Internet directorate reviewer (at myrequest) and you may want to consider this int-dir reviews as well when Pascalwill complete the review (no need to wait for it though):https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/reviewrequest/16761/ https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/reviewrequest/16761/I hope that this review helps to improve the document,Regards,-éric## DISCUSSAs noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/ https://www.ietf.org/blog/handling-iesg-ballot-positions/, aDISCUSS ballot is a request to have a discussion on the following topics:### Tagging of referencesI have not checked all references, but at least RFC 3633 should not benormative but only informative. EV> Still need to get the RFC 3633 as normative though I will remove the reference [RFC 3633] from the section of normative reference, and I will put the reference [RFC 8415] in the section of informative reference as well. Moreover, RFC3633 is obsoleted by RFC 8415 for 4 years. Thanks for your correction. I will put “RFC8415” instead of “RFC3633" ### Section 3.4As 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 (specifiedby NFC), so, the "MUST" below should rather be "is". ```When the MIUX parameter is used, the TLV Type field MUST be 0x02 andthe TLV Length field MUST be 0x02. The MIUX parameter MUST beencoded 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 thesender 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 I will revise your comment as follow: OLD: 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. NEW: When the MIUX parameter is used, the TLV Type field is 0x02 and the TLV Length field is 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 is set to zero by the sender and ignored by the receiver. ### Section 4.2Is 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.3While 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 stableIID'? I revise “ secured and stable IID" to “ random and stable IID”. ### Section 4.4 and 5In section 4.4: `NFC supports mesh topologies but ...`In section 5: `An NFC link does not support a star topology or mesh networktopology`So, is mesh supported or not ? NFC supports mesh topologies. I remove the hanging paragraph in Section 5 before Section 5.1. ### Section 4.5Is 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 areference. 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 https://www.iana.org/assignments/_6lowpan-parameters>. It *seems* that the length is 1 octet, please specify the length ofthe 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.6Possibly 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' Thanks. I will fix the typo, ‘header’ in the sentence. Is `6-bit NFC link-layer` the same as the `6-bit SSAP` discussed before ? Iguess so but I should not guess but be sure. EV> do not forget to address the above Yes, I will not forget it. ### Section 4.8Is 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 connectionuses a different subnet.```Unsure whether 'subnet' means 'IPv6 prefix' or 'link' ?`the 6LBR MUST ensure address collisions do not occur` how can this goal beachieved. 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 NEW: (I put “IPv6 prefix instead of “subnet”) Section 5. Two or more 6LNs may be connected with a 6LBR, but each connection uses a different IPv6 prefix. 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]. ----------------------------------------------------------------------COMMENT:----------------------------------------------------------------------## COMMENTS### Shepherd write-upThe write-up is incorrect about the downward reference ashttps://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ indicates RFC3756 is a downref... Unsure whether this reference to RFC 3756 should benormative though. I will move the reference [RFC 3756] from the section of normative reference to the section of informative reference. ### IEEE 802.15.4Should 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 veryshort transmission range.` More explanations or even a reference would bewelcome. 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 Thanks. ### Section 3.2Should '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 I will change “reliable” with "guaranteed delivery”. What about this? ```The LLCP to IPv6 protocolbinding MUST transfer the Source Service Access Point (SSAP) andDestination Service Access Point (DSAP) value to the IPv6 over NFCprotocol.```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.4There is text for "For sending Router Solicitations and processing RouterAdvertisements" 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 kbpsSelect one unit and keep using it rather than changing during the document. I will use ‘kbps’ only in the document. ### Hexadecimal presentationMost IETF drafts use 0x3f rather than 3Fh (really cosmetic). Section 3.4 uses0x02. 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.2I 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 I agree with you. I will remove Figure 4. ### Section 4.3Please use RFC 5952 for IPv6 address format. EV> not really, simple s/FE80::/fe80::/ 😊 Thanks. I will use "fe80::/64” in the sentence. 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. ## NotesThis review is in the ["IETF Comments" Markdown format][ICMF], You can use the[`ietf-comments` tool][ICT] to automatically convert this review intoindividual GitHub issues.[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md https://github.com/mnot/ietf-comments/blob/main/format.md[ICT]: https://github.com/mnot/ietf-comments https://github.com/mnot/ietf-comments
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
