Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-intarea-provisioning-domains-09

From: Tommy Pauly <[email-masked]>
Date: Mon, 06 Jan 2020 09:52:44 -0800

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Tim Chown <[email-masked]>
Date: Tue, 7 Jan 2020 13:54:11 +0000

Cheers Tommy, all looks good.

Tim

On 6 Jan 2020, at 17:52, Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>> wrote:

Hi Tim,

On Dec 26, 2019, at 2:26 AM, Tim Chown via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

Reviewer: Tim Chown
Review result: Has Nits

Hi,

General comments:

Sec 3.2

Sec 3.4.2

Sec 3.4.4

Nits:

Sec 3.1

p.5

p.7

p.8

Sec 3.2

p.8

Sec 3.3

p.9

Sec 3.4.2
P.11

Sec 4.1
p.14

Sec 5
p.18
“of PvD” -> “of PvDs”

All other nits applied.

Best,
Tommy

                  _...
            o_.-"`    `\
     .--.  _ `'-._.-'""-;     _
   .'    \`_\_  {_.-a"a-}  _ / \

--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call

--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call