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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ronald Bonica <rbonica@xxxxxxxxxxx> wrote:
> 
> 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

   Clearly, this is an honest effort to make 6to4-to-historic closer to
where you think a consensus might be. I do appreciate the attempt...

   ... but it feels like wandering in the weeds. :^(

   We are suffering from many differing views of what "IETF consensus"
is. IMHO, any useful definition includes that anyone who disagrees with
the "consensus" statement agrees to shut up. They may shut up almost
immediately; they may shut up after some painful appeals process; or
worst, they may only pretend to shut up and keep bringing the issue
to mind again. This last, IMHO, doesn't deserve the name "consensus".

> 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.

   That's a funny definition of "historic"...
> 
> 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.

   This _is_ reminiscent of what courts do when faced with a bad law.
But courts _don't_ have the option to not enact the law in the first
place. It _is_ for them the least-worst option.

> Please post your views on this course of action by August 8, 2011.

   Speaking for myself, this proposal accomplishes nothing useful.

   I actually have no particularly strong opinion on whether RFCs
3056 and 3068 deserve to be labeled "historic" at this time. I expect
they will deserve that label within a few years; but the label feels
"optimistic" at this time.

   What I _do_ have a strong opinion on is claiming in a published
RFC that we have IETF consensus to re-classify them. I do not believe
we have such consensus. I do not believe the IESG has followed a process
reasonably aimed at judging such consensus. I don't believe the IESG
even has consensus among themselves -- though if that were what the
boilerplate would claim, I wouldn't interfere.

   At some point, we need to be willing to say, "there is no consensus
at this time," and move on.

   I absolutely do not believe that reclassifying the two RFCs as
"historic" will accomplish what the proponents claim. (Neither do I
believe it would cause world-shattering harm.)

   As a general rule, I think reclassification of _anything_ to
"historic" shouldn't gate on IETF consensus -- it's just too hard.
Instead, I'd recommend some group like the IAB make the call, with
no claim to represent "consensus" of a body so large as the IETF.

   I am probably willing to shut up in any case; but I'd be a whole
lot happier if re-classification were an IAB decision. Barring that,
perhaps the RFC calling for re-classification could follow some path
which doesn't require boilerplate which claims to represent "IETF
Consensus"

   Or, the IESG could just let this document die.

--
John Leslie <john@xxxxxxx>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]