Pascal and 6LO WG, Thanks for the work done in this document (and the shepherd’s write-up). I really like the quick summary in section 1 about the LLN differences wrt. other networks as it will prevent some IPv6 objections.
As usual, I am doing my AD review of draft-ietf-6lo-prefix-registration before going forward with the publication process, i.e., the IETF Last Call and the IESG evaluation. I request the author (or the WG) to address all points below, either by a revised I-D or an explanation (telling me that I am plain wrong is OK of course). As noted by Adnan, by the erratum #8340, and the 6LO chairs’ email: https://mailarchive.ietf.org/arch/msg/6lo/ACVb0LmKUHLnpphjWuF87D4d34Y/, the ‘fix’ will be a in separate short I-D and not in draft-ietf-6lo-prefix-registration. Please rest assured that my only intents are to improve the document quality and to prepare an easy publication path even if there are many points to be addressed below Kind regards -éric Nits: * S 1: `agnotic`? * S 2.4: s/A RPL router that merges becomes the origin of the merged/A RPL router that merges *then* becomes the origin of the merged/ * S 3.2: s/more than one Prefix/more than one *p*refix/ * S 7.2: clarify “the packets will be not be filtered” * S 7.4: `existing registration state might be lost if it was not persisted` use “persistent” perhaps ? * S 7.4: s/the link local address/the link-local address/ or use LLA * S 8: empty bullet * If the I-D uses Kramdown, then using aasvg in the .md file would make some nice SVG rather than ASCII art Comments: 1. Abstract, the sentence starting with “The unicast prefix” is very long and convoluted, i.e., please try to simplify it (perhaps by cutting is smaller sentences ?) 2. S 1: please make `6LoWPAN was a pioneering attempt at the IETF ` more factual (references) and less dramatic 😉 3. S 1: s/complexity in the routers/complexity in the always-powered routers/ ? 4. S 1: `Restful operations` often means REST (Representational state transfer) compatible operations in the IETF context, suggest using another term 5. S 1: is ‘proactive’ required and correct in `Stateful proactive knowledge`? 6. S 1: s/the power usage can be lowered/the power usage can be *reduced*/ 7. S 1: s/asynchronous broadcast operations/asynchronous *multicast* operations/ and later s/when broadcast was cheap/when *multicast* was cheap/ 8. S 1: suggest removing the sentences and reference to SFAAC as it is mostly a distraction 9. S 1: is it `router-protocol-agnostic interface` or “rout*ing*-protocol-agnostic *way*” ? (as interface is overloaded at the IETF) 10. S 1: s/ to enable a node to register a prefix/ to enable a node to register a *unicast* prefix/ 11. S 1: s/asynchronous broadcast messages/asynchronous *multicast* messages/ 12. S 1: expand `RA` at first use 13. S 1: s/ RIO is explicitly not intended to serve in routing/ RIO is explicitly not intended to inject routes in routing/ and I am not sure whether RFC 4191 ‘explicitly’ says so... 14. >>> S 2.1, a tough one, [I-D.kuehlewind-update-tag<https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag-04>]is used in a normative way to define “extends” and “amends”, i.e., it must be normative. You may want to copy the definitions in this document (citing an informative reference) though 15. S 2.3, a very long and dry list, are all acronyms used in this I-D ? 16. S 3: ` can now attract the traffic for a full prefix` please do not use ‘attract’ and be sure that the 6LN takes the traffic in charge (= forward) 17. S 3: s/in other routing protocol/in *an*other routing protocol/ ? 18. S 3: s/the 6LR is requested to redistribute/the 6LR MUST redistribute/ ? (if SHOULD is preferred, then explain when this can be bypassed) 19. S 3: s/across the active registrations for the prefix/across the *non-expired received* registrations for the prefix/ 20. S 3: strongly suggest removing the paragraph starting with `This specification extends 6LoWPAN work, and it is *certainly* possible to leverage it` 21. S 3.1: unsure whether “abstract” is correct in `abstract data structure` also `registrar` is a *role* and not a data structure 22. S 3.1: unsure whether the 3rd § is required 23. S 3.1: in Fig 1, is the Northbound if the 6LBR always “wired” ? E.g., think about the “SNAC AIL”, which can be Wi-Fi 24. S 3.1: suggest to use specific name/id in Fig1 and the text for `A leaf acting ` 25. S 3.1: avoid any ambiguity in ` by the Registering Node`(is it 6LR or 6LN in Fig 1?) 26. S 3.1 is it still worth referencing to an expired I-D heile-lpwan-wisun-overview ? 27. S 3.2: explain ESS ? 28. S 3.2: s/Ethernet + Wi-Fi *ESS*/Ethernet *or* Wi-Fi/ 29. S 3.2: Fig 2 appears as upside-down, i.e., the global connectivity/Internet is usually on the top of the graphic, please flip the graphic 30. >>> S 3.2: in Fig 2, shouldn’t all nodes use SLAAC and have addresses in P1 and P2 prefixes and use RFC 6724 for source address/next hop selection ? 31. S 3.3: avoid having a ‘+’ between HUB-LINK in Fig 3 32. S 3.3: should DHCP-PD be mentioned in `If P2 was delegated by 6LR1`? 33. S 4: should there be a note about the co-existence of RFC 8505 & legacy nodes doing NS/NA ? Section 11 is mostly silent on this topic 34. S 5: `updated by RFC Editor if needed` should rather be a specific paragraph to ensure that this step will be executed 35. S 7.2 there is no `plen` in Fig 5 ;-) 36. S 7.2: `when the packets are sourced with the registered prefix` is it ‘sourced’ or ‘destined’ ? 37. S 7.3, as the terminology is silent, please add a normative reference to the RFC defining EDAR 38. S 7.3, define what to do when the padding of the prefix is != 0 39. S 7.3, prefix length is not a `1-bit flag` 40. S 7.4 the paragraph starting with `The operation for registering prefixes is similar ` is not really a behavior, i.e., remove it from the bulleted list 41. S 7.4: s/FF02::1/ff02::1/ 42. S 7.4: what is an `unreliable environment`? 43. S 7.4: what is a ‘proxy’ in `that a proxy registers a prefix ` ? 44. S 7.4: s/longest match/longest prefix match/ ? (several occurrences) 45. S 7.4: in `it SHOULD register all those prefixes`, explain when the SHOULD can be bypassed or what are the consequences of bypassing the SHOULD 46. >>> S 9: as there will be another I-D for the change C/P, simply add a normative reference to this I-D (and I understand that this I-D should be drafted first...) 47. S 9: in `Prefixes are not always owned by one node` unsure what “own” means here and perhaps use “owned by only on node” 48. S 10: please explain when the “SHOULD” can be bypassed or what are the consequences of bypassing it 49. S 12.2 as written above, remove this sub-section 50. S 13: s/for their early *INT-DIR* review/for their early review*s*/
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
