Re: draft-ietf-v6ops-6to4-to-historic (yet again)

Ron,

The normal typography is 6to4, not 6-to-4. I assume the draft will
still refer to [I-D.ietf-v6ops-6to4-advisory]. Given that, I believe
the draft should proceed.

I definitely disagree with those who say this would be a misuse of
"Historic"; the words in RFC 2026 certainly cover this case
("for any other reason considered to be obsolete").

Regards
   Brian Carpenter

On 2011-07-27 01:47, Ronald Bonica wrote:
> Brian,
> 
> Does the following text work for you?
> 
>                          Ron
> 
> 
> N. Meaning of HISTORIC
> 
> For the purposes of this document, the term HISTORIC means:
> 
> - 6-to-4 should not be configured by default on any implementation (host, cpe router, other)
> 
> - Vendors will decide which future versions of their products will support 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) they are no longer economically incented to do so and b) they are economically incented to remove unused features from their products.
> 
> - Operators will decide when to decommission 6-to-4 relays, if ever. It is assumed that operators will continue to operate 6-to-4 relays as long as they are economically incented to do so. When 6-to-4 traffic levels reach zero, operators will probably begin to consider decommissioning.
> 
> The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time.
> 
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: Monday, July 25, 2011 11:09 PM
>> To: Ronald Bonica
>> Cc: ietf@ietf.org
>> Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
>>
>> To be clear, I'd like to see exact proposed text before expressing
>> support for the proposal. The trick is to get 6to4 disabled by default
>> at the user end, without disabling it for users who are getting good
>> service from it.
>>
>> Regards
>>    Brian
>>
>> On 2011-07-26 09:49, Brian E Carpenter wrote:
>>>>  Likewise, operators will decide whether/when 6-to-4 relays will be
>> removed from their networks.
>>> This is, of course, an undeniable statement of fact (as it is for any
>> other feature
>>> of the Internet). However, it needs to be made clear that doing so
>> *prematurely*
>>> would penalise existing successful users of those relays, and
>> therefore it should
>>> only be done when there is no successful traffic through them. Which
>> is when any
>>> operator would remove them anyway.
>>>
>>> Therefore, I don't see much value in this statement, and possible
>> harm to users.
>>> The ways to avoid such harm as far as possible are already in the RFC
>> Editor
>>> queue.
>>>
>>> Regards
>>>    Brian Carpenter
>>>
>>> On 2011-07-26 02:30, Ronald Bonica wrote:
>>>> Folks,
>>>>
>>>> After some discussion, the IESG is attempting to determine whether
>> there is IETF consensus to do the following:
>>>> - add a new section to draft-ietf-v6ops-6to4-to-historic
>>>> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
>>>>
>>>> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068
>> and convert their status to HISTORIC. It will also contain a new
>> section describing what it means for RFCs 3056 and 3068 to be
>> classified as HISTORIC. The new section will say that:
>>>> - 6-to-4 should not be configured by default on any implementation
>> (hosts, cpe routers, other)
>>>> - vendors will decide whether/when 6-to-4 will be removed from
>> implementations. Likewise, operators will decide whether/when 6-to-4
>> relays will be removed from their networks. The status of RFCs 3056 and
>> 3068 should not be interpreted as a recommendation to remove 6-to-4 at
>> any particular time.
>>>>
>>>> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it
>> clarifies the meaning of "HISTORIC" in this particular case, it does
>> not set a precedent for any future case.
>>>> Please post your views on this course of action by August 8, 2011.
>>>>
>>>>
>>>>
>> Ron Bonica
>> <speaking as OPS Area AD>
>>>> _______________________________________________
>>>> Ietf mailing list
>>>> Ietf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ietf
>>>>