Overview of the Internet Multicast Addressing Architecture
draft-ietf-mboned-addrarch-07

[Ballot comment]
Section 6 says...

  This memo includes no request to IANA.

  IANA considerations in sections 4.1.1 and 4.1.2 of obsoleted and now
  Historic [RFC2908] were never implemented in IANA registry.  No
  update is necessary.

  (RFC-editor: This section may be removed prior to publication;
  alternatively, the second paragraph may be left intact.)

Please do keep the second paragraph at least for Historians, but also for clarity.

[Ballot comment]
The abstract doesn't capture the last sentence of the introduction: 
"This memo obsoletes and re-classifies to Historic RFC 2908, and re-classifies to Historic RFCs 2776 and 2909."

TSVDIR review by Joe Touch


Hi, all,

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
tsv-dir@ietf.org if you reply to or forward this review.

The document describes the various mechanisms for IP multicast address
allocation (delegating a group of addresses for further assignment) and
assigment (assigning addresses for use). The document currently
addresses no transport issues.

There is one notably missing transport issue that should be addressed
prior to publication. The document discusses the use of specific
multicast addresses by individual applications, but does not currently
address the relationship of multicast addresses to transport identifiers
(e.g., port numbers or service names).

The note below includes the significant transport issues, as well as
additional comments that are optional but I hope also useful.

I hope this feedback will be useful to the authors, and will be glad to
provide further assistance either on- or off-list as useful.

Joe

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

Transport issues include:

- sec 2.4 currently discusses use of multicast by applications
Sec 3.4.1 especially should discuss the relationship between multicast
addresses and transport identifiers for per-application use, and when
each (or both) are useful. E.g., sharing a multicast address reduces
network state, but prevents optimizing distribution trees per service.
Sharing a multicast address (e.g., if one were assigned to "all
backups", as one is currently assigned for "all routers") could reduce
the need for per-application multicast addresses, but requires
coordinated transport identifiers (e.g., assigned ports). Using
multicast addresses as transport identifiers could obviates the need for
a globally-assigned port number.

- the discussion in sec 3.4.1 needs revision
The discussion should focus on facts, rather than stating the facts
inside judgements (e.g., remove 'lucrative', and 'land grab'). The facts
appear to be that they're global and limited, and that self-assignments
can conflict with IANA assignments; this is no different from the port
numbers space. The key issue is that the appropriate spaces are much
smaller (8-bits in the Internetwork block, but 24 bits in the admin
scoped block)

Sec 3.5 list item #2 is inconsistent with the discussion in sec 3.4.1
If IANA global assignments are the most common static assignments, then
that should be indicated in sec 3.4.1. ]

This section should explain "last resort" as used in the tables in sec
4, and whether that is expected to persist if admin scoped addrs are
statically assigned

- sec 4.3 should discuss potential future resolution of the relationship
between multicast addresses and transport identifiers in separating
application traffic

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

Some other comments (hopefully optionally useful):

- the document moves RFC 2909 to historic
RFC 2909 was experimental; it's not clear it's necessary to move it to
historic.

- it would be useful for the intro to explain why addresses are
assigned, and what assignments are useful (e.g., in some cases, to speak
to groups of devices, in others, for a service or application)

- the document should include some examples of current static
assignments, e.g., 'all routers'

- sec 2.4 describes "*seriously* implemented"
This should be clarified as 'widely', 'robustly', or some other term
that explains the deficiency.

- sec 2.4 discussion of Norton Ghost seems misplaced
It refers to an assignment issue, not an allocation one; it should be
moved to somewhere in sec 3

- the tables in sec 4 use terms like "last resort" which are
inconsistent with the discussion in previous sections (notably 3.4.1
doesn't talk about that).

- the tables in sec 4 should indicate the size of the available space
e.g., total bits available, and typical allocation or assignment size
(if known, or a range if appropriate). This would further assist those
asking for addresses in determining the appropriate approach.

Further, these tables could be expanded to summarize info already
presented to further help those asking:
  * replace "yes" with "self/dynamic/static" to differentiate
  between (respectively) those internally calculated, those
  obtained by a protocol exchange, and those obtained from IANA
  or a registrar
* explaining whether collisions can occur (or at least are
  prevented by assignment/protocol)
* indicate which multicast block is assigned/allocated using
  the given mechanism

- sec 5 first paragraph wording would benefit from revision
E.g., starting with "This work was inspired and movtivated by ..."; the
current text doesn't parse as a complete sentence.

----

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Overview of the Internet Multicast Addressing Architecture) to Informational RFC


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:
- 'Overview of the Internet Multicast Addressing Architecture'
  as an Informational RFC

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 2011-03-28. 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.

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

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

Abstract

  The lack of up-to-date documentation on IP multicast address
  allocation and assignment procedures has caused a great deal of
  confusion.  To clarify the situation, this memo describes the
  allocation and assignment techniques and mechanisms currently (as of
  this writing) in use.

Technical Summary

Good, up-to-date documentation of IP multicast is close to non-
existent. Particularly, this is an issue with multicast address
allocations (to networks and sites) and assignments (to hosts and
applications). This problem is stressed by the fact that there
exists confusing or misleading documentation on the subject
[RFC2908]. The consequence is that those who wish to learn about IP
multicast and how the addressing works do not get a clear view of the
current situation.

The aim of this document is to provide a brief overview of multicast
addressing and allocation techniques. The term 'addressing
architecture' refers to the set of addressing mechanisms and methods
in an informal manner.

It is important to note that Source-specific Multicast (SSM)
[RFC4607] does not have these addressing problems because SSM group
addresses have only local significance; hence, this document focuses
on the Any Source Multicast (ASM) model.

This memo obsoletes and re-classifies to Historic RFC 2908, and re-
classifies to Historic RFCs 2776 and 2909.

Working Group Summary

WG consensus appears sound and no major controversies were noted.

Document Quality

The document has undergone thorough review within IETF's Multicast
community. This document was previously submitted for publication
several years ago, but changes were suggested during AD review. The
suggested changes have been made.

Personnel

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

State Change Notice email list has been changed to Hiroshi Ohta , Marshall Eubanks , psavola@funet.fi, lenny@juniper.net from Hiroshi Ohta , Marshall Eubanks , psavola@funet.fi

Forwarded my review to working group chairs and authors.
They will summarize and discuss how to deal with the issues brought up,
particularly:

Part of my comments stem from the fact that thiss document is proposed
for BCP, but there is a lot of guidance in there that is not
necessarily of the kind that syas 'this is the best current practise',
but more like a discussion of issues or mentions that IANA policy
should be thightened up but not mentioning how IANA is supposed to do
that. Discussions of issues fit in my opinion better in an
informational document so that it is clear that there is no IANA
action proposed, more that the document signals that there is an issue
and that IETF perhaps should work on getting bewtter guidance to IANA.

At the same time, this document mentions a few protocols that are in
disuse or not workable. In that case, I believe the working group
should get over it and formally ask the IESG to classify as historic.
This document could be an excellant opportunity to do so.

State Change Notice email list have been change to Hiroshi Ohta <ohta.hiroshi@lab.ntt.co.jp>, Marshall Eubanks <tme@multicasttech.com>, psavola@funet.fi from dmm@1-4-5.net, dmm@uoregon.edu, dmm@cisco.com

PROTO Write-up

When a draft is ready to be submitted for publication, it is the task
of the Shepherding WG Chair to do a document write-up for the draft.
There are two parts to this task. First, the Shepherding WG Chair
answers questions 1.a to 1.h below to give the Responsible Area
Director insight into the working group process as applied to this
draft. Note that while these questions may appear redundant in some
cases, they are written to elicit information that the AD must be
aware of (to this end, pointers to relevant entries in the WG archive
will be helpful). The goal here is to inform the AD about any issues
that may have come up in IETF meetings, on the mailing list, or in
private communication that they should be aware of prior to IESG
evaluation of the shepherded draft. Any significant issues mentioned
in the questionnaire will probably lead to a follow-up discussion
with the AD.

The second part of the task is to prepare the "Protocol Write-Up"
which is used both for the ballot write-up for the IESG telechat and
for the the IETF-wide protocol announcement. Item number 1.i
describes the elements of the write-up. Please see other protocol
announcements in the IETF Announce archive for examples of such
write-ups.

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Yes, I reviewed this document and I think it is ready to
forward to the IESG for publication. Hiroshi Ohta is the WG
Chair Shepherd for this document.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

Yes, I believe so. -05 version is an editorial update version
from -04 version. There were no negative comments during the
WGLC for -05 version.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No, I do not have any concern. The initial version of this
document was submitted about two years ago and there was no
negative comments up to now.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No, I do not have any specific concern.

1.e) 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?

I believe the consensus is acceptable level. There are not
many comments on the ML but none of the comments are negative.


1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).

No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes. This check found no nits.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

Yes, this document splits its references into normative and
informative. All the normative references are RFCs.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

The lack of up-to-date documentation on IP multicast address
allocation and assignment procedures has caused a great deal of
confusion. To clarify the situation, this memo describes the
allocation and assignment techniques and mechanisms currently
(as of this writing) in use.


* Working Group Summary

There was not any controversy about this document. There are
not many comments on the ML but none of the comments are negative.


* Protocol Quality

This document surveys the currently proposed/used protocols but
it does not propose any new protocol.


1.j) Please provide such a write-up. Recent examples can be found in
the "Action" announcements for approved documents.

1.k) Note:

* The relevant information for the technical summary can
frequently be found in the abstract and/or introduction of
the document. If not, this may be an indication that there
are deficiencies in the abstract or introduction.

* For the Working Group Summary: Was there anything in WG
process that is worth noting? For example, was there
controversy about particular points, decisions where
consensus was particularly rough, etc.

* For the protocol quality, useful information includes:

+ Are there existing implementations of the protocol?

+ Have a significant number of vendors indicated they
plan to implement the specification?

----------------------- end -----------------------

PROTO Write-up

When a draft is ready to be submitted for publication, it is the task
of the Shepherding WG Chair to do a document write-up for the draft.
There are two parts to this task. First, the Shepherding WG Chair
answers questions 1.a to 1.h below to give the Responsible Area
Director insight into the working group process as applied to this
draft. Note that while these questions may appear redundant in some
cases, they are written to elicit information that the AD must be
aware of (to this end, pointers to relevant entries in the WG archive
will be helpful). The goal here is to inform the AD about any issues
that may have come up in IETF meetings, on the mailing list, or in
private communication that they should be aware of prior to IESG
evaluation of the shepherded draft. Any significant issues mentioned
in the questionnaire will probably lead to a follow-up discussion
with the AD.

The second part of the task is to prepare the "Protocol Write-Up"
which is used both for the ballot write-up for the IESG telechat and
for the the IETF-wide protocol announcement. Item number 1.i
describes the elements of the write-up. Please see other protocol
announcements in the IETF Announce archive for examples of such
write-ups.

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Yes, I reviewed this document and I think it is ready to
forward to the IESG for publication. Hiroshi Ohta is the WG
Chair Shepherd for this document.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

Yes, I believe so.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No, I do not have any concern. The initial version of this
document was submitted about two years ago and there was no
negative comments up to now.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No, I do not have any specific concern.

1.e) 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?

I believe the consensus is acceptable level. There are not
many comments on the ML but none of the comments are negative.


1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).

No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

Yes, this document splits its references into normative and
informative. There are two IDs in normative references but I
believe they are quite mature since they are -09 and -07
versions of WG documents.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

The lack of up-to-date documentation on IP multicast address
allocation and assignment procedures has caused a great deal of
confusion. To clarify the situation, this memo describes the
allocation and assignment techniques and mechanisms currently (as of
this writing) in use.


* Working Group Summary

There was not any controversy about this document. There are
not many comments on the ML but none of the comments are negative.


* Protocol Quality

This document surveys the currently proposed/used protocols but
it does not propose any new protocol.


1.j) Please provide such a write-up. Recent examples can be found in
the "Action" announcements for approved documents.

1.k) Note:

* The relevant information for the technical summary can
frequently be found in the abstract and/or introduction of
the document. If not, this may be an indication that there
are deficiencies in the abstract or introduction.

* For the Working Group Summary: Was there anything in WG
process that is worth noting? For example, was there
controversy about particular points, decisions where
consensus was particularly rough, etc.

* For the protocol quality, useful information includes:

+ Are there existing implementations of the protocol?

+ Have a significant number of vendors indicated they
plan to implement the specification?