Automatic Multicast Tunneling
draft-ietf-mboned-auto-multicast-18

[Ballot comment]

Thanks for handling my discuss points (and apologies for
being slow to check the new text before you posted -18).

I didn't check if these comments are still relevant for -18 but
have left them here just in case.

- 11 years. Wow! Kudos for being persistent!

- p11, in the figure (my ascii-art sympathies btw;-), why is
the application dealing with multicast data via UDP only?

- Its not that common to have a field called a nonce and yet
have that sent in multiple messages. Maybe this is more a kind
of session id?

- 5.1.2 - it'd have been nicer to have a length field for the
nonce or relay address so that you could vary the nonce length
without confusing matters. Seems like there're enough unused
bits to do that if you wanted.

- 5.1.5/5.1.6: What if the encapsulated packet is bigger than
the MTU, isn't that a problem?

- 5.1.6: Oughtn't you say something about congestion and being
TCP friendly? 

- Section 6: I always think that trying to be "as secure as
<>" is a bad goal to select.

- A.1 and 5.3.5 show MD5 inputs in different orders. They ought
be the same.

[Ballot comment]
I didn't have time to do a full review, but did check on previous comments from Sean Turner to see if they were addressed.  I think it would be very helpful to address them, so a little additional info is given here on sections.  I think they were meant to fit in with Stephen's #2 discuss, I think.

From Sean:
a. [RFC6151] recommends against the use of MD5 as you've documented it.  If you
need any kind of collision resistance MD5 is inappropriate to use.  If you
don't care about collisions resistance, then I think you need to explicitly
state that in the security considerations.  MD5 is okay to use in an HMAC
though, but there are better choices out there for "new" protocols.

Reference to Sean's comment with sections:
b. It doesn't appear that Sean Turner's comment on nonce creation was addressed in 5.2.3.4.5 and 5.2.3.5.6
A reference to the RFC he mentioned would be helpful.  Here is Sean's comment:

[RFC4949]:

  $ nonce
      (I) A random or non-repeating value that is included in data
      exchanged by a protocol, usually for the purpose of guaranteeing
      liveness and thus detecting and protecting against replay attacks.
      (See: fresh.)

c. Again, from Sean's review, it looks like protections of the secret key were not added in section 5.3.6.  I think this is important.

Sean's #4: I don't see a reference to RFC4086?

[Ballot comment]
I am moving to Abstain, as some issues have been addressed, namely 2 and 3 (partly), but others such as 1) are not addressed and will probably not be solved by this draft.

I still do not see that this protocol is safe for operations across the public Internet, as the major point 1) isn't solved.

Therefore, I would appreciate very much to emphasize the point "- Limit the scope of this to wallened gardens and adding operational consinderations describing the limits of it."

***************************************

The old DISCUSS as reference:

I have no general objection to the AMT protocol as such, but the below DISCUSS issues.
The overall description of the protocol and its framework is well done.

The current AMT protocol has these DISCUSS issues that must be addressed:
1) lack of congestion control of the AMT traffic between relay and gateway
  -- Then tunnel multicast traffic can exceed a path's capacity. Further, such a relay will send out a number of tunnelled multicast flows to a huge number of destinations, either competing with themselves or with other flows.

2) lack of MTU handling
  -- There absolutely no mentioning of MTU issues in the draft. However, tunnelled packets can easily exceed the path MTU. How does AMT react to this?

3) Use of zero IPv6/UDP checksum and failure handling, if any middlebox enroute is not allowing zero UDP checksum packets to traverse. This is also a question on what happens, if the traffic is black holed for any other reasons, i.e., when no ICMP error message is returned at all.

4) Security: There is a change in the threat model, i.e., multicast requires LAN access but with AMT almost anybody can access the multicast feed. I can understand that this is not needed in certain deployments, e.g., a mobile phone network, but this is not well documented in any part of the draft.

5) NAT traversal and the IANA-assigned port.
Section 4.2.2.2 assumes a simple NAPT with translation from IPv4 to IPv4. However there can be other NATs than even change the source IP address for incoming flows and potentially also the port number. Is there any specific reason to nail down the source port of the relay? The discovery mechanism could also return an arbitrary port number.

6) Section 5.2.3.5.4, start of page 58: NAT timer. The NAT timer is independent of any other time, as this really depends on the NAT on the path.

7) The current AMT specification cuts away the possibility to return ASM receiver feedback to the source. This is not documented nor described.

Magnus did an excellent summary of the above points in his review:
http://www.ietf.org/mail-archive/web/ietf/current/msg76475.html

I can see three potential ways forward for this draft:
- Address the above topics to make the draft ready for the Standards Track and thus safely deployable in the public Internet
- Reclassify it as experimental and figure out all missing parts.
- Limit the scope of this to wallened gardens and adding operational consinderations describing the limits of it.

[Ballot comment]
I am moving to Abstain, as some issues have been addressed, namely 2 and 3 (partly), but others such as 1) are not addressed and will probably not be solved by this draft.

I still do not see that this protocol is safe for operations across the public Internet, as the major point 1) isn't solved.

Therefore, I would appreciate very much to emphasize the point "- Limit the scope of this to wallened gardens and adding operational consinderations describing the limits of it."

***************************************

The old DISCUSS as reference.

I have no general objection to the AMT protocol as such, but the below DISCUSS issues.
The overall description of the protocol and its framework is well done.

The current AMT protocol has these DISCUSS issues that must be addressed:
1) lack of congestion control of the AMT traffic between relay and gateway
  -- Then tunnel multicast traffic can exceed a path's capacity. Further, such a relay will send out a number of tunnelled multicast flows to a huge number of destinations, either competing with themselves or with other flows.

2) lack of MTU handling
  -- There absolutely no mentioning of MTU issues in the draft. However, tunnelled packets can easily exceed the path MTU. How does AMT react to this?

3) Use of zero IPv6/UDP checksum and failure handling, if any middlebox enroute is not allowing zero UDP checksum packets to traverse. This is also a question on what happens, if the traffic is black holed for any other reasons, i.e., when no ICMP error message is returned at all.

4) Security: There is a change in the threat model, i.e., multicast requires LAN access but with AMT almost anybody can access the multicast feed. I can understand that this is not needed in certain deployments, e.g., a mobile phone network, but this is not well documented in any part of the draft.

5) NAT traversal and the IANA-assigned port.
Section 4.2.2.2 assumes a simple NAPT with translation from IPv4 to IPv4. However there can be other NATs than even change the source IP address for incoming flows and potentially also the port number. Is there any specific reason to nail down the source port of the relay? The discovery mechanism could also return an arbitrary port number.

6) Section 5.2.3.5.4, start of page 58: NAT timer. The NAT timer is independent of any other time, as this really depends on the NAT on the path.

7) The current AMT specification cuts away the possibility to return ASM receiver feedback to the source. This is not documented nor described.

Magnus did an excellent summary of the above points in his review:
http://www.ietf.org/mail-archive/web/ietf/current/msg76475.html

I can see three potential ways forward for this draft:
- Address the above topics to make the draft ready for the Standards Track and thus safely deployable in the public Internet
- Reclassify it as experimental and figure out all missing parts.
- Limit the scope of this to wallened gardens and adding operational consinderations describing the limits of it.

[Ballot discuss]
I see there's a -17 of this but don't see that it addresses the
discuss points below. And I've of course lost the context
since January;-) Seems like the TSV area discusses get
priority on this one (still;-).

(1) I'm not getting the trust model. Why is that "MAC" not the
same as a random number chosen by the relay? And that'd be
more robust against mobile gateways for example. Even better
would be an open-channel DH exchange.  I don't understand
what the current design gets you.

(2) I also entirely don't get why its ok to use a fixed-width
48-bit MAC with a home-grown algorithm based on MD5 and no
agility and that page 67 says a relay "MAY skip" sometimes.
I'd also suspect the home-grown algorithm specified in 5.3.5
may have weaknesses - the gateway knows or picks all the inputs
up to the secret which therefore MUST be long and strong, and
side-channel attacks (timing) might be effective against a
relay. That all seems far too ad-hoc for a standard when hmac
exists and is better. Can you point me at where this has gotten
some cryptographic review? (But note the answer to point 1
might impact on this, so bottoming out point 1 first would
be best maybe.)

ENTS)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mboned-auto-multicast-17.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA, ratified 6 May 2012 makes no provision for allocations outside the Regional Internet Registry system.  Thus the request that the /24 come from the "Allocations made from the Current Recovered IPv4 Pool" registry located at:

http://www.iana.org/assignments/ipv4-recovered-address-space/

However, IANA will work with the authors to identify an appropriate /24 for the requested anycast AMT relay discovery prefix based on the template supplied in the document:

+----------------------+----------------+
| Attribute            | Value          |
+----------------------+----------------+
| Address Block        | x.x.x.x./24    |
| Name                | AMT            |
| RFC                  | [RFC-to-be]    |
| Allocation Date      | [TBD]          |
| Termination Date    | N/A            |
| Source              | True          |
| Destination          | True          |
| Forwardable          | True          |
| Global              | True          |
| Reserved-by-Protocol | False          |
+----------------------+----------------+

Second, in the IANA IPv6 Special-Purpose Address Registry located at:

http://www.iana.org/assignments/iana-ipv6-special-registry/

a new, special purpose block is to be registered for IPv6 anycast AMT relay discovery, as follows (based on the information in this template:

+----------------------+----------------+
| Attribute            | Value          |
+----------------------+----------------+
| Address Block        | 2001:0003::/32 |
| Name                | AMT            |
| RFC                  | [RFC-to-be]    |
| Allocation Date      | [TBD]          |
| Termination Date    | N/A            |
| Source              | True          |
| Destination          | True          |
| Forwardable          | True          |
| Global              | True          |
| Reserved-by-Protocol | False          |
+----------------------+----------------+

Third, in the Service Name and Transport Protocol Port Number Registry located at:

http://www.iana.org/assignments/service-names-port-numbers/

the entry for 2268, AMT (both tcp and udp) will be changed as follows:

- the reference will be changed to [ RFC-to-be ]
- the modified date will be entered appropriately

IANA understands that these three actions are the only ones that need to be completed 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 only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Automatic Multicast Tunneling) to Proposed Standard


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:
- 'Automatic Multicast Tunneling'
  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
ietf@ietf.org mailing lists by 2014-05-26. 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 describes Automatic Multicast Tunneling (AMT), a
  protocol for delivering multicast traffic from sources in a
  multicast-enabled network to receivers that lack multicast
  connectivity to the source network.  The protocol uses UDP
  encapsulation and unicast replication to provide this functionality.

  The AMT protocol is specifically designed to support rapid deployment
  by requiring minimal changes to existing network infrastructure.

Additional Notes:

  History of this document is here:

  http://datatracker.ietf.org/doc/draft-ietf-mboned-auto-multicast/history/

  Original last call for this document was 2012-12-05 on draft 14
  The result was recorded as consensus in favor of publication.

  Since then significant changes were performed to address IETF LC,
  IANA, and IESG concerns. Given the long gestation period between
  -14 and draft -17 a  new LC and IESG review is considered advisable.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mboned-auto-multicast/

A side-by-side diff of draft-14 and draft-17 is preserved here:

http://minorthreat.org/amt/Diff-draft-ietf-mboned-auto-multicast-14.txt%20-%20draft-ietf-mboned-auto-multicast-17.txt.html

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mboned-auto-multicast/ballot/


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

Updated 5/3/2014 to reflect current Document status. Edit performed by Shepherding AD Joel Jaeggli.

(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

(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

  The advantages and benefits provided by multicast technologies are
  well known.  There are a number of application areas that are ideal
  candidates for the use of multicast, including media broadcasting,
  video conferencing, collaboration, real-time data feeds, data
  replication, and software updates.  Unfortunately, many of these
  applications lack multicast connectivity to networks that carry
  traffic generated by multicast sources.  The reasons for the lack of
  connectivity vary, but are primarily the result of service provider
  policies and network limitations.

  Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based
  encapsulation to overcome the aforementioned lack of multicast
  connectivity.  AMT enables sites, hosts or applications that do not
  have native multicast access to a network with multicast connectivity
  to a source, to request and receive SSM [RFC4607] and ASM [RFC1112]
  traffic from a network that does provide multicast connectivity to
  that source.

Working Group Summary

  This document has received strong support from the working group and no
  major controversies existed prior to the arriving at the IESG with
  this document.

  Subsequent to the previous IESG review, efforts have been made to address IESG 
  discuss issues, deal with IANA concerns and spin up new work associated with 
  congestion guidance for multicast applications.

Document Quality

  A number of AMT implementations exist today and significant deployment
  experience has been documented.  This document has received thorough
  review from the working group, and many have contributed to this effort
  over the last 11+ years.  In particular, Dave Thaler, Tom Pusateri,
  Thomas Morin and Greg Bumgardner deserve credit for most of the
  authorship of this document, and Bob Sayko, Doug Nortz and their
  colleagues at ATT deserve credit for extremely thorough review of the
  document.

Personnel

  Lenny Giuliano is the Document Shepherd, Ron Bonica is the
  Responsible Area Director.

IANA Note

  IANA Considerations

  IPv4 and IPv6 Anycast Prefix Allocation

  IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to
  the public AMT Relays to advertise to the native multicast backbone
  (as described in Section 4.1.4).  The prefix length should be
  determined by the IANA; the prefix should be large enough to
  guarantee advertisement in the default-free BGP networks.

  IPv4

  A prefix length of 24 will meet this requirement.

  IPv6

  A prefix length of 32 will meet this requirement.  IANA has
  previously set aside the range 2001::/16 for allocating prefixes for
  this purpose.

  IPv4 Address Prefix Allocation for IGMP Source Addresses

  IANA should allocate an IPv4 prefix dedicated for use in IGMP
  messages exchanged between gateways and relays.  This address range
  is intended for use within tunnels constructed between a gateway and
  relay, and as such, is not intended to be globally routable.

  A prefix length of 24 will meet this requirement.

  UDP Port number

  IANA has reserved UDP port number 2268 for AMT.

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

Document was reviewed by the Shepherd, who feels it is ready for
publication.

Document has been reviewed in detail by IANA.  Previous IESG review can be seen as part of the document history

http://datatracker.ietf.org/doc/draft-ietf-mboned-auto-multicast/history/

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

No, the document has undergone thorough review from a number of folks
in the WG.

During previous IETF last call and IESG review an number of issues were addressed. With  respect to the content of the draft it has been very thoroughly reviewed.

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

Not that I am aware of.

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

No concerns.  Doc has been thoroughly reviewed and all issues seem to be
resolved.

Guidelines for multicast applications with respect to congestion awareness or avoidance is work that has begun in order to address concerns expressed in transport are review and by the previous and present transport ADs. This is important work, however amt relay routers as with other forms of multicast tunnel routers are not ultimately in a position to alter the transmission rate of the multicast source, applications running on multicast recievers may be in a position to alter their behavior in response to exigent conditions (see section 4.1.4.2 and http://tools.ietf.org/html/draft-shepherd-multicast-udp-guidelines-01)

(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

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

Not aware of any, nor any recollection of any WG discussion regarding IPR.

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

The WG as a whole appears to understand and agree with it.

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

Not that I am aware of.

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

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

Not aware of any.

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

Yes, there are both normative and informative references.

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

Not that I am aware of.  All normative references point to RFCs.

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

There are no normative references to any informational RFCs.

(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

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

IANA has signed off on draft 17

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

See IANA considerations above.

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

(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

(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

  The advantages and benefits provided by multicast technologies are
  well known.  There are a number of application areas that are ideal
  candidates for the use of multicast, including media broadcasting,
  video conferencing, collaboration, real-time data feeds, data
  replication, and software updates.  Unfortunately, many of these
  applications lack multicast connectivity to networks that carry
  traffic generated by multicast sources.  The reasons for the lack of
  connectivity vary, but are primarily the result of service provider
  policies and network limitations.

  Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based
  encapsulation to overcome the aforementioned lack of multicast
  connectivity.  AMT enables sites, hosts or applications that do not
  have native multicast access to a network with multicast connectivity
  to a source, to request and receive SSM [RFC4607] and ASM [RFC1112]
  traffic from a network that does provide multicast connectivity to
  that source.

Working Group Summary

  This document has received strong support from the working group and no
  major controversies exist today with this document.

Document Quality

  A number of AMT implementations exist today and significant deployment
  experience has been documented.  This document has received thorough
  review from the working group, and many have contributed to this effort
  over the last 11+ years.  In particular, Dave Thaler, Tom Pusateri,
  Thomas Morin and Greg Bumgardner deserve credit for most of the
  authorship of this document, and Bob Sayko, Doug Nortz and their
  colleagues at ATT deserve credit for extremely thorough review of the
  document.

Personnel

  Lenny Giuliano is the Document Shepherd, Ron Bonica is the
  Responsible Area Director.

IANA Note

  IANA Considerations

  IPv4 and IPv6 Anycast Prefix Allocation

  IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to
  the public AMT Relays to advertise to the native multicast backbone
  (as described in Section 4.1.4).  The prefix length should be
  determined by the IANA; the prefix should be large enough to
  guarantee advertisement in the default-free BGP networks.

  IPv4

  A prefix length of 24 will meet this requirement.

  Internet Systems Consortium (ISC) has offered 154.7.0/24 for this
  purpose.

  IPv6

  A prefix length of 32 will meet this requirement.  IANA has
  previously set aside the range 2001::/16 for allocating prefixes for
  this purpose.

  IPv4 Address Prefix Allocation for IGMP Source Addresses

  IANA should allocate an IPv4 prefix dedicated for use in IGMP
  messages exchanged between gateways and relays.  This address range
  is intended for use within tunnels constructed between a gateway and
  relay, and as such, is not intended to be globally routable.

  A prefix length of 24 will meet this requirement.

  Internet Systems Consortium (ISC) has offered 154.7.1/24 for this
  purpose.

  UDP Port number

  IANA has reserved UDP port number 2268 for AMT.

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

Document was reviewed by the Shepherd, who feels it is ready for
publication.

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

No, the document has undergone thorough review from a number of folks
in the WG.

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

Not that I am aware of.

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

No concerns.  Doc has been thoroughly reviewed and all issues seem to be
resolved.

(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

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

Not aware of any, nor any recollection of any WG discussion regarding IPR.

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

The WG as a whole appears to understand and agree with it.

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

Not that I am aware of.

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

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

Not aware of any.

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

Yes, there are both normative and informative references.

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

Not that I am aware of.  All normative references point to RFCs.

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

There are no normative references to any informational RFCs.

(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

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

Looks good to me.

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

See IANA considerations above.

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

[Ballot discuss]
I see there's a -16 of this but don't see that it addresses the
discuss points below. And I've of course lost the context
since January;-) Seems like the TSV area discusses get
priority on this one.

(1) I'm not getting the trust model. Why is that "MAC" not the
same as a random number chosen by the relay? And that'd be
more robust against mobile gateways for example. Even better
would be an open-channel DH exchange.  I don't understand
what the current design gets you.

(2) I also entirely don't get why its ok to use a fixed-width
48-bit MAC with a home-grown algorithm based on MD5 and no
agility and that page 67 says a relay "MAY skip" sometimes.
I'd also suspect the home-grown algorithm specified in 5.3.5
may have weaknesses - the gateway knows or picks all the inputs
up to the secret which therefore MUST be long and strong, and
side-channel attacks (timing) might be effective against a
relay. That all seems far too ad-hoc for a standard when hmac
exists and is better. Can you point me at where this has gotten
some cryptographic review? (But note the answer to point 1
might impact on this, so bottoming out point 1 first would
be best maybe.)

[Ballot comment]
I didn't check if these comments are still relevant for -15 but
have left them here just in case.

- 11 years. Wow! Kudos for being persistent!

- p11, in the figure (my ascii-art sympathies btw;-), why is
the application dealing with multicast data via UDP only?

- Its not that common to have a field called a nonce and yet
have that sent in multiple messages. Maybe this is more a kind
of session id?

- 5.1.2 - it'd have been nicer to have a length field for the
nonce or relay address so that you could vary the nonce length
without confusing matters. Seems like there're enough unused
bits to do that if you wanted.

- 5.1.5/5.1.6: What if the encapsulated packet is bigger than
the MTU, isn't that a problem?

- 5.1.6: Oughtn't you say something about congestion and being
TCP friendly? 

- Section 6: I always think that trying to be "as secure as
<>" is a bad goal to select.

- A.1 and 5.3.5 show MD5 inputs in different orders. They ought
be the same.

[Ballot discuss]

I see there's a -15 of this but don't see that it addresses the
discuss points below. And I've of course lost the context
since January;-) So can we re-start the discussion about
this? Thanks. S.

(1) I'm not getting the trust model. Why is that "MAC" not the
same as a random number chosen by the relay? And that'd be
more robust against mobile gateways for example. Even better
would be an open-channel DH exchange.  I don't understand
what the current design gets you.

(2) I also entirely don't get why its ok to use a fixed-width
48-bit MAC with a home-grown algorithm based on MD5 and no
agility and that page 67 says a relay "MAY skip" sometimes.
I'd also suspect the home-grown algorithm specified in 5.3.5
may have weaknesses - the gateway knows or picks all the inputs
up to the secret which therefore MUST be long and strong, and
side-channel attacks (timing) might be effective against a
relay. That all seems far too ad-hoc for a standard when hmac
exists and is better. Can you point me at where this has gotten
some cryptographic review? (But note the answer to point 1
might impact on this, so bottoming out point 1 first would
be best maybe.)

[Ballot comment]

I didn't check if these comments are still relevant for -15 but
have left them here just in case.

- 11 years. Wow! Kudos for being persistent!

- p11, in the figure (my ascii-art sympathies btw;-), why is
the application dealing with multicast data via UDP only?

- Its not that common to have a field called a nonce and yet
have that sent in multiple messages. Maybe this is more a kind
of session id?

- 5.1.2 - it'd have been nicer to have a length field for the
nonce or relay address so that you could vary the nonce length
without confusing matters. Seems like there're enough unused
bits to do that if you wanted.

- 5.1.5/5.1.6: What if the encapsulated packet is bigger than
the MTU, isn't that a problem?

- 5.1.6: Oughtn't you say something about congestion and being
TCP friendly? 

- Section 6: I always think that trying to be "as secure as
<>" is a bad goal to select.

- A.1 and 5.3.5 show MD5 inputs in different orders. They ought
be the same.

[Ballot discuss]
This document IANA considerations section should update the IPv4 and IPv6 Special-
Purpose Address Registries (RFC 6890)

As discussed during the IESG telechat on Jan 10th, I'm holding the DISCUSS on behalf of IANA (Michelle Cotton) for all IANA issues. Waiting for Michelle Cotton's answer to see if this is fixed.
IANA has reviewed draft-ietf-mboned-auto-multicast-14 and has the following comments:

IANA has questions about the IANA actions requested in this document.

The title of 7.1 is "IPv4 and IPv6 Anycast Prefix Allocation". IANA understands this to mean that the authors actually want unicast prefixes which will be used for anycast routing. RFC 3513, section 2.4 notes that "Anycast addresses are taken from the unicast address spaces (of any scope) and are not syntactically distinguishable from unicast addresses."

IANA believes that 7.1.1 could be more efficiently written as "IANA has assigned 154.7.0/24 for IPv4 AMT Relays."

IANA would also prefer that 7.1.2 should use similar language and we would like to propose 2001:0003::/32 as a prefix.

IANA believes that 7.2 could be more efficiently written as "IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses."

In 7.3 it says "IANA has reserved UDP port number 2268 for AMT." It is not clear to IANA if the authors are asking for a reservation to be turned into an assignment or noting an action that was previously taken and does not need to be modified. IANA has examined the ports registry and can see the registration but no link to an I-D or RFC. Do the authors want the current registrant name to be replaced with this I-D and the RFC number when it is approved?

IANA also believes these prefixes should be registered in the IANA IPv4 and IPv6 Special Registries. It would be helpful if the authors could provide the basic data for the registry in addition to the prefix:

Assignment
Termination Date
Purpose
Contact Details
Routing Scope
Reference

The routing scope is particularly helpful for the future as IANA will use it when developing a set of RPKI objects as defined in RFC 6491.

[Ballot comment]
1.
From this figure ...

  Isolated Site  |    Unicast Network    |  Native Multicast
                |      (Internet)      |
                |                        |
                |                        |
                |    Group Membership    |
      +-------+ ===========================> +-------+ Multicast +------+
      |Gateway|  |                        |  | Relay |<----//----|Source|
      +-------+ <=========================== +-------+          +------+
                |    Multicast Data    |
                |                        |
                |                        |

                    Figure 1: Basic AMT Architecture

... I was not sure whether the left part of the gateway was IP unicast of multicast.
It's only when I saw the following figure that I understood.

                  Gateway                        Relay

                    General _____        _____
        ___________  Query |    |      |    | Query  ___________
      |          |<------|    |      |    |<------|          |
      | Host Mode |      | AMT |      | AMT |      |Router Mode|
      | IGMP/MLD  |      |    |  UDP  |    |      | IGMP/MLD  |
      |___________|------>|    |<----->|    |------>|___________|
                    Report |    |      |    | Report
                Leave/Done |    |      |    | Leave/Done
                          |    |      |    |
      IP Multicast <------|    |      |    |<------ IP Multicast
                          |_____|      |_____|

              Multicast Reception State Managed By IGMP/MLD

It might be better to clarify it earlier in the draft

[Ballot comment]
While I'm happy to work to document or  ameliorate the Transport area's concern that unicast encapsulation is not sensitive to to congestion control, fundamentally multicast encapsulation never has been. While some applications that leverage multicast are adaptive to loss most are not. AMT doesn't really change that situation.

[Ballot discuss]
More of a DISCUSS-DISCUSS type of feedback.
This document IANA considerations section should update the IPv4 and IPv6 Special-
Purpose Address Registries (draft-bonica-special-purpose-05), correct?

As discussed during the IESG telechat on Jan 10th, I'm holding the DISCUSS on behalf of IANA (Michelle Cotton) for all IANA issues:
IANA has reviewed draft-ietf-mboned-auto-multicast-14 and has
the following comments:

IANA has questions about the IANA actions requested in this document.

The title of 7.1 is "IPv4 and IPv6 Anycast Prefix Allocation". IANA understands this to mean that the authors actually want unicast prefixes which will be used for anycast routing. RFC 3513, section 2.4 notes that "Anycast addresses are taken from the unicast address spaces (of any scope) and are not syntactically distinguishable from unicast addresses."

IANA believes that 7.1.1 could be more efficiently written as "IANA has assigned 154.7.0/24 for IPv4 AMT Relays."

IANA would also prefer that 7.1.2 should use similar language and we would like to propose 2001:0003::/32 as a prefix.

IANA believes that 7.2 could be more efficiently written as "IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses."

In 7.3 it says "IANA has reserved UDP port number 2268 for AMT." It is not clear to IANA if the authors are asking for a reservation to be turned into an assignment or noting an action that was previously taken and does not need to be modified. IANA has examined the ports registry and can see the registration but no link to an I-D or RFC. Do the authors want the current registrant name to be replaced with this I-D and the RFC number when it is approved?

IANA also believes these prefixes should be registered in the IANA IPv4 and IPv6 Special Registries. It would be helpful if the authors could provide the basic data for the registry in addition to the prefix:

Assignment
Termination Date
Purpose
Contact Details
Routing Scope
Reference

The routing scope is particularly helpful for the future as IANA will use it when developing a set of RPKI objects as defined in RFC 6491.

[Ballot discuss]
More of a DISCUSS-DISCUSS type of feedback.
This document IANA considerations section should update the IPv4 and IPv6 Special-
Purpose Address Registries (draft-bonica-special-purpose-05), correct?

As discussed during the IESG telechat on Jan 10th, I'm holding the DISCUSS on behalf of IANA (Michelle Cotton) for all IANA issues.

[Ballot discuss]
More of a DISCUSS-DISCUSS type of feedback.
This document IANA considerations section should update the IPv4 and IPv6 Special-
Purpose Address Registries (draft-bonica-special-purpose-05), correct?

[Ballot comment]
1.
From this figure ...

  Isolated Site  |    Unicast Network    |  Native Multicast
                |      (Internet)      |
                |                        |
                |                        |
                |    Group Membership    |
      +-------+ ===========================> +-------+ Multicast +------+
      |Gateway|  |                        |  | Relay |<----//----|Source|
      +-------+ <=========================== +-------+          +------+
                |    Multicast Data    |
                |                        |
                |                        |

                    Figure 1: Basic AMT Architecture

... I was not sure whether the left part of the gateway was IP unicast of multicast.
It's only when I saw the following figure that I understood.

                  Gateway                        Relay

                    General _____        _____
        ___________  Query |    |      |    | Query  ___________
      |          |<------|    |      |    |<------|          |
      | Host Mode |      | AMT |      | AMT |      |Router Mode|
      | IGMP/MLD  |      |    |  UDP  |    |      | IGMP/MLD  |
      |___________|------>|    |<----->|    |------>|___________|
                    Report |    |      |    | Report
                Leave/Done |    |      |    | Leave/Done
                          |    |      |    |
      IP Multicast <------|    |      |    |<------ IP Multicast
                          |_____|      |_____|

              Multicast Reception State Managed By IGMP/MLD

It might be better to clarify it earlier in the draft
The intro mentioned:
  AMT enables sites, hosts or applications that do not
  have native multicast access to a network with multicast connectivity
  to a source, to request and receive SSM [RFC4607] and ASM [RFC1112]
  traffic from a network that does provide multicast connectivity to
  that source.
So I was thinking: a gateway in every host/applications?
Then the following figure is actually a host
          +-----------------------------------------------------+
          |Host                                                |
          |    ______________________________________          |
          |  |                                      |          |
          |  |    ___________________________      |          |
          |  |  |                          |      |          |
          |  |  |                          v      |          |
          |  |  |        +-----------+  +--------------+      |
          |  |  |        |Application|  |  AMT Daemon  |      |
          |  |  |        +-----------+  +--------------+      |
          |  |  | join/leave |  ^ data        ^ AMT          |
          |  |  |            |  |            |              |
          |  |  |      +----|---|-------------|-+            |
          |  |  |      |  __|  |_________    | |            |
          |  |  |      | |                |  | |            |
          |  |  |      | |      Sockets  |  | |            |
          |  |  |      +-|------+-------+-|---|-+            |
          |  |  |      | | IGMP |  TCP  | |UDP| |            |
          |  |  |      +-|------+-------+-|---|-+            |
          |  |  |      | | ^      IP    |  | |            |
          |  |  |      | | |  ____________|  | |            |
          |  |  |      | | | |                | |            |
          |  |  |      +-|-|-|----------------|-+            |
          |  |  |        | | |                |              |
          |  |  | IP(IGMP)| | |IP(UDP(data))  |IP(UDP(AMT))  |
          |  |  |        v | |                v              |
          |  |  |    +-----------+          +---+            |
          |  |  |    |Virtual I/F|          |I/F|            |
          |  |  |    +-----------+          +---+            |
          |  |  |        |  ^                ^              |
          |  |  | IP(IGMP)|  |IP(UDP(data))  |              |
          |  |  |_________|  |IP(IGMP)        |              |
          |  |                |                |              |
          |  |_________________|                |              |
          |                                      |              |
          +--------------------------------------|--------------+
                                                  v
                                              AMT Relay

                Virtual Interface Implementation Example

So clarify early in the draft that the gateway may be a standalone device with muulticast downstream, or a host.

PROPOSAL
OLD
4.1.2.  Gateways

  The downstream side of a gateway services one or more receivers - the
  gateway accepts group membership requests from receivers and forwards
  requested multicast traffic back to those receivers.

NEW
4.1.2.  Gateways

  The downstream side of a gateway services one or more multicast receivers - the
  gateway accepts group membership requests from receivers and forwards
  requested multicast traffic back to those receivers. The gateway functionality may be
  directly implemented in the host requesting the multicast service.


2.

OLD

4.1.5.2. IANA-Assigned Relay Discovery Address Prefix
This document calls for IANA to allocate an anycast address prefix for use in advertising and discovering publicly accessible relays.

NEW:
4.1.5.2. IANA-Assigned Relay Discovery Address Prefix
This document calls for IANA to allocate an anycast IPv4 and IPv- address prefix for use in advertising and discovering publicly accessible relays.

[Ballot comment]
I couldn't find where the document explicitly calls out how to represent the IP addresses in the binary fields - you almost certainly intend for them to be in network-byte-order, but if it's not already explicit in the document, please make it so.

Are there any considerations that the document should call out for administrators for making the transition when the network from which hosts had been using AMT to reach content is given native multicast connectivity?

[Ballot comment]
0) I agree with Martin's 4th discuss (the security one).

1) I agree with Stephen's 1st discuss also.

2) I also agree with Stephen's 2nd discuss, but I've got a bit more:

a) [RFC6151] recommends against the use of MD5 as you've documented it.  If you need any kind of collision resistance MD5 is inappropriate to use.  If you don't care about collisions resistance, then I think you need to explicitly state that in the security considerations.  MD5 is okay to use in an HMAC though, but there are better choices out there for "new" protocols.

b) If you're going to retain the secret key, then some words about protecting the secret are needed.  We can revisit this after the dust has settled on Stephen's discusses.

3) And on his "nonce" comment, yeah I really think it's not much of a nonce [RFC4949]:

  $ nonce
      (I) A random or non-repeating value that is included in data
      exchanged by a protocol, usually for the purpose of guaranteeing
      liveness and thus detecting and protecting against replay attacks.
      (See: fresh.)

4) s5.2.3.4.5/s5.2.3.5.6 and s5.3.6: Add a normative reference to RFC 4086 for randomness requirements.  Put it in the sentence that talks about the pseudo-random number generator.  It's pretty much the standard motherhood and apple pie  statement when it comes to PRNGs.

5) s4.1.3.1: r/is a architectural/is an architectural

6) s4.2.1.2 and elsewhere: r/private secret/secret (secrets are private :)

7) s4.2.2.3: So this is probably nit picking, but isn't I-D.ietf-6man-udpchecksums "the" solution not "a" solution as it's about to be a PS?

8) s5.2.3.4.2/s5.2.3.5.2: Would be good to provide a pointer to the state timers so folks will know how long they need to keep the nonce.

9) s5.3.6: WRT retention, shouldn't the prior secret key be kept until after you start using the new key?  App A talks about reauthenticating with the old key?

10) References:

a) Normative:

Pretty sure that in addition to 1321 being normative the following should also be normative:

I-D.ietf-6man-udpchecksums, 2336, 2710 - Even if these are SHOULD/MAY then it's a normative reference.  And, you place requirements on IGMPv2 MLD.  See IESG statement on informative/normative references.  Or, were you thinking the IGMPv3 implementation must support v2 Membership Report & v2 Leave Group in 3376 so you'd leave it information here?  I guess same for MLDv2 saying which bits of MLDv1 must be supported?.

RFC 2119 - Pretty sure this is always normative when used.

b) Unused references:

  == Unused Reference: 'RFC0768' is defined on line 3366, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4605' is defined on line 3385, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC2104' is defined on line 3418, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC3053' is defined on line 3439, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC3056' is defined on line 3442, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC3068' is defined on line 3445, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC3973' is defined on line 3452, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4760' is defined on line 3464, but no explicit
    reference was found in the text

[Ballot comment]
I have one small clarification to ask about.  In section 5.3.3.4, in
reference to the text:

  The IGMP and MLD protocol specifications indicate that senders SHOULD
  use a link-local source IP address in message datagrams.  This
  requirement must be relaxed for AMT because gateways and relays do
  not share a common subnet.

is the requirement being relaxed that senders use a source IP address
of greater than link-scope or that the the relay IGMP and MLD
implementations accept a message with a link-local source IP address
from a sender that is not on-link?

[Ballot discuss]
[Updated as issue no 7 was missing]

I have no general objection to the AMT protocol as such, but the below DISCUSS issues.
The overall description of the protocol and its framework is well done.

The current AMT protocol has these DISCUSS issues that must be addressed:
1) lack of congestion control of the AMT traffic between relay and gateway
  -- Then tunnel multicast traffic can exceed a path's capacity. Further, such a relay will send out a number of tunnelled multicast flows to a huge number of destinations, either competing with themselves or with other flows.

2) lack of MTU handling
  -- There absolutely no mentioning of MTU issues in the draft. However, tunnelled packets can easily exceed the path MTU. How does AMT react to this?

3) Use of zero IPv6/UDP checksum and failure handling, if any middlebox enroute is not allowing zero UDP checksum packets to traverse. This is also a question on what happens, if the traffic is black holed for any other reasons, i.e., when no ICMP error message is returned at all.

4) Security: There is a change in the threat model, i.e., multicast requires LAN access but with AMT almost anybody can access the multicast feed. I can understand that this is not needed in certain deployments, e.g., a mobile phone network, but this is not well documented in any part of the draft.

5) NAT traversal and the IANA-assigned port.
Section 4.2.2.2 assumes a simple NAPT with translation from IPv4 to IPv4. However there can be other NATs than even change the source IP address for incoming flows and potentially also the port number. Is there any specific reason to nail down the source port of the relay? The discovery mechanism could also return an arbitrary port number.

6) Section 5.2.3.5.4, start of page 58: NAT timer. The NAT timer is independent of any other time, as this really depends on the NAT on the path.

7) The current AMT specification cuts away the possibility to return ASM receiver feedback to the source. This is not documented nor described.

Magnus did an excellent summary of the above points in his review:
http://www.ietf.org/mail-archive/web/ietf/current/msg76475.html

I can see three potential ways forward for this draft:
- Address the above topics to make the draft ready for the Standards Track and thus safely deployable in the public Internet
- Reclassify it as experimental and figure out all missing parts.
- Limit the scope of this to wallened gardens and adding operational consinderations describing the limits of it.

[Ballot discuss]
I have no general objection to the AMT protocol as such, but the below DISCUSS issues.
The overall description of the protocol and its framework is well done.

The current AMT protocol has these DISCUSS issues that must be addressed:
1) lack of congestion control of the AMT traffic between relay and gateway
  -- Then tunnel multicast traffic can exceed a path's capacity. Further, such a relay will send out a number of tunnelled multicast flows to a huge number of destinations, either competing with themselves or with other flows.

2) lack of MTU handling
  -- There absolutely no mentioning of MTU issues in the draft. However, tunnelled packets can easily exceed the path MTU. How does AMT react to this?

3) Use of zero IPv6/UDP checksum and failure handling, if any middlebox enroute is not allowing zero UDP checksum packets to traverse. This is also a question on what happens, if the traffic is black holed for any other reasons, i.e., when no ICMP error message is returned at all.

4) Security: There is a change in the threat model, i.e., multicast requires LAN access but with AMT almost anybody can access the multicast feed. I can understand that this is not needed in certain deployments, e.g., a mobile phone network, but this is not well documented in any part of the draft.

5) NAT traversal and the IANA-assigned port.
Section 4.2.2.2 assumes a simple NAPT with translation from IPv4 to IPv4. However there can be other NATs than even change the source IP address for incoming flows and potentially also the port number. Is there any specific reason to nail down the source port of the relay? The discovery mechanism could also return an arbitrary port number.

6) Section 5.2.3.5.4, start of page 58: NAT timer. Also noted by Magnus. The NAT timer is independent of any other time, as this really depends on the NAT on the path.

Magnus did an excellent summary of the above points in his review:
http://www.ietf.org/mail-archive/web/ietf/current/msg76475.html

I can see three potential ways forward for this draft:
- Address the above topics to make the draft ready for the Standards Track and thus safely deployable in the public Internet
- Reclassify it as experimental and figure out all missing parts.
- Limit the scope of this to wallened gardens and adding operational consinderations describing the limits of it.

[Ballot comment]
Magnus Westerlund has raised a number of other issues with the draft that should be addressed:
http://www.ietf.org/mail-archive/web/ietf/current/msg76475.html

I would suggest to merge section 4.1.4 and 4.1.5. as both discuss exactly the same.

[Ballot discuss]
This is a placeholder DISCUSS referring to Magnus Westerlunds' review:
http://www.ietf.org/mail-archive/web/ietf/current/msg76475.html

Magnus raised a number of DISCUSS issues in his review, e.g., the lack of congestion control.

The issues have not been discussed or addressed yet.

[Ballot discuss]

(1) I'm not getting the trust model. Why is that "MAC" not the
same as a random number chosen by the relay? And that'd be
more robust against mobile gateways for example. Even better
would be an open-channel DH exchange.  I don't understand
what the current design gets you.

(2) I also entirely don't get why its ok to use a fixed-width
48-bit MAC with a home-grown algorithm based on MD5 and no
agility and that page 67 says a relay "MAY skip" sometimes.
I'd also suspect the home-grown algorithm specified in 5.3.5
may have weaknesses - the gateway knows or picks all the inputs
up to the secret which therefore MUST be long and strong, and
side-channel attacks (timing) might be effective against a
relay. That all seems far too ad-hoc for a standard when hmac
exists and is better. Can you point me at where this has gotten
some cryptographic review? (But note the answer to point 1
might impact on this, so bottoming out point 1 first would
be best maybe.)

[Ballot comment]

- 11 years. Wow! Kudos for being persistent!

- p11, in the figure (my ascii-art sympathies btw;-), why is
the application dealing with multicast data via UDP only?

- Its not that common to have a field called a nonce and yet
have that sent in multiple messages. Maybe this is more a kind
of session id?

- 5.1.2 - it'd have been nicer to have a length field for the
nonce or relay address so that you could vary the nonce length
without confusing matters. Seems like there're enough unused
bits to do that if you wanted.

- 5.1.5/5.1.6: What if the encapsulated packet is bigger than
the MTU, isn't that a problem?

- 5.1.6: Oughtn't you say something about congestion and being
TCP friendly? 

- Section 6: I always think that trying to be "as secure as
<>" is a bad goal to select.

- A.1 and 5.3.5 show MD5 inputs in different orders. They ought
be the same.

[Ballot comment]
I have no objeciton ot the publication of this document as an RFC, but some
comments from the Routing Directorate review by Dimitri Papadimitriou are
included below. I agree with these comments and have updated the text
with my own queries.

You may be able to address these comments with email or small changes to
the text.

---

Section 4.1 states
  A gateway or relay implementation does
  not necessarily require a fully-functional, conforming implementation
  of IGMP or MLD to adhere to this specification, but the protocol
  description that appears in this document assumes that this is the
  case.

I am not sure what this statement intends to actually say. Similar
statement is made in Section 5.2.1

---

Section 4.1.3.1.

Figure seem to imply only PIM-SM can be used? Is this the intention?
if so, it might be a good idea to call it out in the text. If not, maybe
make clear that the figure is only an example.

---

Section 4.1.4.1

Any specific reason to impose a "provider-specific relay discovery
mechanism" or "a private anycast address" to obtain access to these
relays. What prevents making them "publically accessible"?

---

Section 4.1.5.1

The concept of "unicast Relay" and "unicast Relay address" appears for
the first time but isn't yet defined.

---

Section 4.2.1.1

Means by which the "Relay Discovery Address" is being advertised should
be documented or referenced.

---

Section 4.2.1.1 point 2

How can the GTW verify that the responder (or the entity responding on
behalf of it) is the actually the RELAY it pretends to be?

---

Section 4.2.1.1

This section doesn't provide any details concerning timing, error
situations (what happens when a message is lost?), and means to overcome
such situations. Further down the text (Section 5.2.X/5.3.X) these
details are provided so maybe just add a forward pointer.

---

Section 4.2.1.2

What is the default setting for the timer mentioned in "Each time the
gateway receives a Membership Query message it starts a timer..."

---

Section 4.2.1.2 point 3

Expand the acronym QQIC

---

Section 4.2.1.2 point 10

Usually one refers to a stream of mcast messages, so does the relay
encaspulate messages 1 by 1? What happens if the incoming message is too
long to be transmitted towards the gateway?

---                                                                 

Section 4.2.1.2

Where you say "or the relay receives a valid Teardown message from the
gateway" please at a pointer to the next section.

---

Section 4.2.1.3

The text seems to imply that the message SHALL only be used in the
conditions described in that Section, but prevents other usage e.g.
sending a Teardown without prior Membership Query/Update message.

Is this really the intent?
                                                               
---

Section 4.2.1.4

The philosophy seems to be that a GTW may receive incoming mcast traffic
from the Relay after a long waiting period, but in this case all
listeners might have "left". How comfortable are you that this type of
asynchronous mode will be effective?

---

Section 5.1.3

It looks really odd to put the P flag in the middle of the two reserved
fields. I can see you intend one byte of flags (with seven flags
reserved) and two bytes of pure reserved field.

If this was your intent, I think you should label the first reserved
field as "Flags" and set up an IANA registry (including allocation
policy) for the rest of the flags.

OTOH if you want the reserved fields to be completely available for any
future use, then perhaps you should put the P flag in bit 8.

---

Section 5.3.3.6

Should you be concerned about traffic ordering issues in the exchange
between Relay downward to the GTW as there is intermediate processing
on both entities?

---

Section 6

You say
  AMT is not intended to be a strongly secured protocol
and give the argument to                           
  make the protocol light-weight
 
You could enhance the security with minimal cost by including a key
(cf. e.g. RFC 2890) in the IP multicast traffic encapsulation format to
prevent network relays resulting in unwanted traffic to the end-user.

---

Section 6.2

  The AMT protocol provides no means for detecting or
  defending against a man-in-the-middle attack - any such functionality
  must be provided by multicast receiver applications through
  independent detection and validation of incoming multicast datagrams.

You might at least tell us what action you recommend if the receiver
detects such a problem.

[Ballot discuss]
I found this document very well-written and will ballot "Yes" once I get a few points clarified.

1. I am surprised that this draft specifically disallows IGMPv1.  Is there some rationale for that?

2. In section 4.1.2.2, there is a use case described as a proxy.  How does an AMT proxy relate to the standard IGMP/MLD proxy defined in RFC 4605 (it is in the normative reference list, but not actually referenced).  It appears to be the same functionality with new rules for the upstream interface.  It would be nice to see some clarifications in this draft on that relationship.  And if there is a tight relationship when operating in this mode, what affect does that have on the gateway needing to generate query messages?

3. Section 4.2.1.2 makes no statement about the version of the IGMP/MLD queries sent by the relays.  Later sections mandate the sending of IGMPv3 or MLDv2 queries.  Why is there a restriction on the version of the queries?  Given that the relays are acting as IGMP/MLD Queries, should there also be discussion as to relaxation of the rules for compatibility modes?

4. Sections 4.2.1.3 and 5.3.3.5 seem to disagree on whether AMT relays must handle TEARDOWN messages.  I suspect that 4.2.1.3 needs to be revised to be consistent with the normative description in 5.3.3.5.

5. Do AMT gateways need to perform any type of RPF check before forwarding packets received via an AMT Multicast Data message, especially when functioning as a proxy?

6. Sections 5.1.2.5 and 5.3.1 indicate that AMT can carry IPv6 payloads encapsulated in IPv4 packets and vice versa.  However, there is no discussion on the implications of doing such address family mixing, especially during the relay discovery process.  I recall having discussions about this in mboned and the consensus seemed to be to disallow the mixing of address families.

[Ballot comment]
And I found a few non-blocking issues.  Feel free to deal with them as you see fit.

1. In section 3.2
  * s/sate/state
  * The definition of Reception State is lacking.  What does it indicate?  What states can it hold?
  * The definition of Subscription should mention that it indicates membership in an IP multicast group

2. The diagram in section 4.1.2.1 probably needs bi-directional arrows on the IGMP/MLD data path to indicate IGMP/MLD messages coming from a relay are processed by the gateway's IGMP/MLD module.

[Ballot comment]
This is an exceptionally well written document, and was generally easy to understand.  Ron, thanks for fixing my DISCUSS point in an RFC Editor note.  What remain are a few non-blocking comments.  I think that addressing these will make the document a little better; feel free to chat with me about them if you like.

-- Section 4 --
This may be implicit in what the paragraph in Section 4 says, and perhaps Sections 4.x and 5.x are entirely consistent and no one will find any errata, but there's a lot here, and just in case there's something we don't catch...

...might it be reasonable to add a sentence such as this to the paragraph in Section 4?: "If anything in Section 4 is inconsistent with or contradictory to something in Section 5, the text in Section 5 is definitive."

-- Throughout Section 5 --
You've mostly consistently used the phrase "IANA-assigned AMT port number" to represent port 2268 [Section 7.3].  Mostly, except for the following:

5.1.5 uses "IANA-assigned AMT UDP port number" (adds "UDP")
5.2.3.4.2 uses "IANA-assigned UDP port number" (omits "AMT" and adds "UDP")
5.3.3.6 uses "IANA-assigned port" (omits "AMT" and "number")

It's probably useful to fix those three so that all uses are exactly the same.  Also, a "(see Section 7.3)" at the first instance, in Section 5.1.1, wouldn't be bad.

-- Sections 5.2.3.4.5, 5.2.3.5.6, and 5.3.6 --
These all refer to "a cryptographically secure pseudo random number generator."  Would they benefit from an informative reference to RFC 4086?

-- Section 5.3.5 --

  A Response MAC is produced by a hash digest computation.  A Response
  MAC value is computed from a Request message for inclusion in a
  Membership Query message, is computed from a Membership Update
  message to authenticate the Response MAC carried within that message,
  and is computed from fields in a Teardown message to authenticate the
  Response MAC carried within that message.

I had to read this a few times to parse it correctly.  Once I got it, I found that there's nothing wrong with it... but maybe we can make people work less hard this way?:

NEW
  A Response MAC is produced by a hash digest computation.  A Response
  MAC value is computed in three situations: from a Request message,
  for inclusion in a Membership Query message; from a Membership Update
  message, to authenticate the Response MAC carried within that message;
  and from fields in a Teardown message, to authenticate the Response
  MAC carried within that message.
END

  Gateways treat the Response MAC field as an opaque value, so a relay
  implementation may generate the MAC using any method available to it.
  The hash function RECOMMENDED for use in computing the Response MAC
  is the MD5 hash digest [RFC1321], though hash functions or keyed-hash
  functions of greater cryptographic strength may be used.

Why is this a 2119 "RECOMMENDED"?  Is there any reason the *protocol* cares what hash algorithm is used?

-- Section 5.3.3.3 --

  If a relay supports the Teardown message, it MUST set the G-flag in
  the Membership Query message and return the source IP address and UDP
  port carried by the Request message in the corresponding Gateway IP
  Address and Gateway Port Number fields.  If the relay does not
  support the Teardown message it SHOULD NOT set these fields as this
  may cause the gateway to generate unnecessary Teardown messages.

What reason might a relay have for violating that SHOULD NOT?  Why would a relay that does not support Teardown sometimes need to set those fields, such that "SHOULD NOT" (rather than "MUST NOT") is necessary?

-- Section 5.3.3.4 --

  A relay MUST maintain some form of group membership database for each
  endpoint.  The per-endpoint databases are used update a forwarding
  table containing entries that map an (*,G) or (S,G) subscription to a
  list of tunnel endpoints.

  A relay MUST maintain some form of group membership database
  representing a merger of the group membership databases of all
  endpoints.  The merged group membership database is used to update
  upstream multicast forwarding state.

  A relay MUST maintain a forwarding table that maps each unique (*,G)
  and (S,G) subscription to a list of tunnel endpoints.  A relay uses
  this forwarding table to provide the destination address when
  performing UDP/IP encapsulation of the incoming multicast IP
  datagrams to form Multicast Data messages.

I don't really want to pick on these too much, mostly because I can't imagine how *else* you might do this other than maintaining databases/tables, but...

Strictly speaking, the 2119 keywords should be calling out protocol requirements, not implementation methods.  It seems that the requirements are actually in the second sentence of each paragraph, and the MUSTs should be attached to those.  I'll use the second one as an example; perhaps this?:

NEW-maybe
  A relay MUST be able to update the upstream multicast forwarding
  state [a little more is needed here].  This is typically done by
  having the relay maintain some form of group membership database
  representing a merger of the group membership databases of all
  endpoints.
END

I would prefer it if you could re-cast each of these three paragraphs to attach the MUST to the actual protocol requirement, and talk about databases and forwarding tables as exemplary implementations (rather than attaching the MUST to the implementation).

That said, I'll remind you that this is a non-blocking comment, and if you think it will make the spec more awkward or less clear, then please don't do that.

[Ballot comment]
Here are a few non-blocking comments.  I think that addressing these will make the document a little better; feel free to chat with me about them if you like.

-- Section 4 --
This may be implicit in what the paragraph in Section 4 says, and perhaps Sections 4.x and 5.x are entirely consistent and no one will find any errata, but there's a lot here, and just in case there's something we don't catch...

...might it be reasonable to add a sentence such as this to the paragraph in Section 4?: "If anything in Section 4 is inconsistent with or contradictory to something in Section 5, the text in Section 5 is definitive."

-- Throughout Section 5 --
You've mostly consistently used the phrase "IANA-assigned AMT port number" to represent port 2268 [Section 7.3].  Mostly, except for the following:

5.1.5 uses "IANA-assigned AMT UDP port number" (adds "UDP")
5.2.3.4.2 uses "IANA-assigned UDP port number" (omits "AMT" and adds "UDP")
5.3.3.6 uses "IANA-assigned port" (omits "AMT" and "number")

It's probably useful to fix those three so that all uses are exactly the same.  Also, a "(see Section 7.3)" at the first instance, in Section 5.1.1, wouldn't be bad.

-- Sections 5.2.3.4.5, 5.2.3.5.6, and 5.3.6 --
These all refer to "a cryptographically secure pseudo random number generator."  Would they benefit from an informative reference to RFC 4086?

-- Section 5.3.5 --

  A Response MAC is produced by a hash digest computation.  A Response
  MAC value is computed from a Request message for inclusion in a
  Membership Query message, is computed from a Membership Update
  message to authenticate the Response MAC carried within that message,
  and is computed from fields in a Teardown message to authenticate the
  Response MAC carried within that message.

I had to read this a few times to parse it correctly.  Once I got it, I found that there's nothing wrong with it... but maybe we can make people work less hard this way?:

NEW
  A Response MAC is produced by a hash digest computation.  A Response
  MAC value is computed in three situations: from a Request message,
  for inclusion in a Membership Query message; from a Membership Update
  message, to authenticate the Response MAC carried within that message;
  and from fields in a Teardown message, to authenticate the Response
  MAC carried within that message.
END

  Gateways treat the Response MAC field as an opaque value, so a relay
  implementation may generate the MAC using any method available to it.
  The hash function RECOMMENDED for use in computing the Response MAC
  is the MD5 hash digest [RFC1321], though hash functions or keyed-hash
  functions of greater cryptographic strength may be used.

Why is this a 2119 "RECOMMENDED"?  Is there any reason the *protocol* cares what hash algorithm is used?

-- Section 5.3.3.3 --

  If a relay supports the Teardown message, it MUST set the G-flag in
  the Membership Query message and return the source IP address and UDP
  port carried by the Request message in the corresponding Gateway IP
  Address and Gateway Port Number fields.  If the relay does not
  support the Teardown message it SHOULD NOT set these fields as this
  may cause the gateway to generate unnecessary Teardown messages.

What reason might a relay have for violating that SHOULD NOT?  Why would a relay that does not support Teardown sometimes need to set those fields, such that "SHOULD NOT" (rather than "MUST NOT") is necessary?

-- Section 5.3.3.4 --

  A relay MUST maintain some form of group membership database for each
  endpoint.  The per-endpoint databases are used update a forwarding
  table containing entries that map an (*,G) or (S,G) subscription to a
  list of tunnel endpoints.

  A relay MUST maintain some form of group membership database
  representing a merger of the group membership databases of all
  endpoints.  The merged group membership database is used to update
  upstream multicast forwarding state.

  A relay MUST maintain a forwarding table that maps each unique (*,G)
  and (S,G) subscription to a list of tunnel endpoints.  A relay uses
  this forwarding table to provide the destination address when
  performing UDP/IP encapsulation of the incoming multicast IP
  datagrams to form Multicast Data messages.

I don't really want to pick on these too much, mostly because I can't imagine how *else* you might do this other than maintaining databases/tables, but...

Strictly speaking, the 2119 keywords should be calling out protocol requirements, not implementation methods.  It seems that the requirements are actually in the second sentence of each paragraph, and the MUSTs should be attached to those.  I'll use the second one as an example; perhaps this?:

NEW-maybe
  A relay MUST be able to update the upstream multicast forwarding
  state [a little more is needed here].  This is typically done by
  having the relay maintain some form of group membership database
  representing a merger of the group membership databases of all
  endpoints.
END

I would prefer it if you could re-cast each of these three paragraphs to attach the MUST to the actual protocol requirement, and talk about databases and forwarding tables as exemplary implementations (rather than attaching the MUST to the implementation).

That said, I'll remind you that this is a non-blocking comment, and if you think it will make the spec more awkward or less clear, then please don't do that.

[Ballot discuss]
This is an exceptionally well written document, and was generally easy to understand.  I have only one, small DISCUSS point that will be very easy to sort out:

-- Section 5.2.3.7 --

  Gateway support for the Teardown message is OPTIONAL but RECOMMENDED.

This is twisted 2119 language: "OPTIONAL" and "RECOMMENDED" have specific, contradictory meanings in RFC 2119, and the statement above makes no sense; if it's RECOMMENDED, then it's *not* OPTIONAL, and vice versa.  I think the best way to fix this is just to remove "OPTIONAL but" from the sentence.

[Ballot comment]
-- Section 4 --
This may be implicit in what the paragraph in Section 4 says, and perhaps Sections 4.x and 5.x are entirely consistent and no one will find any errata, but there's a lot here, and just in case there's something we don't catch...

...might it be reasonable to add a sentence such as this to the paragraph in Section 4?: "If anything in Section 4 is inconsistent with or contradictory to something in Section 5, the text in Section 5 is definitive."

-- Throughout Section 5 --
You've mostly consistently used the phrase "IANA-assigned AMT port number" to represent port 2268 [Section 7.3].  Mostly, except for the following:

5.1.5 uses "IANA-assigned AMT UDP port number" (adds "UDP")
5.2.3.4.2 uses "IANA-assigned UDP port number" (omits "AMT" and adds "UDP")
5.3.3.6 uses "IANA-assigned port" (omits "AMT" and "number")

It's probably useful to fix those three so that all uses are exactly the same.  Also, a "(see Section 7.3)" at the first instance, in Section 5.1.1, wouldn't be bad.

-- Sections 5.2.3.4.5, 5.2.3.5.6, and 5.3.6 --
These all refer to "a cryptographically secure pseudo random number generator."  Would they benefit from an informative reference to RFC 4086?

-- Section 5.3.5 --

  A Response MAC is produced by a hash digest computation.  A Response
  MAC value is computed from a Request message for inclusion in a
  Membership Query message, is computed from a Membership Update
  message to authenticate the Response MAC carried within that message,
  and is computed from fields in a Teardown message to authenticate the
  Response MAC carried within that message.

I had to read this a few times to parse it correctly.  Once I got it, I found that there's nothing wrong with it... but maybe we can make people work less hard this way?:

NEW
  A Response MAC is produced by a hash digest computation.  A Response
  MAC value is computed in three situations: from a Request message,
  for inclusion in a Membership Query message; from a Membership Update
  message, to authenticate the Response MAC carried within that message;
  and from fields in a Teardown message, to authenticate the Response
  MAC carried within that message.
END

  Gateways treat the Response MAC field as an opaque value, so a relay
  implementation may generate the MAC using any method available to it.
  The hash function RECOMMENDED for use in computing the Response MAC
  is the MD5 hash digest [RFC1321], though hash functions or keyed-hash
  functions of greater cryptographic strength may be used.

Why is this a 2119 "RECOMMENDED"?  Is there any reason the *protocol* cares what hash algorithm is used?

-- Section 5.3.3.3 --

  If a relay supports the Teardown message, it MUST set the G-flag in
  the Membership Query message and return the source IP address and UDP
  port carried by the Request message in the corresponding Gateway IP
  Address and Gateway Port Number fields.  If the relay does not
  support the Teardown message it SHOULD NOT set these fields as this
  may cause the gateway to generate unnecessary Teardown messages.

What reason might a relay have for violating that SHOULD NOT?  Why would a relay that does not support Teardown sometimes need to set those fields, such that "SHOULD NOT" (rather than "MUST NOT") is necessary?

-- Section 5.3.3.4 --

  A relay MUST maintain some form of group membership database for each
  endpoint.  The per-endpoint databases are used update a forwarding
  table containing entries that map an (*,G) or (S,G) subscription to a
  list of tunnel endpoints.

  A relay MUST maintain some form of group membership database
  representing a merger of the group membership databases of all
  endpoints.  The merged group membership database is used to update
  upstream multicast forwarding state.

  A relay MUST maintain a forwarding table that maps each unique (*,G)
  and (S,G) subscription to a list of tunnel endpoints.  A relay uses
  this forwarding table to provide the destination address when
  performing UDP/IP encapsulation of the incoming multicast IP
  datagrams to form Multicast Data messages.

I don't really want to pick on these too much, mostly because I can't imagine how *else* you might do this other than maintaining databases/tables, but...

Strictly speaking, the 2119 keywords should be calling out protocol requirements, not implementation methods.  It seems that the requirements are actually in the second sentence of each paragraph, and the MUSTs should be attached to those.  I'll use the second one as an example; perhaps this?:

NEW-maybe
  A relay MUST be able to update the upstream multicast forwarding
  state [a little more is needed here].  This is typically done by
  having the relay maintain some form of group membership database
  representing a merger of the group membership databases of all
  endpoints.
END

I would prefer it if you could re-cast each of these three paragraphs to attach the MUST to the actual protocol requirement, and talk about databases and forwarding tables as exemplary implementations (rather than attaching the MUST to the implementation).

That said, I'll remind you that this is a non-blocking comment, and if you think it will make the spec more awkward or less clear, then please don't do that.

[Ballot comment]

  The reference to RFC 1321 should be informative (not normative).

  Please consider the editorial suggestions in the Gen-ART Review
  by Mary Barnes on 14-Dec-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07993.html

IANA has reviewed draft-ietf-mboned-auto-multicast-14 and has the following comments:

IANA has questions about the IANA actions requested in this document.

The title of 7.1 is "IPv4 and IPv6 Anycast Prefix Allocation". IANA understands this to mean that the authors actually want unicast prefixes which will be used for anycast routing. RFC 3513, section 2.4 notes that "Anycast addresses are taken from the unicast address spaces (of any scope) and are not syntactically distinguishable from unicast addresses."

IANA believes that 7.1.1 could be more efficiently written as "IANA has assigned 154.7.0/24 for IPv4 AMT Relays."

IANA would also prefer that 7.1.2 should use similar language and we would like to propose 2001:0003::/32 as a prefix.

IANA believes that 7.2 could be more efficiently written as "IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses."

In 7.3 it says "IANA has reserved UDP port number 2268 for AMT." It is not clear to IANA if the authors are asking for a reservation to be turned into an assignment or noting an action that was previously taken and does not need to be modified. IANA has examined the ports registry and can see the registration but no link to an I-D or RFC. Do the authors want the current registrant name to be replaced with this I-D and the RFC number when it is approved?

IANA also believes these prefixes should be registered in the IANA IPv4 and IPv6 Special Registries. It would be helpful if the authors could provide the basic data for the registry in addition to the prefix:

Assignment
Termination Date
Purpose
Contact Details
Routing Scope
Reference

The routing scope is particularly helpful for the future as IANA will use it when developing a set of RPKI objects as defined in RFC 6491.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Automatic Multicast Tunneling) to Proposed Standard


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:
- 'Automatic Multicast Tunneling'
  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
ietf@ietf.org mailing lists by 2012-12-19. 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 describes Automatic Multicast Tunneling (AMT), a
  protocol for delivering multicast traffic from sources in a
  multicast-enabled network to receivers that lack multicast
  connectivity to the source network.  The protocol uses UDP
  encapsulation and unicast replication to provide this functionality.

  The AMT protocol is specifically designed to support rapid deployment
  by requiring minimal changes to existing network infrastructure.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mboned-auto-multicast/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mboned-auto-multicast/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

(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

  The advantages and benefits provided by multicast technologies are
  well known.  There are a number of application areas that are ideal
  candidates for the use of multicast, including media broadcasting,
  video conferencing, collaboration, real-time data feeds, data
  replication, and software updates.  Unfortunately, many of these
  applications lack multicast connectivity to networks that carry
  traffic generated by multicast sources.  The reasons for the lack of
  connectivity vary, but are primarily the result of service provider
  policies and network limitations.

  Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based
  encapsulation to overcome the aforementioned lack of multicast
  connectivity.  AMT enables sites, hosts or applications that do not
  have native multicast access to a network with multicast connectivity
  to a source, to request and receive SSM [RFC4607] and ASM [RFC1112]
  traffic from a network that does provide multicast connectivity to
  that source.

Working Group Summary

  This document has received strong support from the working group and no
  major controversies exist today with this document.

Document Quality

  A number of AMT implementations exist today and significant deployment
  experience has been documented.  This document has received thorough
  review from the working group, and many have contributed to this effort
  over the last 11+ years.  In particular, Dave Thaler, Tom Pusateri,
  Thomas Morin and Greg Bumgardner deserve credit for most of the
  authorship of this document, and Bob Sayko, Doug Nortz and their
  colleagues at ATT deserve credit for extremely thorough review of the
  document.

Personnel

  Lenny Giuliano is the Document Shepherd, Ron Bonica is the
  Responsible Area Director.

IANA Note

  IANA Considerations

  IPv4 and IPv6 Anycast Prefix Allocation

  IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to
  the public AMT Relays to advertise to the native multicast backbone
  (as described in Section 4.1.4).  The prefix length should be
  determined by the IANA; the prefix should be large enough to
  guarantee advertisement in the default-free BGP networks.

  IPv4

  A prefix length of 24 will meet this requirement.

  Internet Systems Consortium (ISC) has offered 154.7.0/24 for this
  purpose.

  IPv6

  A prefix length of 32 will meet this requirement.  IANA has
  previously set aside the range 2001::/16 for allocating prefixes for
  this purpose.

  IPv4 Address Prefix Allocation for IGMP Source Addresses

  IANA should allocate an IPv4 prefix dedicated for use in IGMP
  messages exchanged between gateways and relays.  This address range
  is intended for use within tunnels constructed between a gateway and
  relay, and as such, is not intended to be globally routable.

  A prefix length of 24 will meet this requirement.

  Internet Systems Consortium (ISC) has offered 154.7.1/24 for this
  purpose.

  UDP Port number

  IANA has reserved UDP port number 2268 for AMT.

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

Document was reviewed by the Shepherd, who feels it is ready for
publication.

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

No, the document has undergone thorough review from a number of folks
in the WG.

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

Not that I am aware of.

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

No concerns.  Doc has been thoroughly reviewed and all issues seem to be
resolved.

(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

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

Not aware of any, nor any recollection of any WG discussion regarding IPR.

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

The WG as a whole appears to understand and agree with it.

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

Not that I am aware of.

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

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

Not aware of any.

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

Yes, there are both normative and informative references.

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

Not that I am aware of.  All normative references point to RFCs.

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

There are no normative references to any informational RFCs.

(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

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

Looks good to me.

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

See IANA considerations above.

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