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 PROTECTED]> To: <ipv6@ietf.org> Sent: Friday, April 01, 2005 3:13 PM Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 > 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 PROTECTED] > > > JINMEI Tatuya wrote on 03/31/2005 09:49:36 PM: > > > >>>>> On Thu, 31 Mar 2005 06:13:37 -0700, > > >>>>> Kristine Adamson <[EMAIL PROTECTED]> 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 PROTECTED] > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- -------------------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
