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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> wrote:

sending it to the area this time..

On Tue, Dec 17, 2019 at 4:52 PM Martin Duke <martin.h.duke@xxxxxxxxx> 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@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux