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

["Holland, Jake" <[e-mail]>]

Hi Éric,

Thanks for the review and comments.  Some responses below.

On 2019-12-17, 12:01, "Éric Vyncke via Datatracker" <[e-mail]> wrote:
> Thank you for the work put into this document. Quite an achievement for a
> single author !

In many ways I suspect it was easier as a single author ;)

> -- 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.

Sure, that's fine by me.  I've changed this locally and it will be in the
-11 version.

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

(I noticed another case of RFC 8085 mistakenly being used here instead of
RFC 8305, now also fixed locally, and did a search for any others.)

I thought this point was pretty well covered by RFC 8305, but if you
think it's helpful I could add a note about this detail at the end of the
paragraph:

OLD:
   under the algorithm restrictions and guidelines given in [RFC8085]
   for the "Establishment of one connection, which cancels all other
   attempts" phase.

NEW:
   under the algorithm restrictions and guidelines given in [RFC8305]
   for the "Establishment of one connection, which cancels all other
   attempts" phase.  As described in Section 3 of [RFC8305], DNS
   resolution is treated as asynchronous, and connection initiation does
   not wait for lagging DNS responses.

FWIW, I'm slightly negative on adding this. I think this is one of
several details about Happy Eyeballs algorithms that are mostly not
explicitly spelled out in this doc, but rather implied by reference
to RFC 8305.

However, if you think this is a particularly useful detail to highlight,
I'm willing to add the above text or similar.

> -- 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.

I see what you mean, and after having written them up, it occurred to me
that a number of the sub-sections in section 2 maybe could have been
structured as a companion document instead.  But I ended up deciding that
the advice on when to restart discovery was worthwhile to include.

I think updating the abstract is a good solution, thanks for the suggestion.

Does this work?

OLD:
   This document updates RFC 7450 (Automatic Multicast Tunneling, or
   AMT) by extending the relay discovery process to use a new DNS
   resource record named AMTRELAY when discovering AMT relays for
   source-specific multicast channels.  The reverse IP DNS zone for a
   multicast sender's IP address is configured to use AMTRELAY resource
   records to advertise a set of AMT relays that can receive and forward
   multicast traffic from that sender over an AMT tunnel.

NEW:
   This document updates RFC 7450 (Automatic Multicast Tunneling, or
   AMT) by modifying the relay discovery process.  A new DNS resource
   record named AMTRELAY is defined for publishing AMT relays for
   source-specific multicast channels.  The reverse IP DNS zone for a
   multicast sender's IP address is configured to use AMTRELAY resource
   records to advertise a set of AMT relays that can receive and forward
   multicast traffic from that sender over an AMT tunnel.  Other minor
   extensions and clarifications to the relay discovery process are also
   defined.


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

These terms don't fit in the image very well, but I can add them to the
definitions section, unless you have a better suggestion?

NEW (section 1.3):
   |            |                                                      |
   |       CMTS | Cable Modem Termination System                       |
   |            |                                                      |
   |        OLT | Optical Line Terminal                                |


> -- 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...).

AFAICT support is mixed, and often has caveats, especially for interdomain
multicast.  I hope this improves, but I think improved support for the
transition technologies like AMT might be critical to making that happen. 

> -- 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'

This was the case for the -00 version:
https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-00#section-5

However, the codepoint was provisionally assigned by IANA last February,
under the guidelines in RFC 6895:
https://tools.ietf.org/html/rfc6895#section-3.1.1

So it's already in the registry as 260, and will become reasonably permanent
if this doc becomes an RFC:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml


> == NITS ==
> 
> -- Section 2.1 --
> s/The sender/The multicast source/ ?

I think this would make it slightly less correct.  I think "the multicast
source" refers to a device sending multicast traffic (or sometimes maybe its
IP address).  "The sender" at the beginning of paragraph 2 refers to an
entity that both controls the RR in the DNS zone and also operates a device
producing multicast traffic.

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

I think you meant 4.3.2, and this is just DB8 -> db8, correct?  Or was there
more?

OLD:
       10     IN AMTRELAY  10 0 2 2001:DB8::15

NEW:
       10     IN AMTRELAY  10 0 2 2001:db8::15