Brian, if I have this right, you're talking about two possibilities here: 1. Release the NSAPA destination option code, and have IANA mark it as "reserved," or
2. Do nothing, which retains the NSAPA designation for that option code 0xC3. Is there any practical value to changing the designation from NSAPA to "reserved"? If one takes work and the other does not, I'm not sure why bother. In the future, can a request be made to the IANA to reassign that 0xC3 option code to some new use, citing RFC 4048 as a reason why this is okay to do? Bert > -----Original Message----- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 27, 2005 4:56 AM > To: Templin, Fred L > Cc: IPv6; Bob Hinden > Subject: Re: NSAP Address IPv6 option > > I haven't seen any more discussion on this. > > It makes perfect sense to post errata, and as document > editor I can do that, but we also need to send a request to > IANA, as Bob suggested, and that presumably needs WG > consensus to be declared, which is outside my scope. > > Brian > > Templin, Fred L wrote: > > Why not just post this as errata to RFC4048? > > > > Fred > > > > -----Original Message----- > > From: Bob Hinden [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 11, 2005 10:18 AM > > To: Brian E Carpenter > > Cc: IPv6 > > Subject: Re: NSAP Address IPv6 option > > > > Brian, > > > > At 07:04 AM 07/11/2005, Brian E Carpenter wrote: > > > >>RFC 1888 defined a destination option called "NSAP Address" > >>with option type code 11-0-00011 = 195 decimal, C3 hexadecimal. > >> > >>Unfortunately, the IANA Considerations in RFC 4048 > >>faild to discuss this option. It is still listed at > >>http://www.iana.org/assignments/ipv6-parameters > >> > >>My opinion is that it can be released; I'm aware of no usage. > >> > >>Any objections? Can the WG Chairs suggest a procedure to avoid > >>the overhead of another trivial RFC? > > > > > > The chairs could send an email to the IANA (with cc's to > the IPv6 list > > and > > IESG) with something to the effect that since RFC4048 made RFC1888 > > historic, the destination option defined by RFC1888 is no > longer needed > > and > > should be marked as Reserved. This was the intention of > RFC4048, but > > was > > omitted in error. > > > > The only downside of this approach I can think of is that > there wouldn't > > be > > an RFC documenting the change. I am not sure this is a big deal in > > this case. > > > > Other opinions and/or suggestions? > > > > Bob > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
