Warren Kumari has entered the following ballot position for draft-ietf-6lo-rfc6775-update-16: 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-rfc6775-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a very readable document - this is not a simple process, but the document was clear and understandable. Also, thank you for addressing Jürgen Schönwälder's OpsDir comments (I have not personally checked that each was incorporated, but the authors said that they would, and I'm trusting them). Issues: "In IPv6 ND [RFC4861], a router needs enough storage to hold NCEs for all the addresses to which it can currently forward packets." -- I do not believe that this is correct and am not quite sure how to fix it. Can you point where in RFC4861 it says this? I'd agree that *to be efficient* a router should have enough space to hold an NCE for all locally attached subnets, but a constrained device *could* presumably age out and relearn old entries. Apart from that somewhat pathological case, if I'm a router and get a transit packet (not for a directly connected interface), I don't need to have a neighbor entry for it (otherwise "core" routers would need to build NCEs for every IP on the Internet :-P). Perhaps "for all directly connected subnets." or "for all directly connected addresses to which it can currently forward packets."? I'm somewhat uncomfortable with the uppercase MUST in: "A network administrator MUST deploy updated 6LR/6LBRs to support the number and type of devices in their network, ..." Having an uppercase MUST driving operators' design decisions stuff feels weird. I'd be perfectly fine with something like "In order to deploy this, network administrators MUST..." or "Network Administrators need to ensure that 6LR/6LBRs support the number and..." Nits: Section 4.2.1. Comparing TID values "In order to keep this document self-contained and yet compatible, the text below is an exact copy from section 7.2. "Sequence Counter Operation" of [RFC6550]."" I think that it would be helpful to delimit the copied text (perhaps by indenting it) -- it was unclear to me where the copied text started and ended, and so I had to go read RFC6550 (which kind of defeats the purpose of copying it). Section 4.3. Registration Ownership Verifier "An RFC6775-only will confuse the name-spaces," Missing a word - perhaps "device", "6LoWPAN Router" or "implementation"? Section 7.3. RFC6775-only 6LoWPAN Router "But if RFC6775-only and updated 6LRs coexist temporarily in a network, then it makes sense for an administrator to install a policy that allows so, and the capability to install such a policy should be configurable in a 6LBR though it is out of scope for this document." s/that allows so/that allows this/ -- readability (purely a nit). Section Appendix B. Requirements (Not Normative) "This section lists requirements that were discussed discussed by the 6lo WG..." I guess that they were discussed at length? :-P Section B.1. Requirements Related to Mobility " Due to the unstable nature of LLN links, even in an LLN of immobile nodes a 6LN may change" s/of immobile nodes a/of immobile nodes, a/ (add comma -- also a nitty nit). _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
