Hi Suresh, Thanks very much for the review!
We've posted a new -09 version to incorporate your feedback: URL: https://www.ietf.org/internet-drafts/draft-ietf-intarea-provisioning-domains-09.txt <https://www.ietf.org/internet-drafts/draft-ietf-intarea-provisioning-domains-09.txt> Status: https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ <https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/> Htmlized: https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-09 <https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-09> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-intarea-provisioning-domains <https://datatracker.ietf.org/doc/html/draft-ietf-intarea-provisioning-domains> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-provisioning-domains-09 <https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-provisioning-domains-09> Detailed responses inline. Best, Tommy > On Dec 2, 2019, at 7:44 AM, Suresh Krishnan <[email protected]> wrote: > > Hi authors, > I found this draft generally well written and easy to read but I would like a > couple of things fixed in it before I send it off to IETF Last call. > > Major > ==== > > * Section 3 > > "The PvD ID is a Fully > Qualified Domain Name (FQDN) which MUST belong to the network > operator in order to avoid naming collisions." > > Which network operator? Can you please clarify this. Reworded this section to be more clear. > > * Section 3.1 > > How is the Router Lifetime field processed if the R bit is set and the RA > header is included? Is the intent that this will always supersede the “outer” > Router Lifetime for PvD aware hosts? In any case this needs to be specified > as it is not standard RFC4861 behavior. > Added a reference down to the host behavior section, and added a sentence to explain precedence handling. > * Section 3.4.1 > > Not sure if this is the best way to specify stateful DHCPv6. There are > stateful options that will not be under a PIO (e.g. IA_PD). I think this > document should limit itself to IA_NA and possibly IA_TA. Leaving this > unbounded does not seem to be a good idea. Thoughts? > The authors discussed, and we've left this as-is for now; part of the intention is to leave it open for implementations to associate IA_PD if they can. I can let Eric and Pierre chime in more on the details. > * Section 4.1 > > "If the host has a temporary address per[RFC4941] > in this PvD, then hosts SHOULD use a temporary address to > fetch the PvD Additional Information and SHOULD deprecate the used > temporary address and generate a new temporary address afterward.” > > Not sure why this behavior is required. Can you please explain? Added both a description of the reason for this (privacy protections), and made the recommendation a MAY. > > * Section 5 > > I was thinking that there needs to be some host behavior to be specified > related to the H bit and the sequence number here. If the H bit is set and > the sequence number is unchanged from a previous successful query I think the > host should refrain from sending another https query. If you agree, this > needs to be written down. I've added a new example section that details these considerations. Great suggestion! > > Minor > ===== > > * Section 1 > > This text is confusing and self-referential > > OLD: > Since such options are only > considered by hosts implementing this specification, network > operators may configure hosts that are 'PvD-aware' with PvDs that are > ignored by other hosts. > > Suggest rewording to something like > > Since such options are only > considered by hosts implementing this specification, network > operators may configure hosts that are 'PvD-aware' with PvDs that are > ignored by other hosts. Fixed! > > * Section 3.1 > > Not sure if the definition of the L flag is correct. Does the router actually > need to provide the DHCPv4 information to set this? What if it is just a > relay? > > * Section 4.1 > > Not sure why there is a reference to RFC8615 here. Remove this reference, and moved down to the IANA registration (where it is relevant). > > Editorial > ====== > > * Section 1 > > OLD: > The ability to associate additional informations > > NEW: > The ability to associate additional information > > OLD: > deriving from it > > NEW: > derived from it Fixed these. > > Thanks > Suresh >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
