Subject: [MBONED] draft-cotton-v4mcast-guidelines-00.txt

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Mar 2008 04:16:22 +0200 (EET)

More detailed comments on draft-cotton-v4mcast-guidelines-00.txt.

Major issues:

1) I believe we should change ADHOC assignment policy at this stage.
    Current and proposed policy allows allocating large blocks of addresses;
    either at once or in a staged fashion.

    Given that we have GLOP, (soon) IPv4-unicast-prefix-based,
    administratively scoped addresses and also SSM, I don't believe it's
    appropriate to continue with the current trend.

    I suggest that each organization can be assigned a maximum of one
    multicast address per year.

2) Allocation vs assignment terminology needs to be cleaned up to be
    consistent with unicast terminology and draft-ietf-mboned-addrarch.

3) the document keeps the previous "Expert review" guideline, yet offers no
    help to the expert or the community as how the expert is supposed to
    evaluate the requests.  draft-narten-iana-considerations-rfc2434bis talks
    about this (Section 3):

    "In the case where a designated expert is used,
    but there are no specific documented criteria for performing an evaluation, the
    presumption should be that a code point should be granted, unless
    there is a compelling reason to the contrary."

    This "default" doesn't seem useful and if we keep having Expert review,
    guidelines should be established.

Substantial but minor points:
  - The header needs to have "Obsoletes: 3138" because this document in
    effect kills eGLOP as specified in 3138.  3138 should also be moved to
    Historic.
  - The header should also say "Obsoletes: 3171" and abstract/intro say
    that this document replaces 3171.  We should instruct RFC-editor to
    re-use the BCP number for this document.
  - draft-ietf-mboned-addrarch should probably be referred as an
    informational reference about addressing architectures.
  - in section 5 (Internetwork control block) "must be forwarded through the
    Internet" --> s/must/may/ (this document is no place to mandate this)
  - likewise in section 6 (AD-HOC) "these addresses are globally routed" -->
    s/are/may be/.  Most of these currently aren't!
  - section 12.2 refers to temporary assignment which has not been defined in
    the draft or current policies (AFAICS)?
  -

Editorial:
  - The document has no newlines and has a huge number of ID-nits.

  - I'd probably name the AD-hoc blocks in Section 6 and Section 9.2 as
    AD-HOC1 and AD-HOC2 and treat them separately -- because the current
    document structure follows address space, not its use case.

  - S 11.1 the first three sentences are very awkward, and difficult to
    parse:

      Occasionally, more than one multicast address is required.  In these
    cases multiple addresses are available.  Where are very large number
    of addresses is required, the assignment will be staged, ...

  - IANA considerations needs to be made explicit on what IANA is supposed to
    do with this document.  Maybe: "IANA is requested to update its IPv4
    multicast assignments and associated policies to reflect this document".

  - RFC2026, 2770, 2908, 2909 are not used and should be removed from the
    references section.

  - RFC1190 reference should be added in the text or the reference removed.
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Mar 2008 04:16:22 +0200 (EET)

Major issues:

Editorial: