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

[Marshall Eubanks <[e-mail]>]

On Mar 9, 2008, at 10:16 PM, Pekka Savola wrote:

> 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 seFrom [e-mail]  Thu Apr 24 08:31:25 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CB0293A6AF2;
	Thu, 24 Apr 2008 08:31:25 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5F5473A6AC0
	for <[e-mail]>; Thu, 24 Apr 2008 08:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.58
X-Spam-Level: 
X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=-0.137, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156]
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 AymJ607gVjH4 for <[e-mail]>;
	Thu, 24 Apr 2008 08:31:21 -0700 (PDT)
Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7])
	by core3.amsl.com (Postfix) with ESMTP id 5CE1E3A6AF2
	for <[e-mail]>; Thu, 24 Apr 2008 08:31:03 -0700 (PDT)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP-TLS id 11148831; Thu, 24 Apr 2008 11:31:08 -0400
Message-Id: <[e-mail]>
From: Marshall Eubanks <[e-mail]>
To: Pekka Savola <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 24 Apr 2008 11:31:08 -0400
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
X-Mailer: Apple Mail (2.919.2)
Cc: [e-mail]
Subject: Re: [MBONED] draft-cotton-v4mcast-guidelines-00.txt
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mboned>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]


On Mar 9, 2008, at 10:16 PM, Pekka Savola wrote:

> 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 em useful and if we keep having Expert  
> review,
>   guidelines should be established.

Dear Pekka;

I have been considering this point; my feeling is that guidelines  
would be useful. Do you or the WG have any suggestions ?

I would assume that these would be separate from this document, and  
maybe not even an RFC, as they might need to be
changed frequently. Opinions on that point would also be welcomed.

Regards
Marshall


>
>
>
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/mboned


seem useful and if we keep having Expert  
> review,
>   guidelines should be established.

Dear Pekka;

I have been considering this point; my feeling is that guidelines  
would be useful. Do you or the WG have any suggestions ?

I would assume that these would be separate from this document, and  
maybe not even an RFC, as they might need to be
changed frequently. Opinions on that point would also be welcomed.

Regards
Marshall


>
>
>
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/mboned