Subject: [MBONED] Plea / favor: Review and comment on draft-ietf-mboned-ieee802-mcast-problems and draft-ietf-mboned-driad-amt-discovery

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Jun 2019 12:31:58 -0400

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
-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: William Atwood <[email-masked]>
Date: Wed, 12 Jun 2019 21:04:38 -0400

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

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

Paragraph 12, line 1.  Should this "may" be "MAY"?

Section 2.5.2, para 2, line 3.  "following" -> "remaining 4"  (I feel
that "following" is ambiguous.)

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"

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.

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.

NOTE on use of "which" and "that".  "that" is used when the phrase
following it is _required_ if we are going to be able to completely
identify what is being talked about, while "which" is used to introduce
supplementary information.  Some examples:

1) If there are three houses on the street, and only one of them is at
the corner, then you say:
"The house that is on the corner needs to be painted."
2) If there are three houses on the street, and only one of them is
yellow, then you say:
"The yellow house, which needs to be painted, is for sale."

In the first case, the observer cannot identify the exact house until
its position is given.  In the second case, the house is completely
identified by its colour, and the information about the need to be
painted is supplementary information.  This information is set off with
commas, and introduced with "which".

Bill Atwood

-- 
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-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: William Atwood <[email-masked]>
Date: Wed, 12 Jun 2019 23:43:10 -0400

This is a very useful document and I support its adoption.

I have the following nits:

Section 1, para 1, line 9.  "wifi" -> "Wi-Fi"  (A check needs to be made
to expunge all incorrect presentations of "Wi-Fi" from the entire document.)

Section 3.1.2, para 1, line 3.  "which" -> "that"  (See end of review
for the reason.)

Section 3.2.4, para 4, line 4.  "amount" -> "number"  (If you can count
it on the integers, use "number"; if you can measure it using real
numbers, use "amount".)

Section 4.5.3, para 1, line 2.  If "STA" is pronounced "es-tee-ay", then
"a STA" needs to be written as "an STA".  (The form of the article is
dependent on the initial _sound_, not the initial _letter_.)

Section 4.5.4, para 1, line 3.  "a STA" -> "an STA"

Para 2.  I suggest that this text be revised to include a third option:
DRIAD (See draft-ietf-mboned-driad-amt-discovery.)  It would be a shame
to do a Last Call on both DRIAD and this document at the same time and
not coordinate them!!!)

I further suggest that the order of presentation of the three options be
the same as the order of preference for AMT relay lookup, as defined in
the DRIAD document, i.e.:
1.	DNS-SD
2.	The well-known IP addresses from Section 7 of [RFC7450]
3.	DRIAD

Section 4.6, para 4, bullet 4.  "which" -> "that"

Section 5.1, topic "ARP sponges", para 1, line 14.  It is not clear who
"We" is, in "We have to run".  This text needs to be re-written to get
rid of the first-person presentation.

Topic "Router mitigations", line 4.  "which" -> "that"  Also, "we" is
undefined here, so the text needs to be re-written in the third person.

Topic "Firewall unused space".  "from meeting to meeting"  (of what
group??)  (It is clear to me that this point is talking about an IETF
meeting, but the specific text here needs to be either expanded (to
explain the context) or generalized.)

Topic "NAT"  Again, this topic is specific to IETF meetings, without
stating so.  The solution is applicable to much more than IETF meetings...

Topic "Stateful firewalls"  As above, this text is IETF-meeting specific.

Section 8, para 3, line 6.  "amount" -> "number"

Bill Atwood

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 13 Jun 2019 21:58:03 +0000

Thanks Bill, much appreciated.  Some more comments inline.

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

    

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

Thanks for catching this, this is a bad habit I've been working on, but I
missed this one.

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.
    
*
    
Yes, thanks.

    

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?

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

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

---

From: William Atwood <[email-masked]>
Date: Fri, 14 Jun 2019 20:43:51 -0400

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

jwa

> be worth keeping in mind.

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

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

> existing docs, so I'd want to have a solid reason for doing it

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

---

From: "Holland, Jake" <[email-masked]>
Date: Sat, 15 Jun 2019 03:39:42 +0000

Hi Bill,

For most of the responses, I take your suggestions as written, but one
I'll propose a tweak, because I still think s/should/SHOULD/ isn't
quite right in paragraph 1 of 2.5.6, though you do have a point that
it refers to DNS so it can't be from RFC 7450.  (Sorry about that mistaken
claim.)

1.
> Therefore, I believe that the "should" must be a "SHOULD".

Paragraph 1 of 2.5.6 says:
   A gateway should only send DNS queries with the AMTRELAY RRType or
   the DNS-SD DNS queries for an AMT service as part of starting or
   restarting the discovery process.

I think the construct "SHOULD only" is weird, because really I'm expressing
an expectation that a thing won't happen.

However, "SHOULD NOT send unless" is also a bit weird, because it's not
exactly forbidden to send DNS to keep history or something.

This line of reasoning led me to realize that this paragraph is actually
just completely unnecessary, so how about I cut it instead of changing
should to SHOULD?

OLD:
2.5.6.  Relay Discovery Messages vs. Restarting Discovery

   A gateway should only send DNS queries with the AMTRELAY RRType or
   the DNS-SD DNS queries for an AMT service as part of starting or
   restarting the discovery process.

   However, all AMT relays are required to support handling of Relay
   Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]).

   So a gateway with an existing connection to a relay can send a Relay
   Discovery message to the unicast address of that AMT relay.  Under

NEW:
2.5.6.  Relay Discovery Messages vs. Restarting Discovery

   All AMT relays are required to support handling of Relay
   Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]).

   So a gateway with an existing connection to a relay can send a Relay
   Discovery message to the unicast address of that AMT relay.  Under

2.
Reviewing this section made me notice one other spot with a similar issue,
so I'm also changing "recommended" to "RECOMMENDED" in the last paragraph
as well, if there are no objections:
OLD:
   process.  It is recommended for gateways to support the L flag, but
   for gateways that do not support the L flag, sending this message
   during event #3 may help mitigate service degradation when relays
   become unstable.

NEW:
   process.  It is RECOMMENDED for gateways to support the L flag, but
   for gateways that do not support the L flag, sending this message
   during event #3 may help mitigate service degradation when relays
   become unstable.

Thanks much, and please let me know if these edits work for you.

Best regards,
Jake

---

From: "Holland, Jake" <[email-masked]>
Date: Sat, 15 Jun 2019 03:44:03 +0000

Oops, the NEW on that should contain one of your other edits also:

Actual NEW first paragraph of 2.5.6:
   All AMT relays are required by [RFC7450] to support handling of Relay
   Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]).

Best,
Jake

On 2019-06-14, 20:40, "Holland, Jake" <[email-masked]> wrote:

    Hi Bill,

    1.

    

    OLD:

    
    
    NEW:

    2.
    
    NEW:

    
    Best regards,
    Jake

---

From: William Atwood <[email-masked]>
Date: Fri, 14 Jun 2019 23:46:59 -0400

Yup. I like it.

Go for it.

Bill

---

From: William Atwood <[email-masked]>
Date: Fri, 14 Jun 2019 23:47:28 -0400

Yes.

Bill

On 2019-06-14 11:44 p.m., Holland, Jake wrote:
> > is introduced in this document, so this is a new requirement. >