Deprecating Any-Source Multicast (ASM) for Interdomain Multicast
draft-ietf-mboned-deprecate-interdomain-asm-07

[Ballot comment]
Thanks for this well-written document!

Section 2.1

  to deliver traffic from the sender(s) to the receivers.  If there are
  multiple senders for a given group, traffic from all senders will be
  delivered to the receiver.  Since receivers specify only the group

nit: "receivers" plural.

Section 3.1

  troubleshoot.  Some of these issues include complex flooding Reverse
  Path Forwarding (RPF) rules, state attack protection, and filtering
  of undesired sources.

I'm not sure how to parse "complex flooding Reverse Path Forwarding
(RPF) rules" (but think I could figure out "complex Reverse Path
Forwarding (RPF) flooding rules" -- do I need to try harder?

  within one domain.  While this approach solves the MSDP issues, it
  does not solve the problem of unauthorised sources sending traffic to
  ASM multicast groups; this security issue is one of biggest problems
  of interdomain multicast.

Perhaps it's worth expanding on the security issue as including a
substantial level of traffic amplification.  (Or do I misunderstand the
security issue?)

Section 4.1

  The more inclusive interpretation of this recommendation is that it
  also extends to deprecating use of ASM in the case where PIM is

Are we claiming or disclaiming this "more inclusive interpretation"?
The current wording feels ambiguous, and I don't think we should leave
it that way.

Section 4.2

  support SSM (i.e., explicitly sending source-specific reports).  The
  updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states

nit: the I-D reference is not yet an RFC, so it's not proper to refer to
it as one; since it's only an informative reference we will not
necessarily wait to publish this document until that one has an RFC
number assigned, so I think this should be reworded.  (Also, even if
there was a new RFC number, "updated [...] RFC [RFCXXXX]" would still
scan kind of strangely.)

Section 4.3

  The recommendation to use SSM for interdomain multicast means that
  applications should properly trigger the sending of IGMPv3/MLDv2
  source-specific report messages.  It should be noted, however, there
  is a wide range of applications today that only support ASM.  In many
  cases this is due to application developers being unaware of the
  operational concerns of networks.  This document serves to provide
  clear direction for application developers to support SSM.

Without some discussion of the relative level of difficulty for applications
tosupport SSM (to compare against the well-portrayed problems with network
support for ASM), it would be fairly easy to misread this as network
operators getting an IETF BCP to try to force applications to do what's easy
for the network.  I'm given to understand that's not actually the case here,
as the changes in application software are fairly minor, and no one would
expect existing applications to grow a way to announce multicast source
addresses spontaneously, so a little more text might go a long way.

Section 4.4

  While the WG discussions had consensus that best practices should be
  developed to explain when to use SSM in applications, e.g, when ASM
  without (S,G) state in the network is better, or when dedicated
  service-discovery mechanisms should be used, it was agreed that
  documenting such practices are outside the scope of this document.

It might be possible to rephrase this in terms of "the conclusions of
the MBONED WG" or "the consensus of the MBONED WG"; the current phrasing
feels a little informal to me, though I don't place much weight on my
sentiment here.

Section 4.6

A lot of this section feels somewhat speculative and leaves me uncertain
what the BCP recommendations in this space are.

  In the case of existing ASM applications that cannot readily be
  ported to SSM, it may be possible to use some form of protocol
  mapping, i.e., to have a mechanism to translate a (*,G) join or leave
  to a (S,G) join or leave, for a specific source, S.  The general

nit: I think this would read better with fewer commas, i.e., "to
translate a (*,G) join or leave to a (S,G) join or leave for a specific
source S".

Section 4.9

  it.  This allows easy migration of ASM applications to SSM/PIM-SSM
  solely through application side development to handle source-

nit: hyphenate "application-side".

  signaling via IGMPv3/MLDv2 and using SSM addresses.  No network

Do the application developers also consider this work "easy"? ;)

  When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also
  result in the desired PIM-SSM (S,G) operations and bypass any RP
  procedures, but this is not standardized but depends on
  implementation and may require additional configuration in available
  products.  [...]

nit: this sentence is fairly long and convoluted; could it be reworded
and/or split up into smaller pieces?

  Note that these migration recommendations do not include the
  considerations when or how to evolve those intradomain applications
  best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM.  This may also
  be important but is outside the scope of this document.

nit: is there a missing word ("for"/"about"/"on") after
"considerations"?

  Accordingly, this document recommends that future work for general
  purpose interdomain IP multicast focus on SSM items listed in
  Section 4.

nit: hyphenate "general-purpose".

Section 6

We could perhaps consider mentioning again the consequences of
infrastructure assuming that SSM-range addresses are always used for
SSM, such as during the transition period where applications migrating
from ASM to SSM continue to use ASM-range addresses, as mentioned in
Section 4.7.

Changing the model for intradomain multicast to one where
source discovery/state-propagation is not done by the network and is
instead a responsibility of the application layer means that the
applications are responsible for properly implementing such
functionality.  While it's true that we do want applications to not have
bugs in general (and that would hopefully go without saying), we might
want to discuss the scope of potential issues if applications get this
wrong.  Could application bugs (or bugs in host-level IGMPv3 or MLDv2
implementations) specific to SSM usage lead to any worse problems than
just "application traffic doesn't flow", e.g., state exhaustion in the
network?

Section 10.1

I'm not seeing any references to RFC 4610 that would qualify it as
normative; if normative is indeed the proper status, perhaps additional
citations are in order?

[Ballot comment]
Thanks for this well-written and well-reasoned document. Given the rather limited knowledge I have of the nuts and bolts of how multicast works at the routing layer, I found the text clear and easy to follow.

[Ballot comment]
Thanks for a very clear document that was an easy read.  I just have a few very minor editorial suggestions, which need no specific reply:

— Section 2.1 —

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

The “i.e.” seems a bit odd here to my eye.  I’d suggest wording this without the parentheses altogether, thus:

NEW
  Source discovery
  in SSM is handled by some out-of-band mechanism in the
  application layer
END

— Section 2.3 —

  PIM-SSM expects that the sender's source address(es) is known in
  advance by receivers

The “is” sounds odd with “addresses”, and it’s always difficult to know what to do for number agreement with things such as “address(es)”.  I suggest writing around the problem this way:

NEW
  PIM-SSM expects the sender's source address(es) to be known in
  advance by receivers
END

— Section 3.2.2 —
There needs to be a hyphen in “network-wide”.

— Section 4.1 —

  This document recommends that the use of ASM is deprecated for
  interdomain multicast

This needs subjunctive mood: “that the use of ASM be deprecated”.

[Ballot comment]
** Section 4.1.  This section appears to provide multiple definitions of “separate administrative entities”.  Per the paragraph “The more inclusive interpretation of this recommendation …”, it wasn’t clear to me under what circumstance the reader should use the more “inclusive interpretation”.

** Section 4.  This section would benefit from being clearer on who should act on a few of the recommendation:

-- Section 4.3 – vendors/developers of multicast applications?

-- Section 4.4 – not clear who is supposed to develop this guidance? 

-- Section 4.6 – not clear who is supposed to developing this guidance long term

** Editorial Nits:
-- Section 3.2.3. Typo. s/particularily/particularly/

-- Section 4.9.  Typo. s/implentations/implementations/

[Ballot comment]
A couple of suggestions to help the document be more timeless:

= Section 2.2.1 =

s/To this day/At the time of this writing/

= Section 4.4 =

OLD
While the WG discussions had consensus that best practices should be
  developed to explain when to use SSM in applications, e.g, when ASM
  without (S,G) state in the network is better, or when dedicated
  service-discovery mechanisms should be used, it was agreed that
  documenting such practices are outside the scope of this document.

NEW
This document describes best practices to explain when to use SSM in applications, e.g, when ASM without (S,G) state in the network is better, or when dedicated service-discovery mechanisms should be used, but specifying these practices is outside the scope of this document.

[Ballot comment]
Thanks for this well-written document.

I'm by far no expert here but reading this document it sounds a bit like RFC3618 should be moved to historic... was that discussed?

This document seem not to use normative RFC2119 language but I think could benefit from it. Was that considered?

[Ballot comment]
Thank you for the work put into this document. The document is really easy to read with a nice introduction. I trust the responsible AD and my routing colleagues on their evaluation whether it is reasonable, sensible and useful to deprecate ASM in interdomain deployments.

Regards,

-éric

== COMMENTS ==
Mostly a DISCUSS but really trivial to fix, please refer to RFC 8174 in addition to RFC 2119.

Also, AFAIK, Toerless is affiliated to Futurewei and not Huawei, please fix his affiliation in the header.

== NITS ==

-- Section 2.3 --
Please use lowercase in IPv6 addresses.

[Ballot comment]
Thank you for the work put into this document. The document is really easy to read with a nice introduction. I trust the responsible AD and my routing colleagues on their evaluation whether it is reasonable, sensible and useful to deprecate ASM in interdomain deployments.

Regards,

-éric

== COMMENTS ==
Mostly a DISCUSS but really trivial to fix, please refer to RFC 8174 in addition to RFC 2119.

Also, AFAIK, Toerless is affiliated to Futurewei and not Huawei, please fix his affiliation in the header.

-- Section 8 --
Should also contain IPv6 examples.

== NITS ==

-- Section 2.3 --
Please use lowercase in IPv6 addresses.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mboned-deprecate-interdomain-asm-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-12-23):

From: The IESG
To: IETF-Announce
CC: draft-ietf-mboned-deprecate-interdomain-asm@ietf.org, cdoyle@juniper.net, mboned@ietf.org, mboned-chairs@ietf.org, warren@kumari.net, Colin Doyle
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Deprecating ASM for Interdomain Multicast) to Best Current Practice


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document: - 'Deprecating ASM for Interdomain Multicast'
  as Best Current
  Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-12-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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.  The recommendations in this document do not preclude
  the continued use of ASM within a single organisation or domain and
  are especially easy to adopt in existing intradomain ASM/PIM-SM
  deployments.

Requirements Language and Terminology



The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mboned-deprecate-interdomain-asm/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mboned-deprecate-interdomain-asm/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (Proposed Standard - IETF stream)
    rfc3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address (Proposed Standard - IETF stream)
    rfc4607: Source-Specific Multicast for IP (Proposed Standard - IETF stream)
    rfc4610: Anycast-RP Using Protocol Independent Multicast (PIM) (Proposed Standard - IETF stream)
    rfc3307: Allocation Guidelines for IPv6 Multicast Addresses (Proposed Standard - IETF stream)
    rfc3376: Internet Group Management Protocol, Version 3 (Proposed Standard - IETF stream)

Changes are expected over time. This version is dated 6 June 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

***
BCP

The type of RFC is not indicated in the title page header, but is referred
to in the Introduction.

BCP is the appropriate type for this RFC as it provides guidance for
deprecating ASM and using only SSM for interdomain multicast.
***


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that there
are deficiencies in the abstract or introduction.

***
This document recommends a BCP for deprecation and replacement of
Any-Source Multicast (ASM) methods for interdomain multicast with
Source-Specific Multicast (SSM). This document additionally recommends
host/network support for Internet Group Messaging Protocol version 3
(IGMPv3) and Multicast Listener Discovery version 2 (MLDv2). Further
guidance for these protocols can be found in [ RFC4604 ].

Scale limitations of the commonly used Sparse-Mode (PIM-SM)/Multicast
Source Discovery Protocol (MSDP) ASM architecture are appropriately
highlighted as the premise for this recommendation. Design comparisons,
highlighting practical and operational improvements using an SSM-based
interdomain multicast design are appropriate and informative.

This document makes no recommendations for intradomain multicast.
***


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

***
There was some initial concern from a few individuals that ASM was still
useful in intradomain deployments.  The authors resolved these concerns by
making it clear throughout the doc that this recommendation to deprecate
ASM applies only to interdomain deployments and makes no recommendations
for intradomain multicast deployments.  Other than this, no other
controversies with this document were noted.


***


Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification? Are
there any reviewers that merit special mention as having done a thorough
review, e.g., one that resulted in important changes or a conclusion that
the document had no substantive issues? If there was a MIB Doctor, Media
Type or other expert review, what was its course (briefly)? In the case of
a Media Type review, on what date was the request posted?

***
Document is well written, defining a clear problem statement and
supporting scenarios and examples for the core recommendations.
Assumptions regarding the future-state of ASM protocols are appropriately
highlighted, and the impact on the document recommendations are addressed.
***


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

***

  Document shepherd: Colin Doyle
  Responsible AD: Warren Kumari

***


(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

***
I have read the draft and reviewed the minutes and etherpad records for
the mboned WG. This draft is supported by participants and
uncontroversial.
***


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

***
No
***


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

***
No. Recommendations defined are appropriate and supported. Future
adjustments to these recommendations based on protocol and standards
development are accounted for.
***


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.
***
I have no concerns that warrant review, although I would expect the usual
slow adoption cycle of the protocols required by the recommendations in
this document by providers and, to a lesser extent, manufacturers. This
document posits that support for these protocols (IGMPv3 and MLDv2) is
"widespread" in common OS's. This is an optimistic supposition that
naturally assumes that devices running common OS's are running current
versions. As this document lays out no specific timeline for deprecating
multidomain ASM, this consideration becomes largely academic.
***


(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have already been filed. If not, explain why?
***

Each author has confirmed that he is not aware of any IPR:
https://mailarchive.ietf.org/arch/msg/mboned/T6DCvcLuGglbHc212liB40h2pT8
https://mailarchive.ietf.org/arch/msg/mboned/KKKsdjlHwN5nCne2qmPbb7VXoTw
https://mailarchive.ietf.org/arch/msg/mboned/y01M8iGyoLFm-f-sGTGEAKZzOFQ
https://mailarchive.ietf.org/arch/msg/mboned/EMG62prrTbj5D1JufUqHY5a5KY4

No IPR disclosures from anyone else in the WG were noted.

***


(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.
***

Each author has confirmed that he is not aware of any IPR.  No IPR
disclosures from anyone else in the WG were noted.

***


(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?
***
Consensus is strong. Areas of discussion were found to be largely around
the scope and forcefulness of the recommendation as it related to
intradomain multicast. Ultimately, the language recommending deprecation
of ASM for intradomain multicast were removed.

"I think it's important that we don't water down the recommendation so
much that the message gets lost.  My pref would be to strongly recommend
SSM (and thus, no-ASM) for interdomain and provide some gentle nudging for
SSM in intradomain, while recognizing that what one does in his own
network is his own business.  We can't really mandate/decree, but it is
our role/responsibility to provide guidance and recommendations based on
our expertise." - Tim Chown
***


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
***
No
***


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
***
Nits check was run against version 5 of this draft.
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-mboned-deprecate-interdomain-asm-05.txt
Nit regarding multicast addresses can be disregarded as document is
referencing the complete multicast ipv4 range and not a generic example
multicast address.
Nit regarding age of document is assumed trivial and disregarded. Version
reviewed is current.
Nit regarding draft publication should result in an edit/update. On line
377, 705, and 707, draft-ietf-6man-rfc6434-bis is referenced. This draft
has been published as RFC8504.
***


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.
***
No review required
***


(13) Have all references within this document been identified as either
normative or informative?
***
Yes
***


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
***
No, but an edit to the document is required. All references are currently
in RFC status. The reference to "I-D.ietf-6man-rfc6434-bis" should be
updated to reflect the published RFC8504.
***


(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the
Last Call procedure.
***
None based on my review.
***


(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.
***
No. This document provides BCP recommendations using existing protocols,
standards, and RFC's.
***


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed specification of the
initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 8126).
***
No request of IANA are made or required by this document per section 7.
***


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.
***
No new IANA registries are required by this document per section 7.
***


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
***
n/a
***

Changes are expected over time. This version is dated 6 June 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

***
BCP

The type of RFC is not indicated in the title page header, but is referred
to in the Introduction.

BCP is the appropriate type for this RFC as it provides guidance for
deprecating ASM and using only SSM for interdomain multicast.
***


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that there
are deficiencies in the abstract or introduction.

***
This document recommends a BCP for deprecation and replacement of
Any-Source Multicast (ASM) methods for interdomain multicast with
Source-Specific Multicast (SSM). This document additionally recommends
host/network support for Internet Group Messaging Protocol version 3
(IGMPv3) and Multicast Listener Discovery version 2 (MLDv2). Further
guidance for these protocols can be found in [ RFC4604 ].

Scale limitations of the commonly used Sparse-Mode (PIM-SM)/Multicast
Source Discovery Protocol (MSDP) ASM architecture are appropriately
highlighted as the premise for this recommendation. Design comparisons,
highlighting practical and operational improvements using an SSM-based
interdomain multicast design are appropriate and informative.

This document makes no recommendations for intradomain multicast.
***


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

***
There was some initial concern from a few individuals that ASM was still
useful in intradomain deployments.  The authors resolved these concerns by
making it clear throughout the doc that this recommendation to deprecate
ASM applies only to interdomain deployments and makes no recommendations
for intradomain multicast deployments.  Other than this, no other
controversies with this document were noted.


***


Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification? Are
there any reviewers that merit special mention as having done a thorough
review, e.g., one that resulted in important changes or a conclusion that
the document had no substantive issues? If there was a MIB Doctor, Media
Type or other expert review, what was its course (briefly)? In the case of
a Media Type review, on what date was the request posted?

***
Document is well written, defining a clear problem statement and
supporting scenarios and examples for the core recommendations.
Assumptions regarding the future-state of ASM protocols are appropriately
highlighted, and the impact on the document recommendations are addressed.
***


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

***

  Document shepherd: Colin Doyle
  Responsible AD: Warren Kumari

***


(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

***
I have read the draft and reviewed the minutes and etherpad records for
the mboned WG. This draft is supported by participants and
uncontroversial.
***


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

***
No
***


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

***
No. Recommendations defined are appropriate and supported. Future
adjustments to these recommendations based on protocol and standards
development are accounted for.
***


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.
***
I have no concerns that warrant review, although I would expect the usual
slow adoption cycle of the protocols required by the recommendations in
this document by providers and, to a lesser extent, manufacturers. This
document posits that support for these protocols (IGMPv3 and MLDv2) is
"widespread" in common OS's. This is an optimistic supposition that
naturally assumes that devices running common OS's are running current
versions. As this document lays out no specific timeline for deprecating
multidomain ASM, this consideration becomes largely academic.
***


(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have already been filed. If not, explain why?
***

Each author has confirmed that he is not aware of any IPR:
https://mailarchive.ietf.org/arch/msg/mboned/T6DCvcLuGglbHc212liB40h2pT8
https://mailarchive.ietf.org/arch/msg/mboned/KKKsdjlHwN5nCne2qmPbb7VXoTw
https://mailarchive.ietf.org/arch/msg/mboned/y01M8iGyoLFm-f-sGTGEAKZzOFQ
https://mailarchive.ietf.org/arch/msg/mboned/EMG62prrTbj5D1JufUqHY5a5KY4

No IPR disclosures from anyone else in the WG were noted.

***


(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.
***

Each author has confirmed that he is not aware of any IPR.  No IPR
disclosures from anyone else in the WG were noted.

***


(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?
***
Consensus is strong. Areas of discussion were found to be largely around
the scope and forcefulness of the recommendation as it related to
intradomain multicast. Ultimately, the language recommending deprecation
of ASM for intradomain multicast were removed.

"I think it's important that we don't water down the recommendation so
much that the message gets lost.  My pref would be to strongly recommend
SSM (and thus, no-ASM) for interdomain and provide some gentle nudging for
SSM in intradomain, while recognizing that what one does in his own
network is his own business.  We can't really mandate/decree, but it is
our role/responsibility to provide guidance and recommendations based on
our expertise." - Tim Chown
***


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
***
No
***


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
***
Nits check was run against version 5 of this draft.
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-mboned-deprecate-interdomain-asm-05.txt
Nit regarding multicast addresses can be disregarded as document is
referencing the complete multicast ipv4 range and not a generic example
multicast address.
Nit regarding age of document is assumed trivial and disregarded. Version
reviewed is current.
Nit regarding draft publication should result in an edit/update. On line
377, 705, and 707, draft-ietf-6man-rfc6434-bis is referenced. This draft
has been published as RFC8504.
***


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.
***
No review required
***


(13) Have all references within this document been identified as either
normative or informative?
***
Yes
***


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
***
No, but an edit to the document is required. All references are currently
in RFC status. The reference to "I-D.ietf-6man-rfc6434-bis" should be
updated to reflect the published RFC8504.
***


(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the
Last Call procedure.
***
None based on my review.
***


(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.
***
No. This document provides BCP recommendations using existing protocols,
standards, and RFC's.
***


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed specification of the
initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 8126).
***
No request of IANA are made or required by this document per section 7.
***


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.
***
No new IANA registries are required by this document per section 7.
***


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
***
n/a
***