Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542

From: Kristine Adamson <[email-masked]>
Date: Fri, 1 Apr 2005 06:13:22 -0700

Thanks for the responses.  But if RFC3542 is not updated, won't this 
adversely affect the portability of applications that references these new 
codes?  If implementers define their own constant names for these codes in 
their icmp6.h files, then you may not be able to compile the source of the 
same application on different platforms.  Thanks,

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Internet e-mail:[email-masked]

JINMEI Tatuya wrote on 03/31/2005 09:49:36 PM:

> >>>>> On Thu, 31 Mar 2005 06:13:37 -0700,
> >>>>> Kristine Adamson <[email-masked]> said:

> >    Draft draft-ietf-ipngwg-icmp-v3-06.txt adds 3 new ICMPv6 codes to 
the
> > Destination Unreachable type.  RFC3542, Advanced Sockets Application
> > Program Interface (API) for IPv6, provides the programming definitions 
for
> > the ICMPv6 types/codes.  RFC3542 already defines one of the new codes:
> > #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source 
address
> > */

> > Will RFC3542 be updated to include the definitions for the additional 
2
> > new codes:
> > 5 - source address failed ingress/egress policy
> > 6 - reject route to destination

> Perhaps yes, although I think introducing just two new ICMPv6 types
> doesn't require a revision of RFC3542.  Someday, when we have enough
> possible updates for the API, a new version will include the new
> ICMPv6 types.

> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [email-masked]
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 04 Apr 2005 11:52:43 +0900

>>>>> On Fri, 1 Apr 2005 06:13:22 -0700, 

> codes?

Yes, it will.  However, the point is whether the portability issue is
serious enough to require a revision of RFC3542.  Different people may
have different opinions on this, and I personally don't think it's big
enough.

As someone else in this thread pointed out, this type of issue can
always happen when the IETF standardizes any new ICMP types/codes,
extension header identifier (the number of the "next header" field"),
whatever.  Clearly, we cannot update the API specification every time
we see this type of event, so we need to make a consensus on how
serious the related portability issue is.  If others agree on the
severity, I won't oppose to the conclusion.

					JINMEI, Tatuya

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 4 Apr 2005 14:46:21 +0200

Another way to define name-number mappings is as enumerations in a MIB module,
which can be placed under IANA control and be updated by whatever action seems
appropriate, as is defined in the RFC that first creates it.  (Other IANA
registrations tend to
record the number without giving a specific name to go with it). The ICMPv6 MIB,
RFC 2466, does not define such mappings.

Thinking laterally, IANA could also be a registry for the kind of HLL
name-number mappings which appear in RFC3542.

Tom Petch

----- Original Message -----
From: "Kristine Adamson" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 01, 2005 3:13 PM
Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542

> > [email-masked]

--------------------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Mon, 4 Apr 2005 17:58:44 +0300 (EEST)

> severity, I won't oppose to the conclusion.

The new values could also be defined at the appendix of icmp-v3, but 
then we'd have to agree on the proper names now, and there could be 
confusion between the revision of the advanced api and icmp-v3...

-- 
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: Thomas Narten <[email-masked]>
Date: Tue, 05 Apr 2005 21:04:11 -0400

> have different opinions on this, and I personally don't think it's big

Suggestion:

1) Set up an issue tracker for this (and perhaps every IPv6 RFC for
   which there are some known errors/omissions?) that keeps track of
   these sorts of things. That way folk will be able to more easily
   find the list of outstanding issues (and their likely resolution),
   and we (the IETF community) won't lose track of them.

2) Although it may be overkill in this case, one could easily publish
   a (very!) short RFC just listing the additional code points, so
   that they are documened in the RFC series, and folk looking at the
   older RFC can find the new RFC via the "updated by" tag.

Thomas

---

From: Kristine Adamson <[email-masked]>
Date: Fri, 8 Apr 2005 07:24:25 -0600

> older RFC can find the new RFC via the "updated by" tag.

Besides adding the programming names of the new ICMPv6 code points to 
RFC3542, the following documents an old, minor problem with RFC3542, that 
was listed in the errata.  This problem could also be resolved with a new, 
short RFC that updates RFC3542.  Since there are 2 problems that could be 
resolved with a new RFC, do we now have sufficient reasons to publish a 
new RFC?  Thanks!

>>>>>> On Sun, 30 Nov 2003 15:58:17 +0200 (EET), 
>>>>>> Pekka Savola <[email-masked]> said:

>>> And, in fact, the current implementation of the KAME project uses
>>> uint8_t for the align parameter.
>>> 
>>> I don't know how to correct this one, though.  Obviously, we cannot
>>> revise the document again just due to this problem.

>> Well, one could at least report it to:

>> http://www.rfc-editor.org/cgi-bin/errata.pl (link form the main page)

>Just FYI: I've reported this issue, and the errata page has just
>included the correction.

>> .. but most folks probably don't check that when reading the 
>> specs..

>I tend to agree...

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Phone: (919) 254-7911   T/L 444-7911
Internet e-mail:[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 21 Apr 2005 23:53:05 +0900

>>>>> On Fri, 8 Apr 2005 07:24:25 -0600, 

> resolved with a new RFC, do we now have sufficient reasons to publish a 

Opinions may vary, but I personally still do *not* think the
followings are enough for even a "very short RFC":
  - the minor correction recorded at the RFC errata page
  - macro names for the two new ICMPv6 codes

I personally think it makes more sense to file the issues at an issue
tracker (suggestion 1 from Thomas).  With future possible
issues/corrections/additions in that page, we'll probably reach the
point where most of us can agree on the need for an updating RFC.

					JINMEI, Tatuya