[MBONED] Éric Vyncke's No Objection on draft-ietf-mboned-driad-amt-discovery-10: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-mboned-driad-amt-discovery-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Jake,

Thank you for the work put into this document. Quite an achievement for a
single author !

Please find below some non-blocking COMMENTs and NITs. I hope that this helps
to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2.4.2 --
At the end, the text
        "its default settings MUST NOT permit more
   than 10 queries for any 100-millisecond period (though this MAY be
   overridable by administrative configuration)."
should probably use a "SHOULD NOT" rather than a "MUST NOT" as it "MAY" be
overridden.

The last paragraph is a little unclear whether the AMT gateway should wait
until all DNS replies are received before initiating AMT connection.

-- Section 2.5.3 --
The whole section about tunnel stability has little to do, IMHO, with neither
the title of the document "DNS Reverse IP AMT Discovery" nor with the abstract.
The content is useful and should perhaps be moved to another companion
document. I understand that this is a little late in the process so let's
change the abstract at least. Note: I considered balloting a DISCUSS on this
issue.

-- Section 3.1.1 --
Please expand CMTS & OLT used in figure 3

-- Section 3.1.2 --
Unsure whether this is a common use-case in 2019 but it is OK (I hope that my
ISP was mcast-capable...).

-- Section 4.1 --
Should the code 260 be allocated by IANA? I would rather use 'TBD' in the
document and ask for IANA allocation for 'TBD'

== NITS ==

-- Section 2.1 --
s/The sender/The multicast source/ ?

-- Section 4.2.2 --
Please use the canonical format for IPv6 address. I know this is cosmetic but
it hurts my eyes ;-)