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

Agreed items deleted; my comments on the rest are inline.

jwa

On 2019-06-13 5:58 p.m., Holland, Jake wrote:
> Thanks Bill, much appreciated. Some more comments inline.
>
>
> On 2019-06-12, 18:04, "William Atwood" <[email protected]>
> wrote:
>
>
> 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.

<jwa> I agree that "might" would be clearer.

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

For para 1, while the DNS-SD restriction is in 7450, the AMTRELAY RRType
is introduced in this document, so this is a new requirement. 
Therefore, I believe that the "should" must be a "SHOULD".

For para 2, how about the following:

However, all AMT relays are required by [RFC7450] to support ...

For Para 6, I agree with your proposed change.

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

I am no DNS expert at all.  (I can expand the acronym, and I have a
vague idea of how the DNS works, but that's about it.)  :-)  I defer to
your set of examples.

  Bill


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