IANA Guidelines for IPv4 Multicast Address Assignments
draft-ietf-mboned-rfc3171bis-08

[Ballot discuss]
Section 4.1. I'm confused about Expert Review,
  IESG Approval or Standards Action process. Is this Expert Review followed by IESG approval or is it "Expert Review or IESG Approval". The text in 2780 is even more confusing where the sentence

  New values in this range are
  assigned following an IESG Approval or Standards Action process.

seems to contradict the following sentence

  Assignments of individual multicast address follow an Expert Review,
  IESG Approval or Standards Action process.

Can someone help me get unconfused by what this all means.

[Ballot discuss]
This is mainly a procedural discuss; I wanted to be sure the authors had seen Tina Tsou's
secdir review from 10/22.  I do not consider the issues blocking, and I will clear once I
know that authors have responded to the review.

[Ballot comment]
I agree that yearly review of assigned ranges by IANA is excessive.  There's already a requirement for IANA to freeing up unrenewed registrations within 30 days.  A single review of the registry triggered by this document, followed by that renewal/freeing process, ought to suffice for the next few years.

[Ballot discuss]
Section 12: Annual Review. I have no idea what IANA is supposed to review or do. Could this be more specific. I'm also a bit dubious that anything at IETF needs to be done as often as every year.


Section 4.1. I'm confused about Expert Review,
  IESG Approval or Standards Action process. Is this Expert Review followed by IESG approval or is it "Expert Review or IESG Approval". The text in 2780 is even more confusing where the sentence

  New values in this range are
  assigned following an IESG Approval or Standards Action process.

seems to contradict the following sentence

  Assignments of individual multicast address follow an Expert Review,
  IESG Approval or Standards Action process.

Can someone help me get unconfused by what this all means.


10.1 Just because a packet is scoped to stay within the domain, I don't understand why that means we don't need a registration procedure with well known addressees. Imagine I want to build some multicast service to find other IM client within the domain, or say printers. Building a protocol that requires the admin to pick and configure an address for every device they deploy that uses the protocol is just not practical. Can we have a registry for at least some subset of the admin scoped space.


8.1 SSM. I agree that in many uses cases SSM assignments are not needed. But it seems like in some cases it might be useful to have some for certain cases.  Seem my comment on point 10.1 above.

[Ballot comment]
The Gen-ART Review by Miguel Garcia on 19-Oct-2009 included some
  suggestions:

  - Due to the nature of the draft, I think it makes sense to promote
    RFC 5226 to a normative reference.

  - Expand terms at the first occurrence. This includes:
    Section 1: SDP, SAP, GLOP, SSM
    Section 8: VMTP
    Section 9: ASN
    Section 9.2: RIR, AS, eGLOP

  - Section 9.2 contains two similar abbreviations: eGLOP and EGLOP.
    Those are probably the same and should be unified.

  - The document uses quite a few references to URLs. The RFC Editor
    does not like this approach because URLs often change with time. So,
    I would suggest to refer to the title of the web page instead. It
    might be possible that the RFC Editor accepts the addition of a
    reference to a URL (which should be valid for some time), but the
    main link should be done to the content, not to the URL. This
    includes:

    Section 1: http://www.iana.org/numbers.html
    This page is already obsolete, and the URL redirects to
    http://www.iana.org/protocols/; I suggest to refer to the "IANA
    Protocol Registries [IANA-protocols]", and the link is in the
    reference [IANA-protocols].

    Section 11: http://www.iana.org/protocols/apply
    I suggest to refer to the "IANA Protocol Registration Forms
    [IANA-registration]", moving the link to the [IANA-registration]
    reference.

  - There is no reference to [SDR], used in Section 7.

  - Reference to RFC 1190 is obsolete. RFC 1819 should be used instead.

  - Reference to RFC 2030 is obsolete. RFC 4330 should be used instead.

[Ballot discuss]
The cover page shows that this document, once approved, obsoletes
  RFC 3171 and RFC 3138.  Section 1 says that this document also
  updates RFC 2780.  The cover page needs to reflect this too.  An
  RFC Editor Note seems like a fine solution.

IANA comments:

Action 1:

Upon approval of this document, IANA will make the following
changes in "IPv4 Multicast Address Space Registry" registry at
http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
sub-registry "Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))"

OLD:

Reference
[RFC3171]

NEW:

Reference
[RFC-mboned-rfc3171bis-07]


Action 2:

Upon approval of this document, IANA will make the following
changes in "IPv4 Multicast Address Space Registry" registry at
http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
sub-registry "Internetwork Control Block (224.0.1.0 - 224.0.1.255 (224.0.1/24))"

OLD:

Reference
[RFC3171]
Registration Procedures
Expert Review

NEW:

Reference
[RFC-mboned-rfc3171bis-07]
Registration Procedures
Expert Review, IESG Approval, or Standards Action


Action 3:

Upon approval of this document, IANA will make the following
changes in "IPv4 Multicast Address Space Registry" registry at
http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
sub-registry "AD-HOC Block (224.0.2.0 - 224.0.255.0)"

OLD:

Reference
[RFC3171]
Registration Procedures
Expert Review

NEW:

Reference
[RFC-mboned-rfc3171bis-07]
Registration Procedures
Expert Review, IESG Approval, or Standards Action


Action 4:

Upon approval of this document, IANA will make the following
changes in "IPv4 Multicast Address Space Registry" registry at
http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
sub-registry "SDP/SAP Block (224.2.0.0-224.2.255.255 (224.2/16))"

OLD:

Reference
[RFC3171]
Registration Procedures
Expert Review

NEW:

Reference
[RFC-mboned-rfc3171bis-07]
Registration Procedures
No assignments are required

Action 5:

Upon approval of this document, IANA will make the following
changes in "IPv4 Multicast Address Space Registry" registry at
http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
sub-registry "Source-Specific Multicast Block (232.0.0.0-232.255.255.255 (232/8))"

OLD:

Reference
[RFC3171]

NEW:

Reference
[RFC-mboned-rfc3171bis-07]

IANA will make sure that the registry address group titles match
the document address group titles.

IANA will also make it more clear where the relative offsets can be
found in the registry (as mentioned in Section 10.1.1).