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.ch...@jisc.ac.uk> wrote: > > Hi, > > Thanks for the review Dale, comments in-line... > >> On 21 Dec 2019, at 21:10, Dale Worley via Datatracker <nore...@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 _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
