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

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



I was hoping others would comment, but maybe not. Inline..

On Fri, 4 Jun 2004, Bob Hinden wrote:
> >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.

I'm not sure if I agree.  If you have an open specification, and if
your use of types/codes is reasonable (e.g., you don't try to use 10
different types when you could just use one type and 10 codes), there
should be no problem getting the ICMP types you want.  Note that IESG
approval does not require to submit the document to the IETF process;  
you can just send a mail to iesg@ietf.org with a pointer to the open
specification and you might get your codepoint -- and this has the
benefit that with the current process, any IETF RFCs already go past
that point.

I don't want to prevent the legitimate, well-designed use of ICMP
types/codes, but I don't want to create rules which would allow anyone
with an open specification to get e.g. 5 or 10 types (in that single
document) if they tried to.

Requiring IESG Approval is one way to obtain that.  Some other WGs use
"Expert Review".  There may be other options.  Just specifying e.g.,
"IESG Approval of an open specification" should be pretty close to
what you're describing, but closer to RFC2434 language, and also more
future-proof.
 
> >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.

Yes, this doesn't seem very burdensome, but it's still a new 
responsibility they'd have to be doing.

Btw. the IANA considerations section doesn't seem to be specify the 
assignment policy for the code values for the existing ICMP types (see 
the last paragraph of 6.1).  I guess these should be added in section 
6.2.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



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