Genart last call review of draft-ietf-mboned-deprecate-interdomain-asm-05

Reviewer: Dale Worley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.  Please treat these comments just like
any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document:  draft-ietf-mboned-deprecate-interdomain-asm-05
Reviewer:  Dale R. Worley
Review Date:  2019-12-21
IETF LC End Date:  2019-12-23
IESG Telechat date:  not set

* Summary:

       This draft is basically ready for publication, but has some
       nits that should be fixed before publication.

* Major issues:

None

* Minor issues:

None of the recommendations are phrased with SHOULD, which I think
would be natural for a BCP.  The word "recommends" is used, and
replacing it with "RECOMMENDS" seems natural, but the RFC 2119 word is
"RECOMMENDED".  I guess you use the passive construction "It is
RECOMMENDED ...".  But perhaps the convention is not to use RFC 2119
words in BCPs.

* Nits/editorial comments: 

Requirements Language and Terminology

This section should be updated from RFC 2119 to RFC 8174.

1.  Introduction

   ... there has been
   no strong recommendation made by the IETF on the appropriateness of
   those models to certain scenarios, even though vendors and
   federations have often made such recommendations.

   This document addresses this gap by making a BCP-level recommendation
   ...

This isn't phrased correctly; it reads as if it is important for the
IETF "to make a strong recommendation" per se, and that is the primary
motivation for this document.  Instead, something like:

   It has become known that SSM is significantly superior to ASM in
   interdomain multicast uses, so this document changes the situation
   by making a BCP-level recommendation to deprecate the use of ASM
   for interdomain multicast, leaving SSM as the recommended
   mode of interdomain multicast.

2.1.  Multicast service models

   Source discovery
   in SSM is handled by some out-of-band mechanism (ie, the application
   layer), ...

s/ie/i.e./

3.1.  Observations on ASM and SSM deployments

   Some of these issues include complex flooding RPF
   rules, state attack protection, and filtering of undesired sources.

I assume "RPF" means "Reverse Path Forwarding" here.

   Support for IGMPv3 and MLDv2 has become widespread
   in common OSes for several years (Windows, MacOS, Linux/Android) and
   is no longer an impediment to SSM deployment.

It's probably worth stating that the large router vendors also support
these protocols.

3.2.2.  No network wide IP multicast group-address management

   receive each others IP multicast traffic.

s/others/other's/  (Or is that "others'"?  Have to check with the Editor!)

4.  Recommendations

   The more inclusive interpretation of this recommendation is that it
   also extends to the case where PIM may only be operated in a single
   operator domain, but where user hosts or non-PIM network edge devices
   are under different operator control.

The use of "inclusive" is a bit ambiguous, as it's not clear whether
the intention is to expand what is deprecated or to expand what is
approved.  I think this can be solved by changing "extends to" to
"also deprecates":

   The more inclusive interpretation of this recommendation is that it
   also deprecates the case where PIM is operated in a single operator
   domain, but where ...

4.4.  Developing application guidance: SSM, ASM, service discovery

   Applications with many-to-many communication patterns can create more
   (S,G) state than feasible for networks, whether the source discovery
   is done by ASM with PIM-SM or at the application level and SSM/PIM-
   SM.

This is unclear to me.  I think you want "at the application level
with SSM/PIM-SM" for parallelism.

But it's also not clear what "more state feasible for networks" means.
I think it means "more state than is feasible for networks to manage",
but that doesn't seem to mesh with "... or at the application level".
Perhaps the meaning is "more state than is feasible to manage".

   Unfortunately, today
   many applications simply use ASM for service discovery.

Probably better to say "many applications use ASM solely for service
discovery", as "simply" could be read in a number of ways.

4.5.  Preferring SSM applications intradomain

   If feasible, it is recommended for applications to use SSM even if
   they are initially only meant to be used in intradomain environments
   supporting ASM.

It seems like the words "If feasible" are reduendant given the meaning
of "recommended" (or at least the meaning of "RECOMMENDED").

4.8.  Not precluding Intradomain ASM

   In the past decade, Bidir-PIM too has seen deployments to scale
   interdomain ASM deployments beyond the capabilities of PIM-SM.

Perhaps change "Bidir-PIM too has seen deployments to scale
interdomain ASM" to "some Bidir-PIM deployments have scaled
interdomain ASM ...".

4.9.  Evolving PIM deployments for SSM

   In general, it is recommended to always use SSM address
   space for SSM applications.

I can see an advantage using "RECOMMENDED" here, to make sure this
sentence is not overlooked.

5.  Future interdomain ASM work

   Such work could modify or amend the recommendations of this document
   (like any future IETF standards/BCP work).

This could mean either

   Such work could modify or amend the recommendations of this document
   (as could any future IETF standards/BCP work).

or

   Such work (e.g., any future IETF standards/BCP work) could modify
   or amend the recommendations of this document.

[END]


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