Hello Alexey and all, Thanks for your valuable reviews. Please find my answers inline.
BRs, Younghwan Choi > -----Original Message----- > From: Alexey Melnikov via Datatracker <[email protected]> > Sent: Thursday, March 14, 2019 5:22 AM > To: The IESG <[email protected]> > Cc: [email protected]; Carles Gomez > <[email protected]>; Samita Chakrabarti <[email protected]>; > [email protected]; [email protected]; [email protected] > Subject: Alexey Melnikov's No Objection on draft-ietf-6lo-nfc-13: > (with > COMMENT) > > Alexey Melnikov has entered the following ballot position for > draft-ietf-6lo-nfc-13: No Objection > > 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Benjamin about antenna size. Despite that I have enjoyed > reading this document. I have some questions/comments that I would > like to discuss before recommending publication of this document as an RFC: Thanks. Please refer to the answers about Benjamin's DISCUSS (about antenna). > > In 3.2: > > The LLCP consists of Logical Link Control (LLC) and MAC Mapping. The > MAC Mapping integrates an existing RF protocol into the LLCP > architecture. The LLC contains three components, such as Link > Management, Connection-oriented Transmission, and Connection-less > Transmission. The Link Management component is responsible for > serializing all connection-oriented and connection-less LLC PDU > (Protocol Data Unit) exchanges and for aggregation and disaggregation > of small PDUs. This component also guarantees asynchronous balanced > mode communication and provides link status supervision by performing > the symmetry procedure. > > Can you translate the last sentence for somebody who is not an expert > in this? > Agreed with your point. I think the last sentence, "This component also guarantees asynchronous balanced [...] the symmetry procedure.", is not really helpful for understanding IPv6 over NFC. I would rather get rid of this last sentence. Thanks for your comment. > In 4.4: > > The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC > network is can be accomplished via DHCPv6 Prefix Delegation > > I think "is" before "can be" should be deleted above. Thanks a lot. I will fix it. > > ([RFC3633]). > > In 4.5: > > o When two or more NFC 6LNs(or 6LRs) meet, there are two cases. One > is that three or more NFC devices are linked with multi-hop > connections, and the other is that they meet within a single hop > range (e.g., isolated network). In a case of multi-hops, all of > 6LNs, which have two or more connections with different neighbors, > MAY be a router for 6LR/6LBR. In a case that they meet within a > single hop and they have the same properties, any of them can be a > router. When the NFC nodes are not of uniform category (e.g., > different MTU, level of remaining energy, connectivity, etc.), a > performance-outstanding device can become a router. > > The last sentence: how can 2 NFC nodes figure out which one has higher > level or remaining energy, etc? Benjamin also pointed out this. I agree with his opinion. I am going to remove the sentence, " When the NFC nodes are not [...] performance-outstanding device can become a router.". > > In 4.7: > > Therefore, IPv6 header compression in [RFC6282] MUST be implemented. > Further, implementations MAY also support Generic Header Compression > (GHC) of [RFC7400]. > > Will 2 NFC implementations interoperate if one of them supports GHC > and the other one doesn't? If they can't, then "MAY" seems to be too weak > here. I will change it with "MUST". > > In 4.8: > > IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is > NOT RECOMMENDED in this document as discussed in Section 3.4. > > You are using "NOT RECOMMENDED", which is "SHOULD NOT". Why is this > not a "MUST NOT" and why implementation of FAR would be Ok if one node > supports it and another one doesn't? > Agreed. I will change it with "MUST NOT". _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
