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

From: [email-masked]
Date: Thu, 03 Jun 2004 15:51:41 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.

	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
	
   This document describes the format of a set of control messages used
   in ICMPv6 (Internet Control Message Protocol).  ICMPv6 is the
   Internet Control Message Protocol for Internet Protocol version 6
   (IPv6).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipngwg-icmp-v3-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 4 Jun 2004 11:58:34 +0300 (EEST)

> 	Filename	: draft-ietf-ipngwg-icmp-v3-04.txt

I must object to the current IANA considerations section 6.1 on 
type/code assignment.

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.

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
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.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Bob Hinden <[email-masked]>
Date: Fri, 04 Jun 2004 14:43:34 -0700

Pekka,

>I must object to the current IANA considerations section 6.1 on

Thanks for the feedback.

>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.

>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.

>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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Jun 2004 12:27:15 +0300 (EEST)

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

> 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 [email-masked] 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.
 
> >monitoring the assignment of type values and reporting back when
> >they exceed a threshold.  One could argue that IANA is too burdened
> >as it
> 

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.