[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-ipngwg-icmp-v3-04.txt



Pekka,

At 01:58 AM 6/4/2004, Pekka Savola wrote:
>On Thu, 3 Jun 2004 Internet-Drafts@ietf.org wrote:
> >       Title           : Internet Control Message Protocol (ICMPv6)for 
> the Internet
> >                         Protocol Version 6 (IPv6) Specification
> >       Author(s)       : A. Conta, S. Deering
> >       Filename        : draft-ietf-ipngwg-icmp-v3-04.txt
> >       Pages           : 26
> >       Date            : 2004-6-3
>
>I must object to the current IANA considerations section 6.1 on
>type/code assignment.

Thanks for the feedback.

>Subcases 1) and 3) are too loose.  Just make it 'IETF Consensus',
>'IESG Approval', or 'IESG Approval with Specification Required'.
>
>We really don't need a land-rush for ICMP types/codes.  On the other
>hand, there is a valid need for pre-assignment.  This would be worth
>having in-line with draft-kompella-zinin-early-allocation-01.txt.

I don't think there is any evidence of a "land-rush" and even if there were 
it's fairly trivial to expand the type range.  The thinking behind this 
approach is that as long as there is an open specification, there isn't any 
compelling reason to limit allocations to IETF approval.

The goal is to make it easy for a w.g. to get allocations early in the 
process so people can get implementation experience and avoid collisions if 
the protocol becomes widely deployed.  Having to wait until there is IESG 
approval makes it much harder or risky to do deployment.

>Also note that you're burdening IANA with the responsibility of
>monitoring the assignment of type values and reporting back when they
>exceed a threshold.  One could argue that IANA is too burdened as it

While the IANA may or may not have resource issues, the "burden" placed on 
the IANA is fairly trivial.  If the allocations get to the 85% point, all 
the IANA has to do is to ask to IETF to review the allocations.  This 
doesn't seem very burdensome to me.  IMHO we won't ever get to that point 
based on the history with the IPv4 ICMP allocations and IPv6 to date.

>is.  All in all, I think the text for IANA considerations is not
>sufficiently baked, and we could spend 6 months arguing about it, so
>I'd suggest just using the procedure described in
>draft-kompella-zinin-early-allocation-01.txt for early allocation, and
>relatively strict process for permanent allocation, and be done with
>it.
>
>A nit:
>
>    1. The IANA should allocate and permanently register new ICMPv6 type
>       codes from IETF RFC publication.  This is for all RFC types
>       including standards track, informational, experimental status,
>       etc.
>
>==> did you really mean that only _IETF_ RFCs an allocate types? (Not
>that I would object to that..)  Note that RFCs which went through the
>direct submission to the RFC-editor are not IETF RFCs.

Yes, this does mean IETF RFCs.  Paragraph 3. covered non-IETF requests 
including non-IETF RFCs.

Thanks for the comments.  Input from others is very welcome.

Bob



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------