Last Call Review of draft-ietf-intarea-provisioning-domains-09
review-ietf-intarea-provisioning-domains-09-opsdir-lc-chown-2019-12-26-00

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?

Also, talking about MTU on p.9, I think multiple RAs MUST be sent, not “can be
sent”, as per 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.

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)

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”

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 _.'/^\'._.'/^\'._.'/^\'.__) \
     ,=='  `---`   '---'   '---'      )