Re: [nat66] -07 intends experimental status Re: New Version Notification for draft-mrw-nat66-06

[Margaret Wasserman <[e-mail]>]

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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nat66
>>
>>
>> --
>> Arifumi Matsumoto
>> NGN System Architecture Project
>> NTT Service Integration Laboratories
>> E-mail: [e-mail]
>> TEL [phone] FAX [phone]
>>
>
> _______________________________________________
> nat66 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nat66