Subject: Why ask for IETF Consensus on a WG document?

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Jun 2011 15:36:08 -0700

Greetings again. The subject line is an honest question, not a gripe.

For those on the ietf@ mailing list, please see <https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ballot/>. In short, the IESG just approved publication of draft-ietf-v6ops-6to4-to-historic, even with what appears to be a lack of consensus in the comments on the ietf@ mailing list. One AD called it "pretty rough", but my quick count shows that it was not rough at all: there were more people on the ietf@ against this than in favor of it. If the consensus in a WG for a document was the same as we saw on ietf@ for this document, and the WG chair declared consensus anyway, there would be some serious talks with that WG AD about the chairs.

For a document such as this, why even ask for IETF consensus if the IETF consensus doesn't matter? There was a lot of good discussion and a fair number of varied objections to approval of the document. It sounds like the WG was strongly in favor of the document, which may be sufficient motivation to publish it, but the intermediate step of asking for IETF consensus and then not paying attention to the result then seems wasteful of IETF time.

If the IESG has a policy that "WG consensus trumps IETF consensus", that's fine, but it should be a stated policy so we know where to spend our time. If this document is special for some reason (for example, because it was about policy instead of being a protocol) and therefore the IESG measures consensus differently, that too is fine if we all know that ahead of time. Even a policy of "more than a dozen IETF regulars must object on ietf@ before we will consider overturning a WG" is fine, as long as it is a stated policy. If the IESG has a policy that says "the way we count in IETF Last Call is different than the way we expect Working Group chairs to count in WG Last call", that's fine as well. None of that is obvious from the ballot comments that are visible to the community, however.

Guidance from the IESG for our future participation in IETF Last Call discussions would be greatly appreciated. We try to save you folks time and effort; such guidance would return the favor to us.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Jun 2011 18:44:40 -0600

On 6/23/11 4:36 PM, Paul Hoffman wrote:
> For those on the ietf@ mailing list, please see
> <https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ballot/>.
> In short, the IESG just approved publication of
> draft-ietf-v6ops-6to4-to-historic, even with what appears to be a
> lack of consensus in the comments on the ietf@ mailing list. One AD
> called it "pretty rough", but my quick count shows that it was not
> rough at all: there were more people on the ietf@ against this than
> in favor of it.

I can't speak for other IESG members, but I made a point of reading the
full text of every IETF LC message about this I-D, and I disagree with
the accuracy of your quick count. It's true that the Last Call did not
achieve unanimity or even smooth consensus, but my reading was that a
few folks were in the rough (although quite vocal) and that there was
rough consensus to publish. I would not have ballotted "No Objection"
otherwise. However, I freely admit that I might be wrong.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Melinda Shore <[email-masked]>
Date: Thu, 23 Jun 2011 16:58:21 -0800

On 06/23/2011 04:44 PM, Peter Saint-Andre wrote:
 > [ ... ] but my reading was that a

I don't think anybody has a particularly rigorous working
definition of "rough consensus" and it leaves the door open
for this sort of disagreement.

I also think that institutional navel-gazing around this stuff has
repeatedly proven to be fruitless and that maybe people who are
calling consensus should probably talk amongst themselves about
what they mean by "consensus" and how it differs from voting.

Melinda

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Jun 2011 18:15:12 -0700

> otherwise. However, I freely admit that I might be wrong.

And this goes back to my question of how the IESG wants to deal with consensus calls on ietf@. You say "a few folks", but my count says that there were six people who actively said "do not publish", and a few more who hinted at it. On the positive side, there were about five from the WG who said "publish" and a couple who said "let's just move on".

I do not put the latter into the "positive" category, but you might. However, in general, I have heard ADs tell WG chairs *not* to consider "I'm tired of this, publish this and move on" as useful input to the WG consensus process. Is it more useful in the IETF consensus process? Given that a WG has already worked hard on a document, I can see where such sentiment on ietf@ would be considered positive, but it would be good to hear that explicitly.

Said a different way, what needs to happen in IETF Last Call to overcome "we already discussed this in the WG" (which was the majority of the positive comments in this case)? Does a non-WG member need to do more, and if so what? 

--Paul Hoffman

P.S. As someone noted offline, I did not voice my opinion on this document in IETF Last Call. That's correct: I didn't (and don't) care that much about the outcome either way. I do care about knowing how IETF consensus is judged, however.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jun 2011 13:34:33 +1200

> otherwise. However, I freely admit that I might be wrong.

I think that's about right. There were several strong and very raional
opinions against this, including some who were not involved in the similarly
rough consensus in the WG discussion. But (speaking as a co-author of one of
the drafts being historicised) I'd say the balance of opinion was to publish.
However, it's a close call.

    Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Jun 2011 19:38:07 -0600

> what they mean by "consensus" and how it differs from voting.

Omphaloskepsis aside, I've been thinking about writing an I-D on the
meaning of consensus, although I somehow doubt we'd be able to get
consensus on the topic...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "t.petch" <[email-masked]>
Date: Fri, 24 Jun 2011 10:35:41 +0200

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: "IETF-Discussion list" <[email-masked]>
Sent: Friday, June 24, 2011 12:36 AM
> For those on the ietf@ mailing list, please see
<https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ballot/>. In
short, the IESG just approved publication of draft-ietf-v6ops-6to4-to-historic,
even with what appears to be a lack of consensus in the comments on the ietf@
mailing list. One AD called it "pretty rough", but my quick count shows that it
was not rough at all: there were more people on the ietf@ against this than in
favor of it. If the consensus in a WG for a document was the same as we saw on
ietf@ for this document, and the WG chair declared consensus anyway, there would
be some serious talks with that WG AD about the chairs.
>
> For a document such as this, why even ask for IETF consensus if the IETF
consensus doesn't matter? There was a lot of good discussion and a fair number
of varied objections to approval of the document. It sounds like the WG was
strongly in favor of the document, which may be sufficient motivation to publish
it, but the intermediate step of asking for IETF consensus and then not paying
attention to the result then seems wasteful of IETF time.
>
> If the IESG has a policy that "WG consensus trumps IETF consensus", that's
fine, but it should be a stated policy so we know where to spend our time.

I have always seen that as part of our procedures. The IETF Last Call is mostly
about objections, about problems missed, about unforeseen interactions with
other work.  Most of those who spoke up in support of a WG Last Call do not go
on to support the IETF Last Call, while those who object most strenuously in a
WG Last Call tend to repeat their objections at an IETF Last Call, so I have
always taken as axiomatic that the IESG would factor in all the support
expressed in a WG Last Call into the judgement of consensus on an IETF Last
Call, as opposed to a mere count of e-mails to the IETF list during the IETF
Last Call.

The I-D in question seems to fit this pattern perfectly.

Tom Petch

If this document is special for some reason (for example, because it was about
policy instead of being a protocol) and therefore the IESG measures consensus
differently, that too is fine if we all know that ahead of time. Even a policy
of "more than a dozen IETF regulars must object on ietf@ before we will consider
overturning a WG" is fine, as long as it is a stated policy. If the IESG has a
policy that says "the way we count in IETF Last Call is different than the way
we expect Working Group chairs to count in WG Last call", that's fine as well.
None of that is obvious from the ballot comments that are visible to the
community, however.
>
> Guidance from the IESG for our future participation in IETF Last Call
discussions would be greatly appreciated. We try to save you folks time and
effort; such guidance would return the favor to us.
>
> --Paul Hoffman
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Jun 2011 10:40:16 +0100

Basically, I approached this the way Peter did. One further
point below though.

> Said a different way, what needs to happen in IETF Last Call to overcome "we already discussed this in the WG" (which was the majority of the positive comments in this case)? Does a non-WG member n…

In addition to the other factors already mentioned, I didn't
see what I thought were significant new facts or issues being
raised at the IETF LC. I think that such things are perhaps
more likely to cause the IETF rough consensus to differ from
that in the WG. In this case, it looked to me like people
were bringing concerns already expressed in the WG to the
attention of the wider community, which is a reasonable thing
to do in cases like this where the WG consensus was already
fairly rough.

It could well be that I know so little about 6to4 that I was
wrong in that conclusion of course, but then there's so much
about which I know so little that I've gotten used to living
with that risk;-)

S.

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 07:35:32 -0400

On Jun 23, 2011, at 8:44 PM, Peter Saint-Andre wrote:

> rough consensus to publish. 

I often get the impression that dissenters are dismissed as "in the rough" and that their opinions, no matter how well expressed, are given less weight than those who are in favor.

It was clear to me that there was nowhere nearly consensus on this action, not even "rough consensus", and it was completely inappropriate of IESG to approve it.  

Rough consensus does not mean you can disregard the opinions of those whom you disagree with.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 07:47:33 -0400

> about which I know so little that I've gotten used to living

It's problematic, and I believe inappropriate, to consider WG consensus as contributing to community consensus.  The two questions need to be considered separately, for two reasons:

1. Working groups often have strong biases and aren't representative of the whole community.  Put another way, a working group often represents only one side of a tussle, and working groups are often deliberately chartered in such a way as to minimize the potential for conflict within the group.   So when evaluating standards actions for the whole community, the consensus within a working group means little.   In this particular case, v6ops heavily represents the interests of operators (who are naturally interested in having IPv6 run smoothly in the long term) and works against the interests of applications developers (who are naturally interested in having transition mechanisms that allow them to ship code that uses IPv6 and an IPv6 programming model regardless of whether the underlying network supports it).

2. Working groups have spent a lot of time working on a document and will have several members actively participating.  By contrast, most of the wider community will not have these issues "on their radar" until they come up for IETF-wide Last Call.   Also, busy people need to find time to review a document before making comments, and this may require multiple readings.  So it's hardly surprising if the number of IETF-wide Last Call comments is smaller than the number of WG Last Call comments.   Consensus needs to be evaluated separately in the WG and the IETF because the populations and sample sizes are different.

Keith

---

From: Yang C Sijes <[email-masked]>
Date: Fri, 24 Jun 2011 20:17:37 +0800

On 2011-6-24 6:36, Paul Hoffman wrote:
> For those on the ietf@ mailing list, please see<https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ballot/>. In short, the IESG just approved publication of draft-ietf-v6ops-6to4-to-historic, even with what appears to be a lack of consensus in the comments on the ietf@ mailing list. One AD called it "pretty rough", but my quick count shows that it was not rough at all: there were more people on the ietf@ against this than in favor of it. If the consensus in a WG for a document was the same as we saw on ietf@ for this document, and the WG chair declared consensus anyway, there would be some serious talks with that WG AD about the chairs.
>
I maybe wrong but I mean no offensive.
IMO, the "consensus" is not only a matter of numbers.
For example, it's quite OK to move on if we got 6 against 4 by voting. But it's not good if we want
"consensus". Even there's only one individual who is against the draft, His(or her) opinion should
be considered carefully enough, as long as his(or her) suggestion matters.
But it's AD's job to decide whether the suggestion matters or not. If AD thinks that the problem does
not worth another discussion or the draft is OK with these flaws, then we move on. In this case, AD
do(and should) have this power.

--Yang C Sijes

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jun 2011 00:34:19 +1200

Keith,

On 2011-06-24 23:47, Keith Moore wrote:
...
> 1. Working groups often have strong biases and aren't representative of the whole community.  Put another way, a working group often represents only one side of a tussle, and working groups are oft…

I suspect that operators are *severely* under-represented on this
list ([email-masked]) because it is very noisy and operators have other
priorities. Most of them are probably unaware of this discussion,
in fact.

   Brian

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Jun 2011 08:41:41 -0400

On Thursday, June 23, 2011 09:34:33 PM Brian E Carpenter wrote:
> >> <https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ball
> >> ot/>. In short, the IESG just approved publication of
> opinions against this, including some who were not involved in the
> similarly rough consensus in the WG discussion. But (speaking as a
> co-author of one of the drafts being historicised) I'd say the balance of
> opinion was to publish. However, it's a close call.

I'm relatively new to IETF procedure, so I may misunderstand, but that sounds 
a lot more like voting than any kind of consensus, rough or otherwise.

Scott K

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Jun 2011 08:55:22 -0400

(Wearing my Narrative-Scribe hat)

   First, note the Subject line: an IETF Last-Call on a Working Group
document _isn't_ asking for IETF Consensus: it's simply a last-call for
comments on an action proposed by a Working Group.

   Second, I think the Narrative Minutes will help considerably in
understanding this situation. They will likely be published July 5 or 6.

Keith Moore <[email-masked]> wrote:
> 
> It's problematic, and I believe inappropriate, to consider WG consensus
> as contributing to community consensus.

   I agree -- however, this was not a call for community consensus.

   (Possibly it should have been. At the same IESG telechat, there was
a Statement on moving an RFC to Historic Status, which perhaps should
cover cases like this.)

> The two questions need to be considered separately, for two reasons:
> 
> 1. Working groups often have strong biases and aren't representative
> of the whole community. Put another way, a working group often
> represents only one side of a tussle, and working groups are often
> deliberately chartered in such a way as to minimize the potential
> for conflict within the group.

   Nonetheless, WGs are open to all.

   When a WG document comes before the IESG, there are several Directorate
reviews and an IETF-wide Last-Call. These exist to give guidance to the
IESG on whether to send the document back to the WG with comments on
how to improve it. If it is sent back, the WG must deal with anyone who
may join that WG to express opinions on those comments.

   IESG members dislike sending documents back to the WG, because it is
perceived (by WG members) as "micro-management" or whatever nasty term
may come to mind. Generally, IESG members choose to avoid this when they
don't believe the WG consensus will change.

> So when evaluating standards actions for the whole community, the
> consensus within a working group means little.

   I don't agree. The WG is where concerns are supposed to be balanced.
The <[email-masked]> list cannot handle the bandwidth of doing this.

> In this particular case, v6ops heavily represents the interests of
> operators (who are naturally interested in having IPv6 run smoothly
> in the long term) and works against the interests of applications
> developers (who are naturally interested in having transition
> mechanisms that allow them to ship code that uses IPv6 and an
> IPv6 programming model regardless of whether the underlying network
> supports it).

   True.

> 2. Working groups have spent a lot of time working on a document and
> will have several members actively participating. By contrast, most
> of the wider community will not have these issues "on their radar"
> until they come up for IETF-wide Last Call. Also, busy people need
> to find time to review a document before making comments, and this
> may require multiple readings.

   True.

> So it's hardly surprising if the number of IETF-wide Last Call
> comments is smaller than the number of WG Last Call comments.
> Consensus needs to be evaluated separately in the WG and the IETF
> because the populations and sample sizes are different.

   I'm not sure I agree that IETF-wide consensus needs to be evaluated
at all.

   The model of IETF is that work is normally done in WGs, and that
an IETF-wide review is done before publishing an RFC.

   In this particular case, we have an Informational-status RFC
intended to declare a Standards-Track RFC to no longer be an Internet
Standard in any sense. It is arguable that such an action _should_
require IETF-wide consensus; but at the moment there is no procedure
requiring it.

   So, Keith, you must first convince us that an action like this
_does_ require IETF-wide consensus.

--
John Leslie <[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 09:42:00 -0400

> priorities. Most of them are probably unaware of this discussion,

You're probably right about the representation of operators on the ietf list.  But our process requires that we get consensus here in addition to in the working group.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 10:07:14 -0400

> a Statement on moving an RFC to Historic Status, which perhaps should

Well, there was also a process issue because a standards action (changing 6to4 to historic) was advertised as a proposal to publish an informational document.  

But I read 2026 as requiring broad community consensus for standards actions.

> don't believe the WG consensus will change.

I served on IESG for four years, and understand all of that.  Nevertheless, even a strong consensus of a WG should never be taken as consensus of the IETF as a whole.    Working groups are almost inevitably narrowly focused, and in practice they rarely consider the wider effects of their actions.

And in this particular case, I don't think there was even rough consensus within the v6ops working group.

Moreover, while it is always necessary to get rough consensus from the broad community on any standards action, WG consensus is not a necessary condition.   Individual submissions for standards-track can be approved with a 4-week Last Call.   The value of a narrowly-focused working group is not so much to gain consensus of that group (though this can be useful), but to encourage an appropriate amount of attention on protocol design.  Clearly the broad community consensus is more important than the working group's consensus.   A working group should understand that its job is to put forth a proposal that will win consensus of the broad community.

> The <[email-masked]> list cannot handle the bandwidth of doing this.

Working groups that are narrowly focused (which is to say the vast majority of them) cannot possibly balance the competing concerns of the broad community.    They are too subject to the dictates of a single "area".  And schedule conflicts at IETF meetings also discourage cross-area participation.

>   I'm not sure I agree that IETF-wide consensus needs to be evaluated

RFC 2026 states over and over again, in several different ways, that the goal of the process is to achieve broad community consensus.

Keith

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Jun 2011 07:17:10 -0700

> to do in cases like this where the WG consensus was already

My (possibly-flawed) reading of the responses was that none of the people objecting to the publication of this document during IETF LC were WG participants. So, while they might have brought up points already considered by the WG, they were not bringing up ones that they had already expressed.

Is it then your (individual) opinion that issues that were raised in a WG but determined to not be strong enough to affect WG rough consensus should be ignored when determining IETF rough consensus? That's a reasonable opinion, but not one I had heard before. At least, it helps answer the question of what a WG non-participant needs to do to cause a WG document to not pass IETF consensus.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Jun 2011 07:23:18 -0700

> comments on an action proposed by a Working Group.

I'm quite confused by this opinion. *No* IETF Last Call announcements, even those for standards track documents, say that they are to determine IETF consensus, yet IETF consensus is required for many of these documents. In your view, how are we to know which IETF Last Call announcements are to determine IETF consensus and which are just to bring additional input to the IESG for a non-consensus decision? Or are you saying that the IESG determines IETF consensus using metrics other than the discussion on ietf@?

Again, the community knowing what type of response would be productive during IETF Last Call would help everyone set their priorities better.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Jun 2011 15:44:20 +0100

On 24/06/11 15:17, Paul Hoffman wrote:
> My (possibly-flawed) reading of the responses was that none of the people objecting to the publication of this document during IETF LC were WG participants. 

I had the opposite impression. I thought that I saw people
say a few times, "when you brought this up in the WG" type
remark as well (but I've not looked back).

> So, while they might have brought up points already considered by the
WG, they were not bringing up ones that they had already expressed.
> Is it then your (individual) opinion that issues that were raised in a WG but determined to not be strong enough to affect WG rough consensus should be ignored when determining IETF rough consensus…

No. Not "ignored," but I do think that finding out new facts
and cross-cutting considerations are an important part of
IETF LC. (And recall that I started my mail by saying that
I was just adding an additional point.)

So I don't think I've answered your question, or at best,
only partly.

S.

(And of course I'm not talking for the IESG here, just
saying what I did/think - what hat is that anyway? :-)

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 24 Jun 2011 10:46:11 -0400

An IETF consensus call is judgement as to rough consensus. There is no
mechanical set of rules that can substitute for judgement.

WG Chairs judge the consensus of the Working Group. It is reasonable
for them to take into account discussions at WG meetings as well as WG
mailing list discussions.

The IESG judges the consensus of the IETF. It is reasonable for them
to take into account discussions on the WG mailing list and on any
area mailing list or the like, as well as on the IETF mailing list and
discussions at WG, area, and IETF plenary meetings.

If polls at area meetings with 100+ people at them at three successive
IETF meetings on different continents consistently show, say, a 3 to 1
preference for some proposal but the IETF Last call email has 6 people
speaking against and only 4 in favor, what do you think the right
judgement would be as to the consensus of the IETF community? Of
course, I'm not saying that's what happened hear. But a narrow rules
that the IESG is required to put on blinders and only consider the
IETF discussion list IETF Last Call email, ignoring previous
discussions on other relevant IETF mailing lists and ignoring WG,
area, and IETF plenary meeting discussions they have attended, is just
arbitrary nonsense.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 11:21:05 -0400

> remark as well (but I've not looked back).

Looking over both WGLC and IETF LC responses just now and making a rough tally of opinions, I only saw one person who responded to both LC requests.  (But I was only counting the objections to the proposed action.)

> I was just adding an additional point.)

I don't think that people's concerns can be disregarded just because others raised similar concerns in WG discussion.  If anything, that should give more weight to those concerns.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 11:39:43 -0400

> discussions at WG, area, and IETF plenary meetings.

I think I mostly disagree with this, for reasons stated earlier.  

Now it might be that, for some specific issue or objection raised during IETF LC to some technical proposal, the IESG could look at the WG record and say "This issue was thoroughly considered by the WG.   There's really no way to solve this problem that will satisfy all concerns, and the WG did as good a job at making an appropriate compromise as could be expected."    That could be an appropriate way to respond to a dispute over a technical compromise design choice.  And in general, I think IESG should give preference to a WG's technical decisions if it's clear that the WG made an effort to understand all of the competing concerns and to strike an appropriate balance between them.

I don't think that rationale would apply in the case of 6to4-historic, as there's really no technical need to declare this historic.   And the 6to4-advisory document does a much better job at both recommending remedies to the problems that people have (reasonably) complained about, and striking a balance between competing concerns.

> area, and IETF plenary meeting discussions they have attended, is just

I wouldn't agree with that kind of narrow rule either.   But when evaluating IETF-wide consensus, it doesn't make sense to just add up all of the yeas and nays in both IETF and WG last call.  

And in any case where there's not a clear consensus, part of the question should probably be "is there a compelling need for this document or action to move forward at this time?"  Sometimes I think people get the idea that they have to approve things "to get them off of their plates" so to speak, and to avoid having to iterate over the document several more times.   

Keith

p.s. My belief is that the 6to4-historic document wouldn't be nearly as divisive if either (a) it were deferred for a year or three or (b) the proponents had been willing to compromise on the status label.  When simple changes would suffice to build wide consensus, you have to wonder why there's been so much effort to push through a document for which consensus is dubious at best.

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Jun 2011 12:08:55 -0400

--On Friday, 24 June, 2011 13:34 +1200 Brian E Carpenter
<[email-masked]> wrote:

>...
> I think that's about right. There were several strong and very
> raional opinions against this, including some who were not
> involved in the similarly rough consensus in the WG
> discussion. But (speaking as a co-author of one of the drafts
> being historicised) I'd say the balance of opinion was to
> publish. However, it's a close call.

Brian,

I see another problem here that, IMO, is complementary to the
issue that Paul raises and enough independent of that issue that
one could agree that the consensus determination was reasonable
but still wrong (I don't concede the first, but want to look at
the second).

I've never assumed that the LC process is a binary one, with the
only possible answers being "approve as written" or "complete
trash".  It is a call for comments, not an approval vote.   The
IESG clearly recognizes the distinction, although usually in
minor ways -- tuning of documents after IETF LC or IESG reviews
is almost certainly the norm rather than the exception and that
tuning is sometimes fairly significant.

In this case, it would not be hard to convince me that there was
pretty good IETF consensus that an unrestricted recommendation
for using 6to4 was appropriate.  Even most of 6to4's strongest
advocates seem to agree that using it in stupid and naive ways
leads to bad outcomes.  But consensus on that subject is not
consensus that moving the whole business to Historic is a good
idea.  To paraphrase at least one comment, there is danger of
throwing the baby (and perhaps some of the plumbing fixtures)
away with the bath water. 

What I saw was what appeared to me to be some fairly strong
arguments for looking at the problem in a different way -- a way
that I've seen no evidence the WG considered at all.   That
would be to explore alternatives to the rather blunt instrument
of making a protocol specification historic: explaining what
needs to be done to get it right (your document does a lot of
that) and then figuring out ways to warn against the uses and
configurations that we all (or mostly) agree are bad news.

I would like to see evidence (or even a strong assertion) that
the IESG considered options other than "adopt package and more
6to4 to Historic" and "don't".   I believe the LC discussions
call for that discussion, not boilerplate about rough consensus
around a narrow reading of the question that does not admit of
the possibility of other alternatives.

I'm not going to appeal this one, but I think that someone who
feels more strongly about it probably should.

     john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 24 Jun 2011 09:36:13 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
> Sent: Friday, June 24, 2011 4:48 AM
> To: Stephen Farrell
> Cc: IETF-Discussion list; Paul Hoffman; The IESG
> Subject: Re: Why ask for IETF Consensus on a WG document?
> 
> as contributing to community consensus.  The two questions need to be
> considered separately, for two reasons:
> 
> 1. Working groups often have strong biases and aren't representative of
> the whole community.  Put another way, a working group often represents
> only one side of a tussle, and working groups are often deliberately
> chartered in such a way as to minimize the potential for conflict
> within the group.

By contrast, working groups tend to contain more expertise than may be available in an IETF LC; that's partly why they're formed.  I've never been an AD before, but I imagine I might consider the WG consensus to be at least a little bit more weighty than IETF LC resistance.

For that matter, if you object vehemently to something a WG produces, then the work is of interest to you, and I have to wonder why you weren't at least silently tracking that working group in the first place.

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 12:54:55 -0400

> By contrast, working groups tend to contain more expertise than may be available in an IETF LC; that's partly why they're formed.  I've never been an AD before, but I imagine I might consider the W…

WGs tend to contain a narrow range of expertise, even when their work affects a wide range of concerns.   Having a narrow range of expertise is good when the WG is tasked with doing a particular kind of protocol design.  But in general I don't think an "ops" group is in a good position to make recommendations on behalf of the whole IETF about things that aren't related to operations.  If they want to say "we want to call attention to these significant operational problems with protocol X" or " we recommend these particular operational practices to help protocol X work well" I think that's fine.   I don't think it's fine for them to be trying to harm things that other people are using, at least not without some broader community input.  

> For that matter, if you object vehemently to something a WG produces, then the work is of interest to you, and I have to wonder why you weren't at least silently tracking that working group in the…

This one caught me completely by surprise.  I happened to notice, almost by accident, the discussion on the 6to4-advisory document, and was able to participate in some of that discussion.   The main result of my participation in that conversation, I think, was that I became convinced that disabling 6to4 by default really is the right thing to do... mostly because of the impending imposition of LSN.    But 6to4-historic goes way too far, and I wasn't aware of the 6to4-historic effort until IETF LC.

Following WG discussion requires a significant commitment.   I'm peripherally interested in v6ops, but until recently I had assumed that they were generally up to Good Stuff and didn't need my input for damage control purposes.  And the 6to4-advisory document is quite well written, and I came away from that discussion with the mistaken impression that the balance shown in that document was a reflection of the working group as a whole.  Also, I've had significant deadline pressures elsewhere, so haven't been able to check my v6ops mail folder as often as I'd like.

I don't think it's in IETF's interests to restrict input to only those who can make the significant commitment required to follow every IETF working group that might impact their work.  Frankly, with so many working groups, it's hard to even be aware of every working group that might impact one's work.

Keith

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Jun 2011 13:05:15 -0400

On Fri, Jun 24, 2011 at 09:36:13AM -0700, Murray S. Kucherawy wrote:

> By contrast, working groups tend to contain more expertise than may
> be available in an IETF LC; that's partly why they're formed.  I've
> never been an AD before, but I imagine I might consider the WG
> consensus to be at least a little bit more weighty than IETF LC
> resistance.

I rather hope not.  As someone else has argued in this thread, WGs
tend to be narrowly focussed.  The IETF LC is at least partly, as I
understand it, to make sure that something which seems an obviously
good idea to the WG doesn't have all manner of implications that the
WG perhaps did not consider.

It seems to me that very strong reaction in the IETF generally to a
proposal demands convincing counter-arguments from those who support
the publication.  I refuse to have an opinion about the example under
discussion, but surely we don't want to build in some preference for
what the WG says.

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Fri, 24 Jun 2011 09:57:13 -0800

On 06/24/2011 06:46 AM, Donald Eastlake wrote:
> judgement would be as to the consensus of the IETF community?

My understanding is that any decisions reached at meetings must
be ratified on mailing lists, which seems to me to suggest something
about order of precedence.

Melinda

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 24 Jun 2011 14:13:34 -0400

Hi Melinda,

> about order of precedence.

It depends on what you mean by "ratified". I suppose a WG meeting
could be said to have "reached a decision" but it isn't a decision of
the WG, just the meeting. It must be brought up on the WG mailing list
to provide broader opportunity for input, positive or negative. After
it has been brought up on the mailing list, then the WG Chair(s) judge
what the WG consensus is. It is certainly not required that, in making
that judgement, the WG Chairs can only look at WG mailing list
postings.

Thanks,
Donald

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Jun 2011 20:27:14 +0200 (MEST)

> judgement would be as to the consensus of the IETF community?

That is completely missing the point of the IETF consensus process.

If there is just one single person that objects during LC, but
raises 10 different issues, then it is totally irrelavant how many
there are that are in favour.  Raised issues have to be processed with the
issue resolution process, i.e. drilldown (probably during discussion)
into pure matters of taste (where a significant majority decision is OK),
procedural issues (which strongly need to be resolved) and technical
issues that need to be either resolved or determined&declared to be
out-of-scope (or documented that no practical solution is known to
exists but the proposal/document is useful in spite of that).

> area, and IETF plenary meeting discussions they have attended, is just

There is no problem with pointing to the resolution of previously
resolved issues in the WG issue tracker or WG / Document summary
for issued raised during IETF LC that aren't new -- provided that
the issue was actually resolved (rather than the objection withdrawn).

The number of documents produced in the IETF and looking for IESG
approval is huge, so we can only expect a small number of ADs to
have actually read the document and followed the discussion.

But in order to make the IESG decision process work _despite_ the
resource starvation, it is at least necessary for the responsible AD
to create a detailed IESG write-up of the Last Call listing all
issues that were raised including URLs or other suitable references
_to_the_original_messages_ that raised significant or controversial
issues and significant messages of the followup discussion,
for there to be a resource-conservative independent judgement
on the _original_ issues, the _original_ discussion and the proposed
resolution by the responsible AD, document sheperd and document
author/editor.

Yes, I know that this is currently not easy for the one doing
the write-up.  Maybe this could be simplified by the IETF Mailing
List exploder to _first_ put a message in the mailing list archive,
obtain a URL into the archive for it and then send out the message
_with_ that URL of the archived message out to the mailing list recipients.

-Martin

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Jun 2011 20:34:20 +0200

> _with_ that URL of the archived message out to the mailing list recipients.

X-Archived-At?

Best regards, Julian

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Jun 2011 20:55:29 +0200 (MEST)

> > _with_ that URL of the archived message out to the mailing list recipients.

rather not there.

Considering the sheer number of header lines of the averager mailing
list email that hits my mailbox, and considering how difficult it is
to get that junkyard visualized in some MUAs, I personally would prefer
a modification of the automatically added message signature.

The IETF mailing list exploder already automatically tacks a signature to
every redistributed message with an indirect URL to the "haystack"
i.e. the URL for the mailing list subscription page that itself contains
an URL to the mailing list archive.

potential solutions:
  - add a 4th line identifying the needle in the haystack.

  (bandwith-conservative)
  - replace the current indirect URL to the haystack (3rd line) with the
    direct message URL (needle URL) and add a back-reference to the mailing
    list subscription page to the top of the message/needle
    visualization page.

-Martin

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Jun 2011 21:00:09 +0200

>      list subscription page to the top of the message/needle

WFM.

Or make the archive URI a predictable function of the message ID, just 
like the W3C mailing list servers do.

Best regards, Julian

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 24 Jun 2011 15:11:26 -0400

Hi Martin,

> That is completely missing the point of the IETF consensus process.

Sometimes it does and sometimes it doesn't. It depends, as you state
below, on the type of issue or issues that are being discussed. I
should have stated that it was something like deciding between two
methods of accomplishing the same technical goal where neutral
observers do not think there is a big difference in the technical
effectiveness of the methods, or something like.

> there are that are in favour.

But then you go on, below, to say that the number of supporters really
is the most relevant thing if it turns out to be issues of taste...

> Raised issues have to be processed with the

So it really depends on the circumstances.

Thanks,
Donald

---

From: Doug Barton <[email-masked]>
Date: Fri, 24 Jun 2011 12:57:51 -0700

On 06/24/2011 09:08, John C Klensin wrote:
> idea.

I haven't seen those 2 ideas conflated anywhere, but it's not impossible 
that I've missed something.

> To paraphrase at least one comment, there is danger of

By "your document" above are you referring to Brian's 
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory ? If so I 
would argue that the extensive WG discussion about both documents meets 
your criteria. Taken together the 2 documents represent a series of 
compromises between those of us whose opinion is "Kill 6to4 dead, 
yesterday" and those who would like to give it as graceful an exit as 
possible. The "historic" document points out the reasons that doing it 
at all is probably a bad idea, and asks that it be off by default; while 
the "advisory" document tells people that want to to do it anyway how to 
do it right. Personally I was very satisfied with both products of the 
WG and taken as a whole I think they describe a very rational approach.

I would also encourage anyone who has strong opinions about the topic to 
read the WG archives for discussion of both drafts. It was wide-ranging 
and, I believe, thorough. I briefly considered summarizing the high 
points in this message, but my fear is that it would simply re-open 
debate on topics already covered more adequately in the WG archives.

hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Doug Barton <[email-masked]>
Date: Fri, 24 Jun 2011 13:05:50 -0700

> I often get the impression that dissenters are dismissed as "in the rough" and that their opinions, no matter how well expressed, are given less weight than those who are in favor.

One could also consider the idea that due to the very human tendency 
towards confirmation bias that those who dissent often view that 
dissenting opinion as both more important and more popular than a more 
objective observer would.

One of the reasons that I believe this document actually does achieve at 
least rough consensus is that in the course of the WG discussion 
something was achieved that at least in my experience is quite rare in 
the IETF, some people actually changed their opinions as a result of the 
discussion. To me that indicates that the concepts discussed were 
carefully considered (the concerns raised in the IETF LC being a subset 
of those discussed in the WG) and ultimately the right decision was 
reached. Of course, it could also be argued that I'm suffering from 
confirmation bias since I agree with the decisions reached, as far as 
they go.

hth,

Doug

--

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 16:11:29 -0400

On Jun 24, 2011, at 3:57 PM, Doug Barton wrote:

> By "your document" above are you referring to Brian's http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory ? If so I would argue that the extensive WG discussion about both documents meets your criteria. Taken together the 2 documents represent a series of compromises between those of us whose opinion is "Kill 6to4 dead, yesterday" and those who would like to give it as graceful an exit as possible. 

Taken together, the message is confusing. 

And for those of you whose opinion is "KIll 6to4 dead, yesterday" - that's way beyond the scope of what v6ops was chartered to do.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 16:14:02 -0400

On Jun 24, 2011, at 4:05 PM, Doug Barton wrote:

> One could also consider the idea that due to the very human tendency towards confirmation bias that those who dissent often view that dissenting opinion as both more important and more popular than a more objective observer would.
> 
> One of the reasons that I believe this document actually does achieve at least rough consensus is that in the course of the WG discussion something was achieved that at least in my experience is quite rare in the IETF, some people actually changed their opinions as a result of the discussion. To me that indicates that the concepts discussed were carefully considered (the concerns raised in the IETF LC being a subset of those discussed in the WG) and ultimately the right decision was reached. Of course, it could also be argued that I'm suffering from confirmation bias since I agree with the decisions reached, as far as they go.

I've been reviewing the WGLC comments.  I haven't finished doing so yet, but so far my impression is that the discussion was both thorough and well-organized.

Of course, consensus within v6ops is not the same thing as community-wide consensus, and the latter is what is required for a standards action.

Keith

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Jun 2011 16:17:53 -0400

Paul Hoffman <[email-masked]> wrote:
> I'm quite confused by this opinion. *No* IETF Last Call announcements,
> even those for standards track documents, say that they are to determine
> IETF consensus, yet IETF consensus is required for many of these
> documents.

   I cannot speak with any authority on this, but I can quote RFC 2026:
] 
] 4.2.2  Informational
] 
]  An "Informational" specification is published for the general
]  information of the Internet community, and does not represent an
]  Internet community consensus or recommendation.

   This seems pretty plain to me.

   As for Standards-track and BCP, I read RFC 2026 to call for "consensus
building", not "IETF consensus". YMMV.

> In your view, how are we to know which IETF Last Call announcements
> are to determine IETF consensus

   IMHO, essentially none of them. To quote RFC 2026:
] 
] 14. DEFINITIONS OF TERMS
]  Last-Call - A public comment period used to gage the level of
]     consensus about the reasonableness of a proposed standards action.
]     (see section 6.1.2)

   Section 6.1.2 is pretty long; I'll quote only one paragraph:
] 
]  The IESG will send notice to the IETF of the pending IESG
]  consideration of the document(s) to permit a final review by the
]  general Internet community.  This "Last-Call" notification shall be
]  via electronic mail to the IETF Announce mailing list.  Comments on a
]  Last-Call shall be accepted from anyone, and should be sent as
]  directed in the Last-Call announcement.

   I don't read that as requiring "IETF Consensus" to be determined:
merely that the "level of consensus" be considered -- strongly suggesting
that the IESG may approve something where the "level of consensus" falls
below "rough". (I do not intend to express any opinion whether they ever
do so.)

> and which are just to bring additional input to the IESG for a
> non-consensus decision?

   Clearly, RFC 2026 does not require any kind of consensus for Informational
documents.

   Perhaps less clearly, but IMHO, RFC 2026 does not require the IESG
to "determine" "IETF consensus" on Standards-track documents.

> Or are you saying that the IESG determines IETF consensus using metrics
> other than the discussion on ietf@?

   I have not said that. IMHO, the IESG procedures don't even attempt to
"determine IETF consensus" on the vast majority of documents. They attempt
to determine instead whether the document should be sent back for rework.

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 16:44:38 -0400

> ]  Internet community consensus or recommendation.

Even if the document was to be labeled as informational, this was clearly a standards action.  

> building", not "IETF consensus". YMMV.

Yes, but that consensus that is called for is IETF-wide consensus.   If WG consensus were all that were were required, there would be no need for an IETF-wide Last Call.  And I can't tell that there's been any attempt at all by the v6ops group or the document authors to build IETF-wide consensus on this.

> below "rough". (I do not intend to express any opinion whether they ever

The stated purpose of Last Call is to "gage [sic] the level of consensus".  Of course, IESG does have an additional role beyond determining consensus.  e.g. It may also make judgments about the document's technical quality, whether a document meets the 2026 criteria for a particular status (e.g. "no known technical omissions" for Proposed), whether appropriate processes were followed by a WG, etc.  

RFC 2026 does not explicitly state that community-wide consensus is required for standards action.  However it makes abundantly clear that community-wide consensus is the goal of everything in the process.  It also implies that lack of consensus is justification for appeal, and that the goal of the appeals process is to achieve consensus.

> to determine instead whether the document should be sent back for rework.

In my experience, this was also true.  Consensus was not an issue for most documents that I saw while on IESG; technical quality was.    But it's also clear that IESG is supposed to evaluate Last Call comments to "gage" consensus.

Keith

---

From: Doug Barton <[email-masked]>
Date: Fri, 24 Jun 2011 13:45:31 -0700

On 06/24/2011 13:11, Keith Moore wrote:
>> By "your document" above are you referring to
>> Brian'shttp://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory? If
>> so I would argue that the extensive WG discussion about both documents
>> meets your criteria. Taken together the 2 documents represent a series
>> of compromises between those of us whose opinion is "Kill 6to4 dead,
>> possible.

I'm not sure why you would think that. It fits in with a grand IETF 
tradition. :)

> And for those of you whose opinion is "KIll 6to4 dead, yesterday" -
> that's way beyond the scope of what v6ops was chartered to do.

ENONSEQUITUR

--

---

From: Doug Barton <[email-masked]>
Date: Fri, 24 Jun 2011 13:46:44 -0700

On 06/24/2011 13:14, Keith Moore wrote:
>>> I often get the impression that dissenters are dismissed as "in the
>>> rough" and that their opinions, no matter how well expressed, are
>>> given less weight than those who are in favor.
>>
>> One of the reasons that I believe this document actually does achieve
>> at least rough consensus is that in the course of the WG discussion
>> the IETF, some people actually changed their opinions as a result of
>> the discussion. To me that indicates that the concepts discussed were
>> carefully considered (the concerns raised in the IETF LC being a
>> subset of those discussed in the WG) and ultimately the right decision
>> was reached. Of course, it could also be argued that I'm suffering
>> from confirmation bias since I agree with the decisions reached, as
>> far as they go.
>
> I've been reviewing the WGLC comments. I haven't finished doing so yet,
> but so far my impression is that the discussion was both thorough and
> well-organized.

You might want to go further back in the archives than just the LC. 
There was quite a bit of discussion on both drafts.

> Of course, consensus within v6ops is not the same thing as
> community-wide consensus, and the latter is what is required for a
> standards action.

I'll leave that discussion to the process experts.

Doug

--

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 16:54:29 -0400

On Jun 24, 2011, at 4:46 PM, Doug Barton wrote:

> You might want to go further back in the archives than just the LC. There was quite a bit of discussion on both drafts.

I've read some of it, and participated in some of the discussion for -advisory.    Though my immediate question has been whether the WG really had rough consensus, and I don't think the other WG discussion matters too much in gauging that. 

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Jun 2011 17:40:44 -0400

--On Friday, 24 June, 2011 12:57 -0700 Doug Barton
<[email-masked]> wrote:

>> arguments for looking at the problem in a different way -- a
>> way that I've seen no evidence the WG considered at all.
>> That would be to explore alternatives to the rather blunt
>> instrument of making a protocol specification historic:
>> explaining what needs to be done to get it right (your
>> document does a lot of that) and then figuring out ways to
>> warn against the uses and configurations that we all (or
>> mostly) agree are bad news.

> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory ?

yes

> If
> so I would argue that the extensive WG discussion about both
> documents meets your criteria. Taken together the 2 documents
> represent a series of compromises between those of us whose
> opinion is "Kill 6to4 dead, yesterday" and those who would
> like to give it as graceful an exit as possible.

Doug,  you have just returned to the main point of Paul's
question.  Let me state it in a different way.  WGs who produce
drafts on a given issue tend to be made of folks who are heavily
concerned with that issue and who share similar perspectives on
it (that doesn't mean they agree on the answers, but they often
agree on the problem to be solved).   To even a much greater
degree than a decade or two ago, they also tend to be pretty
homogeneous (again, that doesn't mean they necessarily agree).
The reason we do IETF Last Calls is in order to bring community
perspective to bear, to consider things both cross-area and
cross-perspective and, if a WG has gotten over-focused on one
set of issues and ignored others, to create an opportunity to
bring the others out.

Now, the IESG gets to listen to all of those opinions, both WG
and non-WG, and say (in an extreme case) "the WG has engaged on
all the issues and has it right and the rest of the community,
no matter how numerous, doesn't have adequate understanding and
should be ignored".   This is supposed to be a process that
brings different technical perspectives out if they exist, not a
popularity contest.  I don't have any problem with that; I'm not
even clear that Paul does.

_However_ if something causes as much controversy as this did, I
think it is desirable for the IESG to be cautious in at least
two ways.   One is to examine whether it is worth sending the
draft back to the WG, saying "please review these points once
again and make sure you don't want to modify your
recommendation".   As far as I know, they did that... or
consulted with the WG leadership and concluded that the WG
position was sufficiently hardened that no amount of re-review
would make an difference.  Second, I think the IESG has some
implicit obligation to really document such a decision and the
reasons for it, not [just] to issue a Protocol Action notice
that can be easily construed the way several people on this list
have construed it, i.e., as "well the WG and the community input
disagreed, so screw the community".  

Personally, I don't believe that was the basis on which the IESG
made the decisions they made but, as is often the case in this
community, a little more explicitness and transparency about how
and why controversial decisions were made can head off a lot of
problems.

FWIW, if people actually believe that the IESG has gotten too
high-handed or dismissive of community input, I note that the
Nomcom Chair is looking for volunteers and will soon be looking
for input.

> The
> "historic" document points out the reasons that doing it at
> all is probably a bad idea, and asks that it be off by
> default; while the "advisory" document tells people that want
> to to do it anyway how to do it right. Personally I was very
> satisfied with both products of the WG and taken as a whole I
> think they describe a very rational approach.

And, if you will go back and read my comments on the subject,
you will find that I, personally, largely agree.  I just don't
think that adding "historic" to those pieces of advice will be
influential in accomplishing the goals, that it is a too-blunt
instrument, and its application in this sort of situation is
more likely to bring discredit on the IETF than to accomplish
the purpose for which its advocates are encouraging it.   I
believe I'm probably in the minority on that position and
recognize that I'm not likely to persuade anyone who isn't
persuaded already.  It certainly isn't the first time that has
happened and I have no particular problem with it.

But I do think that this is a situation in which a more nuanced
approach is appropriate (which is what my earlier note said) and
for more explanation from the IESG about the reasoning behind
their conclusion (which this one addresses).

I will now go back to lurking.

    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Jun 2011 17:48:46 -0400

--On Friday, 24 June, 2011 16:17 -0400 John Leslie
<[email-masked]> wrote:

>    Clearly, RFC 2026 does not require any kind of consensus
> for Informational documents.
>...

John,

A small nit...  While in this area as in many others, we've
never actually / formally updated 2026, things have evolved a
bit.  We've modified the RFC Editor model to include explicit
and separate streams, have added headers to indicate the stream
in which something is published, and have made provisions for
explicit statements about the level of consensus achieved.  IMO,
that is completely reasonable -- it is less important, IMO,
whether the IESG requires community consensus about a particular
document (regardless of whether it is Information, Full
Standard, or somewhere in between) than that they not
misrepresent the situation.

I don't quite see how that is relevant to this particular case,
either.

     john

---

From: james woodyatt <[email-masked]>
Date: Fri, 24 Jun 2011 16:10:15 -0700

> configurations that we all (or mostly) agree are bad news.

That's not how it appeared to me when I was participating the WG discussions and WG last call.  What I remember was that we had two drafts, the first, 6to4-advisory, aimed to do exactly what Mr. Klensin describes, and the second, 6to4-to-history, aimed at giving operators an excuse not to read the advisory, because hey-- 6to4 is history now.  The working group considered the option of publishing one and not the other.  That evaluation seemed to me to come to an end when the author of 6to4-advisory came out in support of publishing both documents.

In the WG discussions leading to the adoption of both drafts as work items, I supported 6to4-advisory and strenuously argued against taking up 6to4-to-historic.  When it became clear that I was on the losing side of that argument, and that WG consensus for publishing *both* would be achieved during LC, I analyzed my own reasons for opposing the 6to4-to-historic draft and concluded that I didn't really care that much if 6to4-to-historic were published, because the draft is clearly written to specify something other than what its authors and most of the WG were intending.

The WG consensus is to throw 6to4 into the historic trash bin.  The draft, however, doesn't do that.  It just tells the IETF to stop worrying and learn to love the bomb, while all the vendors of 6to4-capable equipment keep on keeping on with exactly what they're doing today.  I could live with that, and I said so.  Nobody seemed to care about it, but the observation *was* on the table.

I see that some of those in the opposition to 6to4-to-historic do not agree with me that the draft is utterly harmless and will be roundly ignored by industry.  To the extent that I can see how 6to4-to-historic may divert its intended audience from reading the much more important 6to4-advisory draft, I sympathize, but I don't see that argument moving too many minds.  I had kinda hoped that IESG would put a stop to this nonsense and kick the draft back to the WG with instructions to develop a phase-out plan for 6to4.  Alas, that didn't happen.  Oh well.

I do, however, wonder if we can finally remove 2002::/16 from the default policy table in the next revision of RFC 3484 on the grounds that 6to4 is Historic now, just like 3ffe::/16 is... that would be *excellent*.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jun 2011 19:40:50 -0400

On Jun 24, 2011, at 7:10 PM, james woodyatt wrote:

> I see that some of those in the opposition to 6to4-to-historic do not agree with me that the draft is utterly harmless and will be roundly ignored by industry. 

I think the effect of declaring something Historic is difficult to predict, and I doubt that all of "industry" will react in a uniform fashion.

We're a long way away from having universal v6; so far away that it's still not clear that it will ever happen.  We're not going to get there unless application vendors can ship code that makes good use of IPv6 (meaning the addressing and the programming model) and expect it to be able to run on customers' systems.  And we're not going to get that without a transition mechanism that's better than anything we currently have.  

The 6to4-advisory document lists many ways in which 6to4 falls short of being suitable for this.  So, I believe, does Teredo, for different reasons.   But in order to get something better we need to be able to use some of the techniques of both.  If v6ops is allowed to declare 6to4 as Historic, that can be used as a bat to quash any further development in this space.  And I find that completely unacceptable.

Keith

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 24 Jun 2011 17:10:34 -0700

>> I see that some of those in the opposition to 6to4-to-historic do not agree with me that the draft is utterly harmless and will be roundly ignored by industry. 

Were it completely harmless I think it wouldn't meet the needs of the authors or supporters either. Clearly they would prefer that it be off as a result, or that the usage be limited to people who've deliberately turned it on and therefore can be expected to tolerate the limitations.

---

From: james woodyatt <[email-masked]>
Date: Fri, 24 Jun 2011 18:22:43 -0700

> Were it completely harmless I think it wouldn't meet the needs of the authors or supporters either. Clearly they would prefer that it be off as a result, or that the usage be limited to people who'…

Which the 6to4-advisory draft also says quite clearly.

I pointed this out in the WG discussion.  Everybody understands that 6to4-advisory is sufficient to send that message.  No, the WG supporters of this draft are firmly convinced that 6to4-to-historic is also necessary because they mistakenly believe it does something else that 6to4-advisory does not say.

The common thread tying together the sentiment expressed by practically all the supporters of 6to4-to-historic is that they want 6to4 not merely turned off by default in subscriber equipment, they also want IETF blessing for operators to ignore the recommendations in 6to4-advisory aimed at IPv6 content and network service providers for properly handling the presence of intentional 6to4 users.  In shorter terms, they want to kill 6to4 dead dead dead starting yesterday.

This, as others have observed, is a rather confusing message, but it's the one with rough consensus behind it.  As I said before, I had hoped that IESG would take the opportunity to clarify this muddle and demand a phase-out plan for 6to4 before declaring it a historic curiosity.  But no, it looks like 6to4 tunnel-router mode will be going into the same bucket as wired equivalent privacy (WEP), i.e. a technology that everyone knows is obsolete, and would like to see go away forever, but nobody wants to buy the phase-out plan for it, and so it will continue to be ubiquitous and kept in support forever.  Because it works for some people with legacy gear and they don't want to change.

Thanks ever so much, IESG!

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 25 Jun 2011 11:25:57 +0900

james woodyatt wrote:

> No, the WG supporters of this draft are firmly convinced that
> 6to4-to-historic is also necessary because they mistakenly
> believe it does something else that 6to4-advisory does not say.

That IETF declare 6to4 historic means that IETF, naturally,
won't produce any new document on 6to4.

							Masataka Ohta

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Jun 2011 20:50:34 -0600

This thread brought up many good points but I would like to add one more that Lisa Dusseault made very clearly years ago. That is consensus is measured at a point of time. Many ideas start with people hating them and as people learn more, they may come to like them even thought the idea did not change. Or perhaps the deployment environment changed. The important point is that the results of consensus calls made in the past may or may not have much bearing on the current IETF consensus. I see IETF LC as a clear point where consensus can be measures before the IESG makes a decision. Most documents have very clear consensus by the time they reach IETF LC. For the ones that are not, every WG member is welcome to send comments to IETF LC, if they care - some times they do, mostly they do not. 

It's very hard to define consensus and I actually think it is better if we don't strive for a formal definition of it. As with many of the best things in life, most of us know it when we see it. The words rough consensus certainly mean to me a lot more than half of the of the informed people. I do not believe that silence can be read as consensus support for a position - it is simply silence - it is not in favor or again. However each chair or AD judging rough consensus chooses to define it for themselves, I hope the definition results in an environment where a document can be progresses by a small group of the willing and only stopped by the outrage of the masses. WIthout that, the willing will simply find a better place to work. And with that, I'm off to read the WHATWG list. 

Cullen

---

From: Christian Huitema <[email-masked]>
Date: Sat, 25 Jun 2011 04:18:04 +0000

It seems that we have wide consensus to publish the advisory document, not so much for the "6to4 historic" part. Can we just publish the advisory and be done with this thread?

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Sat, 25 Jun 2011 01:24:33 -0400

> Were it completely harmless I think it wouldn't meet the needs of the authors or supporters either. Clearly they would prefer that it be off as a result, or that the usage be limited to people who'…

But there is general agreement to turn 6to4 off by default.   It's the labeling of 6to4 as historic that is the divisive point.

Keith

---

From: Tim Chown <[email-masked]>
Date: Sat, 25 Jun 2011 10:44:55 +0100

> It seems that we have wide consensus to publish the advisory document, not so much for the "6to4 historic" part. Can we just publish the advisory and be done with this thread?

I'm a little confused by this discussion.

I had thought the call here was to solicit 'substantial' comments about -advisory and -historic.  Thus I assume people who, like me, are in favour of both drafts progressing are not going to respond to the list at all, which means the list isn't a reflection of consensus - it's not a vote.

I do agree with the comment that the call should be identifying new issues, and even if just one person raises several such (valid) issues, they should be considered as part of the process. 

While I'm now here, my personal view is that -advisory must be progressed and -historic should be progressed.

Tim

---

From: SM <[email-masked]>
Date: Sat, 25 Jun 2011 02:30:31 -0700

Hi Paul,
At 15:36 23-06-2011, Paul Hoffman wrote:
>in favor of it. If the consensus in a WG for a document was the same 
>as we saw on ietf@ for this document, and the WG chair declared 
>consensus anyway, there would be some serious talks with that WG AD 
>about the chairs.

Assuming that there was rough consensus (I agree with you that it was 
not rough at all), the document would still not satisfy the following 
statement:

   "It represents the consensus of the IETF community.  It has
    received public review and has been approved for publication by
    the Internet Engineering Steering Group (IESG)."

The IETF Last Call is to get cross-area review and, as others have 
pointed out, to provide an opportunity for people who have not read 
the WG document previously to comment.  Sometimes there is a rehash 
of the WG discussions.  Although that might be viewed by some 
participants as "wasting IETF time", it is part of the cost of the process.

If an objection was raised, the IESG might have to argue that the 
document represents the consensus of the IETF community.  That is 
generally based on the IETF Last Call comments and not discussions 
within the WG Cloud.

If a WG chair declared consensus on an issue like this, the 
responsible AD would hear about it.  If the IESG declared consensus 
on an issue like this, complain to NomCom about it.

Regards,
-sm

---

From: John Leslie <[email-masked]>
Date: Sat, 25 Jun 2011 09:16:26 -0400

>    the Internet Engineering Steering Group (IESG)."

   I actually don't know whether the intent is to attach that boilerplate:
it certainly isn't present in the I-D.

   I quite agree that -6to4-to-historic doesn't satisfy such a statement;
and I don't believe the IESG process for Informational track documents
gives any assurance of "consensus of the IETF community".

   In the interests of truth in advertising, perhaps we should be
looking towards boilerplate more like:
" 
" This document represents the consensus of the V6OPS WG...

   (Disclaimer: I date from when RFCs didn't claim any sort of consensus;
and I'd be happier if we simply avoided such claims on Informational
track RFCs.)

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Jun 2011 10:09:11 -0400

--On Friday, 24 June, 2011 16:10 -0700 james woodyatt
<[email-masked]> wrote:

> That's not how it appeared to me when I was participating the
> WG discussions and WG last call.  What I remember was that we
> had two drafts, the first, 6to4-advisory, aimed to do exactly
> what Mr. Klensin describes, and the second, 6to4-to-history,
> aimed at giving operators an excuse not to read the advisory,
> because hey-- 6to4 is history now.  The working group
> considered the option of publishing one and not the other.
> That evaluation seemed to me to come to an end when the author
> of 6to4-advisory came out in support of publishing both
> documents.

First. as I've told that author at more length privately, I
disagree with that decision as, apparently, do many others.  As
others have pointed out, it sends a very confusing message to
someone who doesn't know the WG history, is reading the RFCs in
isolation, and isn't doing so carefully.   Fortunately or
unfortunately, that is a pretty good description of the typical
reader of RFCs, as least in my experience/observation.  

As I told Brian, if the intent is to deliver a clear "we think
you REALLY REALLY SHOULD NOT (a term that is not quite in 2119)
use this, but, if you do anyway, take this advice", then you do
that in one document that explains both.   When you publish the
advice document and simultaneously publish a document that can
be read as saying "never mind, this, including the advice, is
all ancient history and you should pay no attention to it", you
are just being confusing.   IMO, that is largely independent of
whether you also move everything to Historic except that the
formal Historic classification just adds to the confusion.

Now that opinion obviously disagrees with that of the WG.  My
hypothesis is that the WG just got too close to the problem to
see the issue from the casual reader of RFCs who doesn't have a
long history with debates about the issue.  And, as others have
said, I believe that IETF LC is designed to identify exactly
that problem.  In matters of technical expertise, I believe the
IESG should balance WG opinion and IETF opinion very carefully,
giving great (but certainly not absolute) weight to issues that
the WG considered carefully and reached a conclusion about.
But when the evaluation is about whether the document is clear
to an expert who did not participate in the WG or whether it
sends a clear message, then I believe the opinions of those
outside the WG, without the history and shared understanding,
should absolutely predominate.  And I hope that, if you think
about it for a while, that reasoning will be clear.

> In the WG discussions leading to the adoption of both drafts
> as work items, I supported 6to4-advisory and strenuously
> argued against taking up 6to4-to-historic.  When it became
> clear that I was on the losing side of that argument, and that
> WG consensus for publishing *both* would be achieved during
> LC, I analyzed my own reasons for opposing the
> 6to4-to-historic draft and concluded that I didn't really care
> that much if 6to4-to-historic were published, because the
> draft is clearly written to specify something other than what
> its authors and most of the WG were intending.

And, if IETF Last Call had pointed out, really clearly, that the
intent of "...historic" was different from what the WG intended,
would you expect the IESG to follow the WG's intent or the text
of the document?  That is actually a serious question.  If I
were IESG, I'd argue strongly for punting both documents back to
the WG at that point and say "figure out what you really want
and mean and express it clearly and consistently in one
document".   But I'm no on the IESG and know that I'm taking
advantage of not having to deal with possible consequences and
side-effects of such a move.

> The WG consensus is to throw 6to4 into the historic trash bin.
> The draft, however, doesn't do that.  It just tells the IETF
> to stop worrying and learn to love the bomb, while all the
> vendors of 6to4-capable equipment keep on keeping on with
> exactly what they're doing today.  I could live with that, and
> I said so.  Nobody seemed to care about it, but the
> observation *was* on the table.

Yes.  And???  (see above)

> I see that some of those in the opposition to 6to4-to-historic
> do not agree with me that the draft is utterly harmless and
> will be roundly ignored by industry.  To the extent that I can
> see how 6to4-to-historic may divert its intended audience from
> reading the much more important 6to4-advisory draft, I
> sympathize, but I don't see that argument moving too many
> minds.  I had kinda hoped that IESG would put a stop to this
> nonsense and kick the draft back to the WG with instructions
> to develop a phase-out plan for 6to4.  Alas, that didn't
> happen.  Oh well.

With one major exception, I think that puts us pretty much on
the same page, including with some small disappointment at the
IESG for not telling the WG to do its job.   The exception is
that I believe  that every authoritative-sounding document that
is published in the IETF Stream and then ignored by industry
strikes a blow against IETF's overall credibility and that those
blows, however small, are cumulatively damaging.

And, from your later note but very much to the same point...

> But no, it looks like 6to4 tunnel-router mode will be going
> into the same bucket as wired equivalent privacy (WEP), i.e. a
> technology that everyone knows is obsolete, and would like to
> see go away forever, but nobody wants to buy the phase-out
> plan for it, and so it will continue to be ubiquitous and kept
> in support forever.  

In addition, WEP, and the process that created it, are routinely
held up outside that group as the product of a clueless
standards body that probably understood radios but that
exhibited a complete lack of clue where encryption was
concerned.  That may be an unfair rap, or may not be, but, as
far as good reputations are concerned, it is bad news...

    john

---

From: SM <[email-masked]>
Date: Sat, 25 Jun 2011 11:01:08 -0700

>gives any assurance of "consensus of the IETF community".

It doesn't.

The IANA Considerations section raises an interesting question about 
whether it is appropriate to have such action in an Informational RFC.

>" This document represents the consensus of the V6OPS WG...

That document would then have to be published as a WG Snapshot.  That 
label does not exist yet.

>and I'd be happier if we simply avoided such claims on Informational

The objective was to document the level of consensus.  It is 
sometimes overlooked as the I-D does not contain the final 
boilerplate text.  I would be happy if such claims were avoided in 
Informational RFCs as it makes the line between Standards-Track and 
Informational fuzzy.

At 02:44 25-06-2011, Tim Chown wrote:
>I had thought the call here was to solicit 'substantial' comments 
>about -advisory and -historic.  Thus I assume people who, like me, 
>are in favour of both drafts progressing are not going to respond to 
>the list at all, which means the list isn't a reflection of 
>consensus - it's not a vote.

The wording in the Last Call announcement says "substantive 
comments".  The use of the word "substantive" is intentional (see 
comment from "the Last Defender of Camelot" [1]).  A response is 
optional if there are already arguments in the I-D to counter the 
"substantive comments".  If there are strong objections, it is left 
to the working group or author to see whether it is worthwhile to 
address the objections.

A long time ago, there was an RFC [2], from which I'll quote:

   "This group of people struggled with a broad range of issues in host
    implementations of the Internet protocols, attempting to reconcile
    theoretical and architectural concerns with the sometimes conflicting
    imperatives of the real world.  The present RFC recaps the results of
    this struggle, with the issues that were settled and those that
    remain for future work."

   'However, not all issues were so easy; the working group struggled
    with a number of deep and controversial technical issues.  Where the
    result was a reasonable consensus, then definite, firm
    recommendations and requirements resulted.  We list these settled
    issues in Section 2.  Section 2 also lists a number of areas where
    the HR RFCs fill gaping holes in the current specifications by giving
    extended discussions of particular issues.

    However, in some other cases the working group was unable to reach a
    crisp decision or even a reasonable consensus; we list these open
    issues in Section 3.  Future discussion is needed to ascertain which
    of these issues really do have "right answers", and which can
    reasonably be left as implementation choices.'

>the WG considered carefully and reached a conclusion about.

It's better when there is consensus on a reclassification to Historic.

>blows, however small, are cumulatively damaging.

Agreed.

At 07:36 25-06-2011, Noel Chiappa wrote:
>organization. When you have a _significant_ minority which is really unhappy
>with a decision, it's going to have poisonous effects which are going to
>hamper the promulgation/adoption of that design/decision/etc. And this is in
>fact what have seen happen, when we crossed this line before.

Agreed.

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02651.html
2. http://www.rfc-editor.org/rfc/rfc1127.txt

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 25 Jun 2011 12:18:05 -0700

> I've read some of it, and participated in some of the discussion for -advisory.    Though my immediate question has been whether the WG really had rough consensus, and I don't think the other WG di…

The  question of what the wg thought at the time of the wg last call is supposed to be captured in the document shepherd writeup.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/history/

I belive that in the case of this documents the unresolvable but understood objections present in the wg process around this document are specifically called out.

---

From: Pete Resnick <[email-masked]>
Date: Sat, 25 Jun 2011 16:15:02 -0500

> gives any assurance of "consensus of the IETF community".

I believe the IESG concluded that, although the document itself is 
Informational, it is moving two RFCs to Historic status, which is a 
Standards Action, and that we would use whatever procedures are 
appropriate to a Standards Action to act on the document. This was the 
third point of my DISCUSS comment and I believe the rest of the IESG 
agreed with me on this point.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 25 Jun 2011 16:48:07 -0700

On Jun 25, 2011, at 2:15 PM, Pete Resnick wrote:

> I believe the IESG concluded that, although the document itself is Informational, it is moving two RFCs to Historic status, which is a Standards Action, and that we would use whatever procedures are appropriate to a Standards Action to act on the document. This was the third point of my DISCUSS comment and I believe the rest of the IESG agreed with me on this point.

Draft 4 which went through wgcl and was  submitted to the iesg had an intended status of standards track, at the request of the iesg the reguested status was changed to informational. The document is a standards action and thus must meet the higher standard to pass iesg review regardless of it's intended status... This is entirely consistent with historical precident as far as I can tell.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 25 Jun 2011 21:42:08 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, June 24, 2011 10:05 AM
> To: [email-masked]

Maybe I'm taking your words too extremely, but if WGs tend to be narrowly focused, then how can they be reasonably assured of the success of anything they produce?  I'm imagining a model here wherein a WG produces documents suffering from a focus that is too narrow, those documents go to IETF LC or the IESG, and are invariably shot down because they failed to account for this or that outside of that focus.  It would take a huge number of iterations to get anything done.

Rather, I would hope they would have or seek to have enough people in them to bring breadth as well as depth, specifically so that they aren't producing things prone to raise objections.  Perhaps we see this as the role of the AD that is overseeing that particular WG, but that seems a huge burden to put on one person.

For the working groups and documents into which I've put work, I've made a point of seeking the breadth so that the reviews of the various directorates, whose comments are influential with the IESG, don't end up stalling publication.  I would hope this is common practice.

> discussion, but surely we don't want to build in some preference for

I suspect the documents from a WG should carry within them enough instructive text to include those arguments up-front, so if there's any objection voiced at IETF LC, it's bound to be new material.  The re-hashing of the same arguments made in the WG during IETF LC seems like a waste of time to me unless there are new details available.

-MSK

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 26 Jun 2011 07:53:15 +0300

>> gives any assurance of "consensus of the IETF community".
 From RFC 5741, Section 3.2.2, for Informational documents which were 
Last Called and approved on IETF Stream:

Note the first sentence.  By approving the Informational RFC which Last 
Call was issued for, IESG claims that IETF consensus exists.  Thia 
assumes Last Call which actually resulted in IETF consensus.  However, 
if Last Call doesn't represent such sort of agreement, IESG just 
shouldn't approve the document.

Mykyta Yevstifeyev

---

From: Keith Moore <[email-masked]>
Date: Sun, 26 Jun 2011 09:09:55 -0400

> Maybe I'm taking your words too extremely, but if WGs tend to be narrowly focused, then how can they be reasonably assured of the success of anything they produce?  I'm imagining a model here where…

Quite often it really doesn't matter that a WG is narrowly focused.  Consider IP-over-foo documents, for example.  Most of the rest of the community doesn't care, or need to care, how a particular IP-over-foo mechanism is defined.  IP has been around so long that people generally understand what any given IP-over-foo mechanism needs to accomplish.   Even where some difficult compromise is needed, the community can generally trust the Internet area to make reasonable decisions. 

But cross-area concerns in IETF have often been handled poorly.   The way IETF is structured, it takes careful crafting of a charter and close management by a politically skilled and conscientious AD, to get a working group whose output is going to affect a wide range of concerns, to produce documents that really earn community-wide consensus.   This has to be balanced against a very real concern that trying to put too many different kinds of people in the same room, so to speak, might result in a group that can't agree on anything.  (When I was an AD my goal was always to get a broad spectrum of interests in the room, but I remember one occasion where the group failed miserably because the various factions were completely unwilling to compromise on how to solve a problem....in this case because two out of the three factions saw an opportunity for a land grab and weren't about to give it up that easily.) 

Without pointing fingers, I think it's fair to say that the results of WGs producing documents that really had broad consensus of the community, have been mixed.   Some WGs and ADs have done better jobs than others.   

Note that these are effects of scale.  I remember it being easier to look for, and to get consensus on, such issues when active participation in IETF was only a few hundred people.  It was certainly easier to track what was going on in IETF when there were fewer working groups.

Also, in the distant past there were plenary meetings where each area would give a summary of activity in that area for the benefit of all of the participants.   Those meetings tended to drag a bit, and take time away from WG sessions, so I don't think they were missed very much.  But it might be that a stripped down version of such meetings - focusing on issues that might affect multiple areas of concern - would benefit the community, and be more important than WG sessions.  (I tend to think that IETF has too many WGs these days, but of course that just reflects the incredible breadth of the Internet today.)

> Rather, I would hope they would have or seek to have enough people in them to bring breadth as well as depth, specifically so that they aren't producing things prone to raise objections.  Perhaps w…

It is.

> For the working groups and documents into which I've put work, I've made a point of seeking the breadth so that the reviews of the various directorates, whose comments are influential with the IESG…

It's a good idea, and I suspect it's often sufficient, but not always.  

> I suspect the documents from a WG should carry within them enough instructive text to include those arguments up-front, so if there's any objection voiced at IETF LC, it's bound to be new material.…

Sometimes it does help if the WG explains why it made particular decisions; that can help to reduce re-hashing of those same issues during IETF LC.  That doesn't by itself counter the effect of WG bias in favor of some concerns and against others, though it might make such biases more obvious both to the WG and to the community at large.

In general, I think WGs need to be more aware that their job is to produce a document that will earn consensus of the whole community.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Jun 2011 10:06:29 -0400

+1

--On Saturday, 25 June, 2011 04:18 +0000 Christian Huitema
<[email-masked]> wrote:

> It seems that we have wide consensus to publish the advisory
> document, not so much for the "6to4 historic" part. Can we
> just publish the advisory and be done with this thread?