Last Call Review of draft-ietf-mboned-deprecate-interdomain-asm-05
review-ietf-mboned-deprecate-interdomain-asm-05-rtgdir-lc-andersson-2019-12-22-00

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: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64