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: 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? 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. ([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? 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. 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? _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
