Personally, I think Experimental status matches what we are hearing
from the IETF community. There are a fairly large number of people
who want to have a stable reference for the algorithm used by NPT6, so
they can write interoperable versions to meet current needs and
experiment with long term impacts of this mechanism. Meanwhile, there
are people who do not want to see the IETF advocate the use of this
technology -- the vast majority of these people understand that
something like this will be used, but they don't want the IETF to go
as far as recommending it.
Experimental does exactly that: it provides a stable RFC to define
the algorithm, however it does not produce a Standards-Track IETF RFC,
which would indicate that this technology is recommended for
operational use by the IETF.
Margaret
On Feb 1, 2011, at 2:10 AM, Fred Baker wrote:
On Feb 1, 2011, at 5:25 AM, Arifumi Matsumoto wrote:
Hi all,
I realized -07 was published yesterday, and the intended status was
changed to Experimental. Have we discussed about it here or
anywhere else ?
I'm not against this change, but I just want to see what happened
on this.
In short form, I talked about it with Ron Bonica, who agreed to
carry it through the IESG as an individual submission. We talked
about standards track vs informational vs experimental status. In
short, the IESG can put any document to whatever status they want,
but depending on status the bar is higher or lower and the process
varies a bit. Experimental has the lowest bar; Ron and I thought it
might make the process in the IETF (which has already been highly
contentious) easiest.
Like you, I'm not particularly concerned with the status. We have
any number of instances where technology has been published as
experimental or informational and later moved to the standards
track. However, if there is a strong opinion on this list, I (and I
think Ron) can also be convinced to change it.
http://bit.ly/h4q9wl
On 2011/01/05, at 19:28, Fred Baker wrote:
Posted a new version this evening, with updates from Merike Kaeo
in the Security Considerations section.
http://tinyurl.com/2f2mdre
On Jan 4, 2011, at 10:12 PM, IETF I-D Submission Tool wrote:
A new version of I-D, draft-mrw-nat66-06.txt has been
successfully submitted by Fred Baker and posted to the IETF
repository.
Filename: draft-mrw-nat66
Revision: 06
Title: IPv6-to-IPv6 Network Prefix Translation
Creation_date: 2011-01-04
WG ID: Independent Submission
Number_of_pages: 31
Abstract:
This document describes a stateless, transport-agnostic IPv6-to-
IPv6
Network Prefix Translation (NPTv6) function that provides the
address
independence benefit associated with IPv4-to-IPv4 NAT (NAT44),
and in
addition provides a 1:1 relationship between addresses in the
"inside" and "outside" prefixes, preserving end to end reachability
at the network layer.
Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this
document are to be interpreted as described in RFC 2119 [RFC2119].
The IETF Secretariat.
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
--
Arifumi Matsumoto
NGN System Architecture Project
NTT Service Integration Laboratories
E-mail: [email protected]
TEL +81-422-59-3334 FAX +81-422-59-6364
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
