Re: draft-ietf-mboned-driad-amt-discovery

Thanks Bill, much appreciated.  Some more comments inline.


On 2019-06-12, 18:04, "William Atwood" <[email protected]> wrote:

    This is a very useful addition to the AMT toolkit, which should
    encourage the deployment of multicast services.  I therefore support its
    adoption enthusiastically.
    
    I offer the following nits:
    
    Section 2.2, para 5, line 5.  "a SSM" -> "an SSM"  (Since "SSM" is
    pronounced "es-es-em", the initial *sound" is "es", and the required
    form for the indefinite article is therefore "an".  The form of the
    article is dependent on the initial _sound_, not the initial _letter_.)

Thanks for catching this.  It looks like this is what RFCs 4601 and 7761
use, so I agree this should do the same.  I was thinking of the pronunciation
as the expansion ("source-specific multicast"), but on reflection, I agree
this is better.  (Same response for other examples marked with *)
    
    Section 2.3.1, para 2, line 2.  "a SSM" -> "an SSM"
*
    
    Section 2.4.2, para 4, bullet 3, line 2.  "which" -> "that"  (See the
    end of this review for the reason.)

Thanks for catching this, this is a bad habit I've been working on, but I
missed this one.
    
    Paragraph 12, line 1.  Should this "may" be "MAY"?

I meant this intentionally.  Perhaps I should change it to "might" to be
more clear?  I felt like this use wasn't describing an optional protocol
feature, but rather a state of affairs that could be occurring and would
be worth keeping in mind.
    
    Section 2.5.2, para 2, line 3.  "following" -> "remaining 4"  (I feel
    that "following" is ambiguous.)
Thanks, I agree that's better.
    
    Bullet 6, line 1.  "a (S,G)" -> "an (S,G)"
*
    
    Section 2.5.3, para 1, line 4.  "as long the" -> "as long as the"
Yes, thanks.
    

    Section 2.5.6, para 1, line 1.  Should "should" be "SHOULD"?
    
    Para 2, line 1.  Should "are required to" be "MUST"?
    
    Para 6.  Again, this looks to me like normative text, but there are no
    RFC 2119 keywords.

My reasoning here was that these are not new requirements this document
is setting, but rather a summary of existing requirements already explained
in RFC 7450, which this doc is not changing.

On review, I think maybe I'm wrong about the last one, but I think it holds
for the first 2.  Do you think it works if I change just the paragraph 6 to
"This style of Relay Discovery message ... SHOULD NOT be ..." instead of
"should not", and leave the other 2?

    
    Section 4.3.2, para 1, line 6.  Since the last field of this line
    contains what looks like an FQDN, I believe that the terminal period
    should not be present.

Maybe I'm mistaken, and if there's a DNS expert who can point to a solid
explanation, I'd be grateful.  But I thought for DNS zone files the trailing
period was considered right.

There's other similar examples for entries with a similar syntax, e.g. from
Section 3.5 of RFC 1035:
    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.    
https://tools.ietf.org/html/rfc1035#section-3.5

And likewise in the more recent example I was using as a model, in Section 3.2
of RFC 4025:
   38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
                    mygateway.example.com.
                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
https://tools.ietf.org/html/rfc4025#section-3.2


But I admit I found the DNS specs kind of a horrible, hard-to-follow sprawl,
and I'm not sure I got it right.

So do you have a guideline to how sure you are about this?  I'm no DNS expert,
and I'll gladly defer to wiser heads on this, but this seems to disagree with
existing docs, so I'd want to have a solid reason for doing it differently.


In summary:

My local copy has edits for all your suggested changes except these where
I've tentatively disagreed, though of course I'm open to further discussion:

- Section 2.4.2, Paragraph 12, line 1 may->MAY in 
"certain relay addresses may be excluded"

- Section 2.5.6, para 1, line 1.  "should"->"SHOULD" in
"A gateway should only send DNS"
(Maybe this one would be better written as "A gateway ordinarily only sends
DNS..."?)

- Section 2.5.6 Para 2, line 1. "are required to" -> "MUST" in
"all AMT relays are required to support handling of"

- Section 4.3.2, para 1, line 6, regarding trailing dot on FQDN

Please let me know if you still disagree on any of these, I don't feel too
strongly and can easily be convinced to accept some edits on these if you
want to suggest something, I just wanted to respond and check how strongly
you feel about them.


And thanks much!

-Jake
    
    
    On 2019-06-12 12:31 p.m., Warren Kumari wrote:
    > Dear MBONED,
    > 
    > Pretty please, can you review and comment on the WGLC for
    > draft-ietf-mboned-ieee802-mcast-problems and
    > draft-ietf-mboned-driad-amt-discovery ?
    > 
    > See the thread labeled: "[MBONED] WGLCs for
    > draft-ietf-mboned-ieee802-mcast-problems and
    > draft-ietf-mboned-driad-amt-discovery"
    > 
    > The initial WGLC was extended until June 13th to get additional
    > feedback - "both docs have enjoyed tremendous support from folks in
    > the meetings/list in the past and there has been no particularly
    > controversies  noted in either doc."
    > 
    > It will be very discouraging if we cannot get additional comments.
    > 
    > W
    > 
    
    -- 
    Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
    Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
    Department of Computer Science
       and Software Engineering
    Concordia University EV 3.185     email:[email protected]
    1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
    Montreal, Quebec Canada H3G 1M8
    
    _______________________________________________
    MBONED mailing list
    [email protected]
    https://www.ietf.org/mailman/listinfo/mboned
    

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned