Skip to main content

Last Call Review of draft-ietf-mboned-driad-amt-discovery-09
review-ietf-mboned-driad-amt-discovery-09-opsdir-lc-comstedt-2019-11-29-00

Request Review of draft-ietf-mboned-driad-amt-discovery
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-12-02
Requested 2019-11-18
Authors Jake Holland
I-D last updated 2019-11-29
Completed reviews Rtgdir Last Call review of -09 by Henning Rogge (diff)
Rtgdir Last Call review of -09 by Carlos Pignataro (diff)
Opsdir Last Call review of -09 by Niclas Comstedt (diff)
Genart Last Call review of -09 by Dan Romascanu (diff)
Secdir Last Call review of -11 by Daniel Fox Franke (diff)
Tsvart Last Call review of -09 by Dr. Bernard D. Aboba (diff)
Assignment Reviewer Niclas Comstedt
State Completed
Request Last Call review on draft-ietf-mboned-driad-amt-discovery by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/cwgNyT-qZnATxOVVqLnatj8F-Hw
Reviewed revision 09 (document currently at 13)
Result Ready
Completed 2019-11-29
review-ietf-mboned-driad-amt-discovery-09-opsdir-lc-comstedt-2019-11-29-00
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 extends AMT (RFC 7450), specifically by extending the relay discovery
process to use a new DNS AMTRELAY RR mechanism, and as such is targeting the 
standards track. It's a well written draft and ready to go. It covers relevant 
operational aspects throughout the draft in appropriate sections.

The one nit about the usage of IPv4 mcast address (currently 232.252.0.2) I
don't see as an issue. Given this draft and mechanism is SSM specific I think 
using a valid SSM address instead of 233.252.0.0/24 is fine.


/nco