Last Call Review of draft-ietf-intarea-provisioning-domains-09

Request Review of draft-ietf-intarea-provisioning-domains
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2019-12-25
Requested 2019-12-11
Authors Pierre Pfister, √Čric Vyncke, Tommy Pauly, David Schinazi, Wenqin Shao
Draft last updated 2019-12-21
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 Martin Duke
State Completed
Review review-ietf-intarea-provisioning-domains-09-tsvart-lc-duke-2019-12-21
Posted at
Reviewed rev. 09 (document currently at 11)
Review result Ready with Nits
Review completed: 2019-12-21


This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC if you reply to or forward this review.

This document is ready, and well-written. The examples were especially helpful in following how things fit together. There aren't any specific transport layer considerations that must be addressed to move forward; however, this mechanism is partly intended to support multihomed transports, and it is not difficult to imagine extensions that would help those transports by providing additional information about each path. I hope these eventually follow in another document.

- Second sentence of Sec 3: delete either "which" or "that"
- Sec 3.1 RA Message Header description: clarify that non-zero checksums "MUST be ignored by the receiver and the rest of the option processed", if that is in fact accurate.
- Sec 3.1 it might be helpful to spell out RDNSS the first time the acronym appears.
- Sec 5.2. Can you add a sentence on why sending two RA messages is RECOMMENDED?