I'm having a hard time thinking of adequate alternatives terms (but
this purely a personal failing, I'm sure). Recommendations for other
words?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
The youtube folks made the decision to leave the video-serving
hostnames available in blacklist-mode, meaning only very broken
networks won't get s.
This is being watched, and could easily change back. The exact policy
for blacklisting has yet to be fully formalized.
But re: 6to4 in this cas
All,
> Perhaps declaring 6to4 deprecated rather than historic would have a
> better chance of consensus.
Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?
This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
"""
A spe
>> > Perhaps declaring 6to4 deprecated rather than historic would have a
>> > better chance of consensus.
>>
>> Pardon my ignorance, but where is the document describing the
>> implications of historic{,al} vs deprecated?
>>
>> This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
> Given that each of us reads something different into the definition of
> HISTORIC, is there any hope that this thread will ever converge?
I don't see any "progress".
We may just have to blacklist any resolvers that have 6to4 clients
behind them and leave it at that.
___
Moving 6to4 to historic does not in any way impact your ability to use
it as you wish.
6to4 support is not part of the IPv6 node requirements, as I
understand it. Therefore I believe that any vendor (OS, router,
otherwise) could deleted 6to4 support in any release and be in
violation of anything,
World IPv6 Launch changes the relevance of this document greatly, I
think. Since this would be published after the announcement of World
IPv6 Launch, I think the document should be updated to discuss its own
applicability in a post- World IPv6 Launch Internet.
On 2 February 2012 00:09, The IESG
On 4 February 2012 01:35, Fred Baker wrote:
>
> On Feb 2, 2012, at 6:57 PM, Erik Kline wrote:
>
>> World IPv6 Launch changes the relevance of this document greatly, I
>> think. Since this would be published after the announcement of World
>> IPv6 Launch, I think the do
REQ 1:
6434 5.9.1 is already a MUST. This does not need to be repeated.
6434 5.8 is already a MUST. Unless you want to make multipart
ICMP a MUST (why?) as well, this too can be removed.
REQ 6:
re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUST
frankly even 5
