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 . 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]