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
