DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery
draft-ietf-mboned-driad-amt-discovery-13

[Ballot comment]
Thank you for this well-written document!  My comment are all pretty
minor (and many of them are more of a "side note" than actionable
comments, anyway...).

Section 1

  This document updates Section 5.2.3.4 of [RFC7450] by adding a new
  extension to the relay discovery procedure.

I know that there is not a universal usage of "updates", but note that
in other protocols with similar scenarios (multiple possible discovery
methods), the core protocol document is not always in an "Updated by"
relationship with the new discovery methods.  (That said, there seem to
be plenty of other ways in which this document updates RFC 7540, so this
particular instsance isn't a big deal.)

Section 1.2.2

  |    L flag | The "Limit" flag described in Section 5.1.1.4 of    |
  |            | [RFC7450]                                            |

nit: s/5.1.1.4/5.1.4.4/

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in
  [RFC2119] and [RFC8174] when, and only when, they appear in all
  capitals, as shown here.

nit: this is not quite the prescribed form from RFC 8174.

Section 2.2

Perhaps it's worth a brief note that the UDP unicast tunnel is over IPv6
even though the multicast traffic being conveyed is native IPv4 in both
multicast networks?

Section 2.3.2

      A related motivating example in the sending-side network is
      provided by considering a sender that needs to instruct the
      gateways on how to select between connecting to Figure 6 or
      Figure 7 (from Section 3.2), in order to manage load and failover
      scenarios in a manner that operates well with the sender's
      provisioning strategy for horizontal scaling of AMT relays.

I don't think I understand what "connecting to Figure 6" means.

  Among relay addresses that have an equivalent preference as described
  above, a Happy Eyeballs algorithm for AMT SHOULD use use the
  Destination Address Selection defined in Section 6 of [RFC6724].

  Among relay addresses that still have an equivalent preference after
  the above orderings, a gateway SHOULD make a non-deterministic choice

side note: I think that the way RFC 6724 is written (as a series of
comparison rules), it doesn't have an "are equivalent preference"
option, just a "leave the order unchanged" one.  But that's probably a
useless pedantic distinction and I can't see an actionable change that
would result from it.

Section 2.7

  The DNS query functionality is expected to follow ordinary standards
  and best practices for DNS clients.  A gateway MAY use an existing
  DNS client implementation that does so, and MAY rely on that client's
  retry logic to determine the timeouts between retries.

The first part of this seems to be a duplication of Section 2.4.2, but
the latter part (and following paragraph/sentences) diverges.  There's
probably some room for consolidation and/or harmonization of procedures
here.

Section 4.2.4

(Presumably we ignore entires with unrecognized 'type'; I forget whether
this is standard DNS usage or we should mention it explicitly, though.)

Section 5

Is there any guidance to give to the Designated Experts in addition to
the default rules from RFC 8126?

Section 6

I like that the relay-discovery precedence rules minimize the
opportunity for an attacker to disrupt discovery and try to force a
different relay to be used (whether to afford an opportunity to tamper
with the traffic going to a target recipient or other reasons).  Since
we are updating the generic AMT relay discovery procedure, we could
reasonably mention that (and the generic risks with discovery procedures
that involve attempting to contact a relay and failing over if a timely
response does not appear); RFC 7450's Section 6.2 provides only a
minimal mention.  That said, most of the security considerations
relevant here seem to be ones that apply to stock AMT, and are tolerably
covered in RFC 7450.  I'm a little surprised that Happy Eyeballs doesn't
cover this sort of disruption in its security considerations; I was
going to suggest referencing that as well.

We briefly mention active/active failover in Section 2.3.3, and such a
scheme poses some risk of (additional) traffic duplication around a
failover event, but (1) that can happen with UDP anyway, so it will
already be handled, and (2) it's a pretty tenuous hook to say that we
need to talk about the security considerations of such a situation.

Also on the borderline of worth mentioning, an attacker might attempt to
force a gateway to repeatedly go through the relay discovery process; I
don't think this process is sufficiently resource-intensive that it
would be a usable DoS attack, though, so there's not really much there
other than the generic "disruption" that is already covered in 7450.

Section 6.2

Even though not all of the listed mechanisms are currently specified for
recursive-to-authoritative queries, I think it's fine to list them here,
as they are expected to become defined in the future and would make
sense as options, when available.

  response from the trusted server.  The connection to the trusted
  server can use any secure channel, such as with a TSIG [RFC2845] or
  SIG(0) [RFC2931] channel, a secure local channel on the host, DNS
  over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism
  that provides authentication of the RR.

I don't think that it's really "authentication" that we're providing for
the RR itself; what we want is more of "source authentication" for the
provenance of the RR (and integrity protection for its contents).

  If an AMT gateway accepts a maliciously crafted AMTRELAY record, the
  result could be a Denial of Service, or receivers processing
  multicast traffic from a source under the attacker's control.

Even for an honest AMTRELAY record, isn't there a chance that the
multicast traffic's contents could also be modified or injected by the
attacker?

Section 8.2

Arguably RFC 8499 would be normative, since we defer to its definition
of FQDN, but I am not really very concerned about it.

Appendix A

    $ ./translate.py amtrelays.example.com
    24
    09616d7472656c617973076578616d706c6503636f6d
 

  The length and the hex string for the domain name
  "amtrelays.example.com" are the outputs of this program, yielding a
  length of 22 and the above hex string.

I'm having a hard time parsing this in a consistent way where the
yielded length is 22 and the literal command output is 24.

[Ballot comment]
Thanks for the work that went into creating this document! This approach to
multicast tunnel establishment sounds quite useful, and I hope it sees broad
adoption.

---------------------------------------------------------------------------

Please expand "AMT" in the title.

---------------------------------------------------------------------------

§2.2:

>                        Figure 2: DRIAD Messaging

This example uses IPv4 rather than IPv6. Please either add a similar diagram
showing IPv6 usage, or change this diagram to use IPv6. See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for further information.

---------------------------------------------------------------------------

§2.6:

>  AMTRELAY records MAY also appear in other
>  zones...

What would this mean? Is this intended for future specifications to
take advantage, or is the document assuming that the reader is able
to figure out the semantics of AMTRELAY RRs elsewhere in the DNS tree?
If the latter, please spell it out explicitly. If the former, please
indicate that using records in this way may be specified in future
documents.

[Ballot discuss]
I think this should be easy to clear up but I think the following text is vague and needs be clarified

"  Among relay addresses that have an equivalent preference as described
  above, a Happy Eyeballs algorithm for AMT MUST use the Destination
  Address Selection defined in Section 6 of [RFC6724], as required by
  [RFC8305]."

Does this mean that the addresses are sorted as defined in Section 6 of [RFC6724] or as defined in Section 4 of [RFC8305] that defines further steps on top of RC6724 including ordering by RTTs, address family interleaving etc. I think this needs to be stated explicitly.

[Ballot comment]
I had the same question as Barry regarding the "non-deterministic choice" wording in the draft. I think it would be good if you can be more specific here.

[Ballot comment]
Section 2.2.  Step #1 of the text describing the data flow of Figure 2 references the address 232.252.0.2, but that address isn’t used in Figure 2.

[Ballot comment]
— Section 2.2 —

  1.  The end user starts the app, which issues a join to the (S,G):
      (198.51.100.15, 232.252.0.2).

What is 232.252.0.2, and where did it come from?  It would be good for the text to introduce that.


— Section 2.3.2 —

  Among relay addresses that still have an equivalent preference after
  the above orderings, a gateway MUST make a non-deterministic choice
  for relay preference ordering, in order to support load balancing by
  DNS configurations that provide many relay options.

What do you have in mind here?  Random selection?  Something else?  If so, what else that can be assured to be non-deterministic, given the "MUST"?

[Ballot comment]
Jake,

Thank you for the work put into this document. Quite an achievement for a single author !

Please find below some non-blocking COMMENTs and NITs. I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2.4.2 --
At the end, the text
"its default settings MUST NOT permit more
  than 10 queries for any 100-millisecond period (though this MAY be
  overridable by administrative configuration)."
should probably use a "SHOULD NOT" rather than a "MUST NOT" as it "MAY" be overridden.

The last paragraph is a little unclear whether the AMT gateway should wait until all DNS replies are received before initiating AMT connection.

-- Section 2.5.3 --
The whole section about tunnel stability has little to do, IMHO, with neither the title of the document "DNS Reverse IP AMT Discovery" nor with the abstract. The content is useful and should perhaps be moved to another companion document. I understand that this is a little late in the process so let's change the abstract at least. Note: I considered balloting a DISCUSS on this issue.

-- Section 3.1.1 --
Please expand CMTS & OLT used in figure 3

-- Section 3.1.2 --
Unsure whether this is a common use-case in 2019 but it is OK (I hope that my ISP was mcast-capable...).

-- Section 4.1 --
Should the code 260 be allocated by IANA? I would rather use 'TBD' in the document and ask for IANA allocation for 'TBD'

== NITS ==

-- Section 2.1 --
s/The sender/The multicast source/ ?

-- Section 4.2.2 --
Please use the canonical format for IPv6 address. I know this is cosmetic but it hurts my eyes ;-)

[Ballot comment]
UPDATE: Actually I saw the replies to the TSV-ART review but the discussed changes where not yet implemented in the current draft version. So I assume that will happen in the nest version! Thanks!

Thanks for addressing the TSV-ART review (and thanks Bernard for the review!)! Based and in addition to that review, I have a few more small comments:

1) Minor wording comment on this point in 2.5.2:
"  8.  When congestion or substantial loss is detected in the stream of
      AMT packets from a relay."
I think is should be "substantial congestion or substantial loss" or just "substantial congestion".
But actually I would even maybe say "substantial and persistent congestion" or maybe even use "(network) overload" instead of "congestion" because I think that what you are actually looking for.

2) And on this sentence in section 2.7 again:
"with a RECOMMENDED initial_timeout
  of 1 second and a RECOMMENDED maximum_timeout of 120 seconds."
Why do you even specify a max value at all? I think it's more common to define an initial value and a max number of retries.

3) I have an additional question on this part in 2.4.2:
"Otherwise, a gateway MUST provide a rate limit
  for the DNS queries, and its default settings MUST NOT permit more
  than 10 queries for any 100-millisecond period (though this MAY be
  overridable by administrative configuration)."
Where do these numbers come from?

4) Editorial: I would recommend to have the examples (section 3) before section 2. And I saw that there is one normative requirement in the examples section (3.2.2.); that's easy to overlook. I would recommend to move it somewhere as or make it not normative.

5) Sec 6.3:
"Application implementors and network operators that use DRIAD-capable
  AMT gateways..."
Thanks for noting this down. However, I'm wondering if DRIAD-capable AMT gateways are in this respective any different that non-DRIAD-capable AMT gateways?
However, I think would be good or actually is needed to point to and discuss section 4.1.4.2.  on Congestion Considerations in RFC7450!
Further regarding the security consideration in general I would also recommend to point to the security considerations section of RFC7450 and double-check if there is no change based on the potential different location of the reply (than assumed in RFC7450).

6) (Important) nit:
In section 2.4.2:
"When present, IP addresses in the initial response provide resolved
  destination address candidates for the "Sorting of resolved
  destination addresses" phase described in Section 4 of [RFC8085]),"
and
"and attempts connections with the corresponding relays
  under the algorithm restrictions and guidelines given in [RFC8085]
  for the "Establishment of one connection, which cancels all other
  attempts" phase."
These should be references to RFC8305 (and not RFC8085).

[Ballot comment]
Update: Actually I saw the replies to the TSV-ART review but the discussed changes where not yet implemented in the current draft version. So I assume that will happen in the nest version! Thanks!

Thanks for addressing the TSV-ART review (and thanks Bernard for the review!)! Based and in addition to that review, I have a few more small comments:

1) Minor wording comment on this point in 2.5.2:
"  8.  When congestion or substantial loss is detected in the stream of
      AMT packets from a relay."
I think is should be "substantial congestion or substantial loss" or just "substantial congestion".
But actually I would even maybe say "substantial and persistent congestion" or maybe even use "(network) overload" instead of "congestion" because I think that what you are actually looking for.

2) And on this sentence in section 2.7 again:
"with a RECOMMENDED initial_timeout
  of 1 second and a RECOMMENDED maximum_timeout of 120 seconds."
Why do you even specify a max value at all? I think it's more common to define an initial value and a max number of retries.

3) I have an additional question on this part in 2.4.2:
"Otherwise, a gateway MUST provide a rate limit
  for the DNS queries, and its default settings MUST NOT permit more
  than 10 queries for any 100-millisecond period (though this MAY be
  overridable by administrative configuration)."
Where do these numbers come from?

4) Editorial: I would recommend to have the examples (section 3) before section 2. And I saw that there is one normative requirement in the examples section (3.2.2.); that's easy to overlook. I would recommend to move it somewhere as or make it not normative.

5) Sec 6.3:
"Application implementors and network operators that use DRIAD-capable
  AMT gateways..."
Thanks for noting this down. However, I'm wondering if DRIAD-capable AMT gateways are in this respective any different that non-DRIAD-capable AMT gateways?
However, I think would be good or actually is needed to point to and discuss section 4.1.4.2.  on Congestion Considerations in RFC7450!
Further regarding the security consideration in general I would also recommend to point to the security considerations section of RFC7450 and double-check if there is no change based on the potential different location of the reply (than assumed in RFC7450).

6) (Important) nit:
In section 2.4.2:
"When present, IP addresses in the initial response provide resolved
  destination address candidates for the "Sorting of resolved
  destination addresses" phase described in Section 4 of [RFC8085]),"
and
"and attempts connections with the corresponding relays
  under the algorithm restrictions and guidelines given in [RFC8085]
  for the "Establishment of one connection, which cancels all other
  attempts" phase."
These should be references to RFC8305 (and not RFC8085).

[Ballot comment]
Thanks for addressing the TSV-ART review (and thanks Bernard for the review!)! Based and in addition to that review, I have a few more small comments:

1) Minor wording comment on this point in 2.5.2:
"  8.  When congestion or substantial loss is detected in the stream of
      AMT packets from a relay."
I think is should be "substantial congestion or substantial loss" or just "substantial congestion".
But actually I would even maybe say "substantial and persistent congestion" or maybe even use "(network) overload" instead of "congestion" because I think that what you are actually looking for.

2) And on this sentence in section 2.7 again:
"with a RECOMMENDED initial_timeout
  of 1 second and a RECOMMENDED maximum_timeout of 120 seconds."
Why do you even specify a max value at all? I think it's more common to define an initial value and a max number of retries.

3) I have an additional question on this part in 2.4.2:
"Otherwise, a gateway MUST provide a rate limit
  for the DNS queries, and its default settings MUST NOT permit more
  than 10 queries for any 100-millisecond period (though this MAY be
  overridable by administrative configuration)."
Where do these numbers come from?

4) Editorial: I would recommend to have the examples (section 3) before section 2. And I saw that there is one normative requirement in the examples section (3.2.2.); that's easy to overlook. I would recommend to move it somewhere as or make it not normative.

5) Sec 6.3:
"Application implementors and network operators that use DRIAD-capable
  AMT gateways..."
Thanks for noting this down. However, I'm wondering if DRIAD-capable AMT gateways are in this respective any different that non-DRIAD-capable AMT gateways?
However, I think would be good or actually is needed to point to and discuss section 4.1.4.2.  on Congestion Considerations in RFC7450!
Further regarding the security consideration in general I would also recommend to point to the security considerations section of RFC7450 and double-check if there is no change based on the potential different location of the reply (than assumed in RFC7450).

6) (Important) nit:
In section 2.4.2:
"When present, IP addresses in the initial response provide resolved
  destination address candidates for the "Sorting of resolved
  destination addresses" phase described in Section 4 of [RFC8085]),"
and
"and attempts connections with the corresponding relays
  under the algorithm restrictions and guidelines given in [RFC8085]
  for the "Establishment of one connection, which cancels all other
  attempts" phase."
These should be references to RFC8305 (and not RFC8085).

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

The IANA Functions Operator has completed its review of draft-ietf-mboned-driad-amt-discovery-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that upon approval of this document, there are two actions to be completed.

First, in the Resource Record (RR) TYPEs registry on the Domain Name System (DNS) Parameters registry page located at

https://www.iana.org/assignments/dns-parameters/

the following registration will have its reference updated to point to the most recent version of this document:

TYPE: AMTRELAY
Value: 260
Meaning: Automatic Multicast Tunneling Relay
Reference: [ RFC-to-be ]
Template:https://www.iana.org/assignments/dns-parameters/AMTRELAY/amtrelay-completed-template
Registration Date: 2019-02-06

Second, a new registry page called "AMTRELAY Resource Record Parameters" will be created.

IANA Question --> Should the new registry be filed under the "Domain Name System (DNS) Parameters" category at https://www.iana.org/protocols, or will it have its own category?

The following new registry will be created at the new registry page:

Registry Name: Relay Type Field
Registration Procedure: Specification Required
Reference: [ RFC-to-be ]

+-------+---------------------------------------+---------------+
| Value | Description | Reference |
+-------+---------------------------------------+---------------+
| 0 | No relay is present. | [ RFC-to-be ] |
| 1 | A 4-byte IPv4 address is present | [ RFC-to-be ] |
| 2 | A 16-byte IPv6 address is present | [ RFC-to-be ] |
| 3 | A wire-encoded domain name is present | [ RFC-to-be ] |
| 4-255 | Unassigned | |
+-------+---------------------------------------+---------------+

The IANA Functions Operator understands that these are the only actions required  upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

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

From: The IESG
To: IETF-Announce
CC: tim.chown@jisc.ac.uk, Tim Chown , mboned@ietf.org, draft-ietf-mboned-driad-amt-discovery@ietf.org, mboned-chairs@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Reverse IP AMT Discovery) to Proposed Standard


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document: - 'DNS Reverse IP AMT Discovery'
  as Proposed Standard

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-02. 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 updates RFC 7450 (Automatic Multicast Tunneling, or
  AMT) by extending the relay discovery process to use a new DNS
  resource record named AMTRELAY when discovering AMT relays for
  source-specific multicast channels.  The reverse IP DNS zone for a
  multicast sender's IP address is configured to use AMTRELAY resource
  records to advertise a set of AMT relays that can receive and forward
  multicast traffic from that sender over an AMT tunnel.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/ballot/


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

(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?

Proposed Standard.
This is the appropriate RFC type given the protocol extensions defined within the document.

(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:

This document extends Automatic Multicast Tunnelling (AMT, RFC 7450) to allow the relay discovery process to use a new AMTRELAY DNS resource record for discovering source-specific multicast channels.  This allows a set of AMT relays that can receive and forward multicast traffic from a sender to be advertised via reverse IP entries in DNS, hence the DNS Reverse IP AMT Discovery or DRIAD name. 

Working Group Summary:

There was no particular controversy in the WG process, and consensus was good.

Document Quality:

The document is well written, explaining the basic mode of operation clearly, and including many example use cases.

Personnel:

The document shepherd is Tim Chown (tim.chown@jisc.ac.uk), and the responsible AD is 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, reviewed recent WG list discussion, and am happy that it is ready overall to be advanced to the IESG.

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

(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 am happy overall with the document.

I would suggest that the text in 2.3.1 on applying a Happy Eyeballs algorithm where there are multiple choices for the relay be expanded; it is very vague at present.  I presume that this may result in multiple unicast AMT streams coming in to a given gateway, and all but one of these would be pruned back, but some specifics on that, and how the preferred stream is retained, would be useful. This also needs to be set against the proposed active/active failover mode described in 2.4.3.

While maximising the multicast portion of the path will avoid data duplication over unicast tunnels, using a relay close to the source (and known to the source such that it can be added to the DNS reverse zone) has some management benefits.  It’s an interesting trade-off.  The document proposes mechanism(s) to discover topologically close relays; with hindsight perhaps this, and aspects such as handling active/active failover, should have been covered in a separate document to a basic DNS RR specification that assumes a single gateway and single relay near the source.

(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?

Yes. See https://mailarchive.ietf.org/arch/msg/mboned/Y2xm-oXRFhzKmSXgdu7MrmvaTKc

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

No.

(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 good, with no opposition to publication, but mboned is a relatively small WG with a generally low attendance at meetings.  The WGLC in June passed but needed a prod from the WG chairs and another poke from Warren as the AD to get additional responses - see https://mailarchive.ietf.org/arch/msg/mboned/5OzJMfSfWvWq6Nu-SPqdxCMLjSw

Those who did comment were favourable, for example - “This is a very useful addition to the AMT toolkit, which should encourage the deployment of multicast services.  I therefore support its adoption enthusiastically.” - William Atwood.

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

I ran a nits check on the -08 version.  See https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-mboned-driad-amt-discovery-08.txt
The two warnings about IPv4 literal and multicast addresses appear to be spurious.  This was discussed by the author at https://mailarchive.ietf.org/arch/msg/mboned/G6rBrnc9u4YCBniAOnZf1-iTQqw
It looks like the nit checker needs a tweak for SSM?
Otherwise, the document passes all nit checks.

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

No such reviews are 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, all references are at RFC status.

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

None apparent.

(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. Though it does update RFC 7450 by providing a specific DNS-based mechanism for AMT relay discovery.


(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 5226).

The IANA Considerations are covered in Section 5.
The document requests a new DNS Resource Record Type of type 260.
This type is already listed at https://www.iana.org/assignments/dns-parameters/dns-parameters.xml, the reservation of which appears consistent with the document.
There is a sub-registry for the Relay Type field, for which four of 256 possible values are defined.

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

The Relay Type field may potentially have additional values assigned in the future; as above four of 256 values are defined, the rest (4-255) are unassigned.  The document states that Expert Review would be required for these, as per Section 4.6 (policy of Specification Required) of RFC 8126.

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

(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?

Proposed Standard.
This is the appropriate RFC type given the protocol extensions defined within the document.

(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:

This document extends Automatic Multicast Tunnelling (AMT, RFC 7450) to allow the relay discovery process to use a new AMTRELAY DNS resource record for discovering source-specific multicast channels.  This allows a set of AMT relays that can receive and forward multicast traffic from a sender to be advertised via reverse IP entries in DNS, hence the DNS Reverse IP AMT Discovery or DRIAD name. 

Working Group Summary:

There was no particular controversy in the WG process, and consensus was good.

Document Quality:

The document is well written, explaining the basic mode of operation clearly, and including many example use cases.

Personnel:

The document shepherd is Tim Chown (tim.chown@jisc.ac.uk), and the responsible AD is 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, reviewed recent WG list discussion, and am happy that it is ready overall to be advanced to the IESG.

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

(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 am happy overall with the document.

I would suggest that the text in 2.3.1 on applying a Happy Eyeballs algorithm where there are multiple choices for the relay be expanded; it is very vague at present.  I presume that this may result in multiple unicast AMT streams coming in to a given gateway, and all but one of these would be pruned back, but some specifics on that, and how the preferred stream is retained, would be useful. This also needs to be set against the proposed active/active failover mode described in 2.4.3.

While maximising the multicast portion of the path will avoid data duplication over unicast tunnels, using a relay close to the source (and known to the source such that it can be added to the DNS reverse zone) has some management benefits.  It’s an interesting trade-off.  The document proposes mechanism(s) to discover topologically close relays; with hindsight perhaps this, and aspects such as handling active/active failover, should have been covered in a separate document to a basic DNS RR specification that assumes a single gateway and single relay near the source.

(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?

Yes. See https://mailarchive.ietf.org/arch/msg/mboned/Y2xm-oXRFhzKmSXgdu7MrmvaTKc

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

No.

(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 good, with no opposition to publication, but mboned is a relatively small WG with a generally low attendance at meetings.  The WGLC in June passed but needed a prod from the WG chairs and another poke from Warren as the AD to get additional responses - see https://mailarchive.ietf.org/arch/msg/mboned/5OzJMfSfWvWq6Nu-SPqdxCMLjSw

Those who did comment were favourable, for example - “This is a very useful addition to the AMT toolkit, which should encourage the deployment of multicast services.  I therefore support its adoption enthusiastically.” - William Atwood.

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

I ran a nits check on the -08 version.  See https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-mboned-driad-amt-discovery-08.txt
The two warnings about IPv4 literal and multicast addresses appear to be spurious.  This was discussed by the author at https://mailarchive.ietf.org/arch/msg/mboned/G6rBrnc9u4YCBniAOnZf1-iTQqw
It looks like the nit checker needs a tweak for SSM?
Otherwise, the document passes all nit checks.

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

No such reviews are 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, all references are at RFC status.

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

None apparent.

(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. Though it does update RFC 7450 by providing a specific DNS-based mechanism for AMT relay discovery.


(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 5226).

The IANA Considerations are covered in Section 5.
The document requests a new DNS Resource Record Type of type 260.
This type is already listed at https://www.iana.org/assignments/dns-parameters/dns-parameters.xml, the reservation of which appears consistent with the document.
There is a sub-registry for the Relay Type field, for which four of 256 possible values are defined.

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

The Relay Type field may potentially have additional values assigned in the future; as above four of 256 values are defined, the rest (4-255) are unassigned.  The document states that Expert Review would be required for these, as per Section 4.6 (policy of Specification Required) of RFC 8126.

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