Le lun. 14 avr. 2025 à 13:44, Eric Vyncke (evyncke) <[email protected]> a écrit :
> Pascal and 6LO WG, > > > Hello Eric! Many thanks for your review. > 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. > > I published 08 prior to handling it so we can have a clean diff on the application of your comments below. 08 takes off the handling of the 'C' flag which is now done by draft-ietf-6lo-updating-rfc-8928. > 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 > > > : ) > > > 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” > > I added the title of the BCP ( Network Ingress Filtering ) .so it's more clear what filtering I'm talking about: " This means that the Registering Node relays packets that are sourced in the Registered Prefix to the outside, in accordance with "Network Ingress Filtering" [BCP38] . " > > - S 7.4: `existing registration state might be lost if it was not > persisted` use “persistent” perhaps ? > > No, I meant persisted in some remanent storage > > - S 7.4: s/the link local address/the link-local address/ or use LLA > > what about " if it was not safely stored, e.g., in persistent memory. " > > - > - 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*/ > > > > > > > -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
