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

From: Marshall Eubanks <[email-masked]>
Date: Thu, 24 Apr 2008 11:31:08 -0400

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 [email-masked]  Thu Apr 24 08:31:25 2008
From: Marshall Eubanks <[email-masked]>
To: Pekka Savola <[email-masked]>
Date: Thu, 24 Apr 2008 11:31:08 -0400
Cc: [email-masked]
Subject: Re: [MBONED] draft-cotton-v4mcast-guidelines-00.txt
Sender: [email-masked]

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Apr 2008 08:19:47 +0300 (EEST)

On Thu, 24 Apr 2008, Marshall Eubanks wrote:
>> 3) the document keeps the previous "Expert review" guideline, yet offers no
>>  evaluate the requests.  draft-narten-iana-considerations-rfc2434bis talks
>>  about this (Section 3):
>>
>>  This "default" doesn't seem useful and if we keep having Expert review,
> 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

draft-narten-iana-considerations-rfc2434bis-09.txt S 3.2 seems to 
indicate that at least someone thinks that in an ideal case, they 
should be wherever the registry is created or updated:

    Ideally, the designated expert follows
    specific review criteria as documented with the protocol that creates
    or uses the namespace. (See the IANA Considerations sections of
    [RFC3748,RFC3575] for examples that have been done for specific name
    spaces).

.. but different kinds of registries may require different kinds of 
treatment and S3.2 and S3.3 of that draft discusses this pretty well. 
This may be something that ADs and/or other IETF WGs have had 
experience on if we knew how to get that (ietf list?  wgchairs list?).

I think this I-D needs to establish at least high-level expectations 
(e.g., default accept/deny, major conditions for acceptal/refusal, 
whether this depends on the block from which addresses are requested).

I'd uncomfortable if that was done only on a web page or some other 
place that doesn't go through the IETF process.

However, if we want to document very detailed instructions, I agree 
that those don't necessarily need to be in an RFC.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Apr 2008 08:19:47 +0300 (EEST)