Hi Tim, Happy New Year! Thanks very much for your thorough review. We've just posted a -10 version (https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-10) that addresses your comments. > On Dec 26, 2019, at 2:26 AM, Tim Chown via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Tim Chown > Review result: Has Nits > > Hi, > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects of > the IETF drafts. Comments that are not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs should > treat these comments just like any other last call comments. > > This draft describes the use of Provisioning Domains (PvDs), which form > consistent sets of network related information, allowing hosts to better manage > multiple simultaneous connections. The draft includes the definition of a > Router Advertisement option to convert PvD information to “PvD aware” hosts. > Hosts not supporting PvDs continue to function as before. > > I have been following the PvD work since its early roots in the Multiple > Interfaces (MIF) WG. I believe PvDs have the potential to be of great value > for hosts in multiple interface (physical or virtual) scenarios, and that this > is important work. > > The document is very well-written and easy to follow, aided admirably by the > use of PvD examples. > > Overall, the draft is in good shape, and I would consider it to be Ready with > Nits. > > General comments: > > Sec 3.2 > Should we say anything here in para 4 about what happens when a router’s > link-local interface address changes for some reason? Added the following sentence: If a link-local address on the router is changed, then any new RA will be interpreted as a different Implicit PvD by PvD-aware hosts. > > Also, talking about MTU on p.9, I think multiple RAs MUST be sent, not “can be > sent”, as per RFC6980. That's a good point. We now also reference RFC6980. > > Sec 3.4.2 > In the penultimate paragraph, while this behaviour seems appropriate, I can see > troubleshooting it as being tricky for many administrators. It’s probably > beyond the scope of this document, but that topic is something to think about, > and also how PVDs are presented in general through operating system network > configuration commands. Indeed, this is something that does require careful configuration for more complex deployments. I agree, however, that such further details are out of scope for this document. > > Sec 3.4.4 > Second para - but just how would an application make that selection? What form > does the API take? Need a reference to that work, maybe Sec 6 of RFC 7556? > (Not just 5.2.1 of that doc) Added a reference to section 6 as well. A good suggestion! > > Nits: > > Sec 3.1 > > p.5 > “called PvD option” -> “called the PvD option” > > p.7 > “Domain names” -> “Domain name” > “Here is” -> “Figure 2 shows” > > p.8 > To be consistent with section 3.4, I’d change RFC6106 in the figure to RFC8106. > > Sec 3.2 > > p.8 > “hosts per” -> “hosts as per” > “PvDs are” -> “PvD is” > > Sec 3.3 > > p.9 > “This ensure” -> “This ensures” > “with a” -> “where a” > > Sec 3.4.2 > P.11 > “with the all” -> “with all” > > Sec 4.1 > p.14 > “that host” -> “that the host” > > Sec 5 > p.18 > “of PvD” -> “of PvDs” All other nits applied. Best, Tommy > > And given it’s Boxing Day here, I’ll throw this in from November 1997 drawn by > “jgs”, for those reading in fixed width font :) > > _... > o_.-"` `\ > .--. _ `'-._.-'""-; _ > .' \`_\_ {_.-a"a-} _ / \ > _/ .-' '. {c-._o_.){\|` | > (@`-._ / \{ ^ } \\ _/ > `~\ '-._ /'. } \} .-. > |>:< '-.__/ '._,} \_/ / ()) > | >:< `'---. ____'-.|(`"` > \ >:< \\_\\_\ | ; > \ \\-{}-\/ \ > \ '._\\' /) > '. /( > `-._ _____ _ _____ __.'\ \ > / \ / \ / \ \ \ > jgs _.'/^\'._.'/^\'._.'/^\'.__) \ > ,==' `---` '---' '---' ) > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
