Subject: RE: NSAP Address IPv6 option

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 27 Jul 2005 11:03:38 -0400

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-masked]] 
> 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-masked]] 
> > 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-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
> --------------------------------------------------------------------
> 
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jul 2005 09:15:01 +0200

Bert,

Over in another part of the universe, there's been quite a
discussion about the prudence required in the management
of limited namespaces, including IP options. As a result, I
don't want to leave what is basically garbage in the IANA
registry. So here is where I am at now, after the
discussion here:

1. I will, right now, send an erratum note to the RFC Editor
to correct the omission in RFC 4048.

2. I request the WG Chairs to make a consensus call on this
proposal:

The WG agrees to request the IANA to mark IPv6
option type code 11-0-00011 = 195 decimal, C3 hexadecimal
as available for assignment.

Rationale: it's clear that this part of RFC 1888 was never
implemented by anybody, and we should not tie up a
namespace resource as a result.

    Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 28 Jul 2005 07:19:18 -0400

> as available for assignment.

Since no one has objected to this, the chairs will proceed with
drafting an e-mail to IANA asking them to free this codepoint.

Regards,
Brian