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

Pekka Savola <pekkas@netcore.fi> Mon, 10 March 2008 02:18 UTC

Return-Path: <mboned-bounces@ietf.org>
X-Original-To: ietfarch-mboned-archive@core3.amsl.com
Delivered-To: ietfarch-mboned-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F94C3A67F2; Sun, 9 Mar 2008 19:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.363
X-Spam-Level:
X-Spam-Status: No, score=-100.363 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u40Zoyos51yi; Sun, 9 Mar 2008 19:18:56 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AE03A68B9; Sun, 9 Mar 2008 19:18:56 -0700 (PDT)
X-Original-To: mboned@core3.amsl.com
Delivered-To: mboned@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966683A68B9 for <mboned@core3.amsl.com>; Sun, 9 Mar 2008 19:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-mZMgi3depC for <mboned@core3.amsl.com>; Sun, 9 Mar 2008 19:18:54 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 0D5273A67F2 for <mboned@ietf.org>; Sun, 9 Mar 2008 19:18:53 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2A2GPEv030390; Mon, 10 Mar 2008 04:16:25 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2A2GMsr030387; Mon, 10 Mar 2008 04:16:25 +0200
Date: Mon, 10 Mar 2008 04:16:22 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Marshall Eubanks <tme@multicasttech.com>
In-Reply-To: <alpine.LRH.1.00.0802180905210.24060@netcore.fi>
Message-ID: <alpine.LRH.1.00.0803100415070.30323@netcore.fi>
References: <C3CF7440.B551%michelle.cotton@icann.org> <82FDB1A0-8CED-4C5C-9B04-A50AC9157E3D@multicasttech.com> <E1101EBA-69EB-458A-AA29-0FD11EF1CAF7@multicasttech.com> <alpine.LRH.1.00.0802180905210.24060@netcore.fi>
User-Agent: Alpine 1.00 (LRH 882 2007-12-20)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.92.1/6188/Sun Mar 9 21:28:13 2008 on otso.netcore.fi
X-Virus-Status: Clean
Cc: mboned@ietf.org
Subject: [MBONED] draft-cotton-v4mcast-guidelines-00.txt
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mboned-bounces@ietf.org
Errors-To: mboned-bounces@ietf.org

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
MBONED@ietf.org
https://www.ietf.org/mailman/listinfo/mboned