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

Request Review of draft-ietf-intarea-provisioning-domains
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-12-25
Requested 2019-12-11
Authors Pierre Pfister, Éric Vyncke, Tommy Pauly, David Schinazi, Wenqin Shao
Draft last updated 2019-12-26
Completed reviews Intdir Early review of -01 by Zhen Cao (diff)
Opsdir Early review of -01 by Tim Chown (diff)
Secdir Last Call review of -04 by Phillip Hallam-Baker (diff)
Rtgdir Last Call review of -09 by Russ White (diff)
Tsvart Last Call review of -09 by Martin Duke (diff)
Genart Last Call review of -09 by Francis Dupont (diff)
Opsdir Last Call review of -09 by Tim Chown (diff)
Assignment Reviewer Tim Chown
State Completed
Review review-ietf-intarea-provisioning-domains-09-opsdir-lc-chown-2019-12-26
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/eES1FGONF6ZCIschw5wCEIHLixQ
Reviewed rev. 09 (document currently at 11)
Review result Has Nits
Review completed: 2019-12-26

Review
review-ietf-intarea-provisioning-domains-09-opsdir-lc-chown-2019-12-26

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