Dear all, I will fix on of my answers like follow:
>>> >>> ### 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 >> > 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 is 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. I should have fixed all of “MJUST” with “is”, but one “MUST” was remaining. Thanks. Best regards, Younghwan > On Jan 5, 2023, at 2:06 PM, y...@etri.re.kr wrote: > > 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:00 >> To: 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, 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/ >>> >>> <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-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/ >>> <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/ >>> <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/ >>> <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 > > 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.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 >> > > 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.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 >> <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' > > 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 ? I >>> guess 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.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 > > 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-up >>> >>> The write-up is incorrect about the downward reference as >>> https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ >>> <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 > > Thanks. > >>> ### 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 > > I will change “reliable” with "guaranteed delivery”. What about this? > >>> >>> ``` >>> 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 >> > > I agree with you. I will remove Figure 4. > >> >>> >>> ### Section 4.3 >>> >>> Please 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. >> >>> >>> ## 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 >>> <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
