I get the point. Thank you for your quick response. I really appreciate your generous contribution on this item.
On 2011/02/01, at 16:10, 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 >> > > -- 松本 存史 <[email protected]> NTTサービスインテグレーション基盤研究所 次世代ネットワーク方式SEプロジェクト TEL 0422-59-3334 FAX 0422-59-6364 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
