Re: [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-intarea-provisioning domains

Hi Martin,

Thanks very much for your helpful review! We've just posted a -10 revision (https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-10), that should address your comments.

> On Dec 17, 2019, at 4:53 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> sending it to the area this time..
> 
> On Tue, Dec 17, 2019 at 4:52 PM Martin Duke <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>> wrote:
> Reviewer: Martin Duke
> Review result: Ready
> 
> 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
> tsv-art@ietf.org <mailto:tsv-art@ietf.org> 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.
> 
> Nits:
> - 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.

All of these suggestions have been applied!

> - Sec 5.2. Can you add a sentence on why sending two RA messages is RECOMMENDED?

The new explanation here is:

This approach allows for two distinct sets of configuration
   information to be sent in a way that will not disrupt non-PvD-aware
   hosts.  It also lowers the risk that a single RA message will
   approach its MTU limit due to duplicated information.

Best,
Tommy

> 
> Martin
> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call