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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 17 Dec 2019 12:00:55 -0800

É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 ;-)

---

From: "Holland, Jake" <[email-masked]>
Date: Tue, 17 Dec 2019 23:04:26 +0000

Hi Éric,

Thanks for the review and comments.  Some responses below.

> Thank you for the work put into this document. Quite an achievement for a

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

> should probably use a "SHOULD NOT" rather than a "MUST NOT" as it "MAY" be

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

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

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

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

> 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

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

> Please use the canonical format for IPv6 address. I know this is cosmetic but

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 18 Dec 2019 06:43:59 +0000

Jake,

I won't comment on your statement about having  a single author is easier ;-)

Thank you for the replies and the actions on my IESG review, please see in-line for the remaining open points, look for EV>. The document is was and is still "good for publication" from my point of view.

Regards

-éric

On 18/12/2019, 00:04, "Holland, Jake" <[email-masked]> wrote:

    

    OLD:
    
    NEW:

EV> I see what you mean...

EV> this is really the only place where I see it beneficial for the reader to understand. So, up to you, but I am still in favor of the NEW text

    
    
    Does this work?
    
    OLD:
    
    NEW:

EV> a step forward in the right direction, any chance to remove the word 'minor' ?

EV> OK

EV> yes, only one occurrence  AFAIK

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 18 Dec 2019 22:47:22 +0000

On 2019-12-17, 22:44, "Eric Vyncke (evyncke)" <[email-masked]> wrote:
    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.

 

[JH] OK, the new text is fine with me.

    NEW:

[JH] No problem, I'll do it that way.

EV> OK