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
Manfredi, Albert E wrote:
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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
