Subject: [RTG-DIR] RtgDir review: draft-ietf-mboned-deprecate-interdomain-asm

From: Loa Andersson <[email-masked]>
Date: Sun, 22 Dec 2019 17:44:51 +0800

Routing Directorate Last Call Review Template
To:

rtg-ads@…
Cc:

rtg-dir@…;
draft-name.all@…;
wg-mailing-list;
Subject:

RtgDir review: draft-ietf-mboned-deprecate-interdomain-asm
Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-mboned-deprecate-interdomain-asm
Reviewer: Loa Andersson
Review Date: date
IETF LC End Date: date-if-known
Intended Status: BCP

Summary:

    This document recommends deprecation of the use of Any-Source
    Multicast (ASM) for interdomain multicast.  It recommends the use of
    Source-Specific Multicast (SSM) for interdomain multicast
    applications and that hosts and routers in these deployments fully
    support SSM.

Major Issues:

No major issues found. On the contrary I think that the document is
well wriiten and comprehensive. My point below are at best minor issues,
but mostly nits.

Actually from a pure technical content point of view everything that
needs to be there is there and the recommendations is as far as
I understand correct.

Minor Issues:

There is a document from the RFC Editor, RFC 7322 "RFC Style guide".
These guidelines should be followed, e.g. the "Requirement Language
should be moved into the body of the document, normally section 1.1.

Someone (AD) should think about if the requirement language is needed in
this Informational document. A "MUST" is used when outlining what
draft-ietf-6man-rfc6434-bis does. but it is not really a requirement
from this document. I'm split about this and could go either way.

Also the new template should be used for 2119 language.

MLDv2 (or MLD) is not a well-know abbreviation and needs to be expanded.

IGMPv3 is well-known, but IGMPv3 is not. Beats me what is required,
but in such cases I always recommend expanding.

"
Nits:

I wonder about this in section 3.1"

"... has become widespread in common OSes for several years (Windows,
MacOS, Linux/Android)..."

Should we say:

"... has become widespread in common Operating Systems for several years
(Windows, MacOS, Linux/Android)..."

Other style issue:

Sometimes IGMPv3 / MLDv2 is used

At other places IGMP/MLD or IGMPv3/MLDv2, I think we should use one
or the other.

Nits tool has two issues, these are addressed in the Shepherd Write-up,
poimting out that updates

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Tim Chown <[email-masked]>
Date: Sun, 22 Dec 2019 09:54:09 +0000

Hi,

Many thanks for the review, comments in-line...

> On 22 Dec 2019, at 09:44, Loa Andersson <[email-masked]> wrote:
> 
> <snip>
> 
> Minor Issues:
> 

Will do.  It seems RFC 7322 recommends a separate section 2 for this after the Introduction.

> from this document. I'm split about this and could go either way.

Perhaps put MUST in “”s in 4.2?  

> MLDv2 (or MLD) is not a well-know abbreviation and needs to be expanded.

Will do.  I think the RFC Editor would pick this up, but we can minimise their work :)

> but in such cases I always recommend expanding.

Not sure what you mean here.

> (Windows, MacOS, Linux/Android)..."

Can do.  

> At other places IGMP/MLD or IGMPv3/MLDv2, I think we should use one

In some places, like 4.2, it is generic IGMP/MLD, but there are others where we should make it more specific, like 3.2.3.

Tim

---

From: Loa Andersson <[email-masked]>
Date: Sun, 22 Dec 2019 23:37:59 +0800

Tim,

Some snall comments, personal opinions and clarifications inline.

> Will do.  It seems RFC 7322 recommends a separate section 2 for this after the Introduction.

I think there is a mismatch between RFC 7332 and what the RFC Editor do.
If you look at RFC 8696, the latest published Standard Track RFC when I
write this. Intyroduction is section 1 and the 2119 language is
section 1.1.

> Perhaps put MUST in “”s in 4.2?

hmmmm - could be something we would want to do, but as I said I would 
take AD advice on this, especially if we intend to remove the 2119
language.

>> but in such cases I always recommend expanding.

Copy and paste error on my side, what I intended to say was

IGMP is well-known, but IGMPv3 is not. Beats me what is required,
but in such cases I always recommend expanding.
Maybe you should do "IGMP version 3 (IGMPv3).
But I'd go with whatever you think we should do.
> In some places, like 4.2, it is generic IGMP/MLD, but there are others where we should make it more specific, like 3.2.3.

Yes, that is right, but what I meant was that sometimes you put a space
on either side of the "/", sometimes not.

/Loa

--

---

From: Tim Chown <[email-masked]>
Date: Mon, 23 Dec 2019 09:31:40 +0000

Hi Loa,

> On 22 Dec 2019, at 15:37, Loa Andersson <[email-masked]> wrote:
> 
> Tim,
> 

OK, thanks, it seems the RFC ~Editor its fine with that, so we can do that.

> hmmmm - could be something we would want to do, but as I said I would take AD advice on this, especially if we intend to remove the 2119
> language.

Will do.  We need to decide whether to go the 2119 path or not and then be consistent.

> But I'd go with whatever you think we should do.

I’ll add more expansions on first use; some others were posted out in another review.  

> on either side of the "/", sometimes not.

Ah, I thought you meant writing MLD or writing MLDv2, not the / and space :).  But I’ll fix up both in the revved version.

Best wishes,
Tim