Re: [MBONED] [Gen-art] Genart last call review of draft-ietf-mboned-deprecate-interdomain-asm-05

Dale, thanks for your detailed review. Tim, thanks for addressing Dale’s comments. I entered a No Objection ballot.

Alissa

> On Dec 22, 2019, at 5:09 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
> 
> Hi,
> 
> Thanks for the review Dale, comments in-line...
> 
>> On 21 Dec 2019, at 21:10, Dale Worley via Datatracker <noreply@ietf.org> wrote:
>> 
>> 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.
> 
> That’s a good point; will discuss with the other authors and perhaps check with the RFC Editor.  As another review pointed out, currently the only 2119 language refers to another RFC.
> 
>> * 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.
> 
> Well, I think the discussion in mboned was around the lack of an IETF recommendation.  Personally, I quite like how it is phrased, as it speaks to the rationale for the document being written, but again I’ll check with the other authors.
> 
>> 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./
> 
> Thanks, one less for the RFC Editor :)
> 
>> 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.
> 
> Yes, thanks, other reviews have also suggested we need to do some first use expansions of the acronyms in general in the document.  Will fix in the next rev.
> 
>>  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.
> 
> I think the point being made here is that use of SSM was only made practical once host support was added, and was generally the last piece in the deployment puzzle.  We also ensured that support for MLDv2, as a MUST, was added to the IPv6 Node Requirements RFC update.
> 
>> 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!)
> 
> Probably others’, but yes :)
> 
>> 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 ...
> 
> Or maybe 
> 
> The more inclusive interpretation of this recommendation is that it  
> also extends to deprecating use of ASM in 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".
> 
> I think what we’re trying to say is that if applications create a significant amount of (S,G) state then that may become problematic for networks to manage, particularly where the applications run over multiple domains, or as you say 
> "more state than is feasible for networks 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.
> 
> Yes, I think either of your suggestions would improve that.
> 
>> 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").
> 
> There was some pushback in earlier discussions on this, “if feasible” was added as a compromise.  Ultimately, what an operator does in their own domain is up to them; the main recommendation of this BCP is on the inter-domain use.
> 
>> 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 ...".
> 
> Yes, we could do that.
> 
>> 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.
> 
> We’ll review all use of recommended / RECOMMENDED.
> 
>> 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.
> 
> I think it’s implicitly true wither way :)
> 
> Thanks again!
> 
> Tim
>> 
>> [END]
>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art