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

["Eric Vyncke (evyncke)" <[e-mail]>]

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" <[e-mail]> wrote:

   
    On 2019-12-17, 12:01, "Éric Vyncke via Datatracker" <[e-mail]> wrote:
    
    > 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.

EV> I see what you mean...
   
    However, if you think this is a particularly useful detail to highlight,
    I'm willing to add the above text or similar.
 
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

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

EV> a step forward in the right direction, any chance to remove the word 'minor' ?
    
    
    > == 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.

EV> OK
    
    > -- 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?

EV> yes, only one occurrence  AFAIK