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

[t.petch]

- Original Message -
From: "Paul Hoffman" 
To: "The IESG" 
Cc: "IETF-Discussion list" 
Sent: Friday, June 24, 2011 12:36 AM
> Greetings again. The subject line is an honest question, not a gripe.
>
> For those on the ietf@ mailing list, please see
. 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
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Stephen Farrell]

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

On 24/06/11 02:15, Paul Hoffman wrote:
> 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? 

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.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

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

> On 6/23/11 4:36 PM, Paul Hoffman wrote:
>> Greetings again. The subject line is an honest question, not a
>> gripe.
>> 
>> For those on the ietf@ mailing list, please see
>> .
>> 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 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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 5:40 AM, Stephen Farrell wrote:

> 
> Basically, I approached this the way Peter did. One further
> point below though.
> 
> On 24/06/11 02:15, Paul Hoffman wrote:
>> 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? 
> 
> 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;-)

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Yang C Sijes]

On 2011-6-24 6:36, Paul Hoffman wrote:

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

For those on the ietf@ mailing list, please 
see. 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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Brian E Carpenter]

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

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

   Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Scott Kitterman]

On Thursday, June 23, 2011 09:34:33 PM Brian E Carpenter wrote:
> On 2011-06-24 12:44, Peter Saint-Andre wrote:
> > On 6/23/11 4:36 PM, Paul Hoffman wrote:
> >> Greetings again. The subject line is an honest question, not a
> >> gripe.
> >> 
> >> For those on the ietf@ mailing list, please see
> >>  >> ot/>. 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.
> 
> 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.

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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[John Leslie]

   (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  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  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 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 8:34 AM, Brian E Carpenter wrote:

> 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 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).
> 
> I suspect that operators are *severely* under-represented on this
> list (ietf@ietf.org) because it is very noisy and operators have other
> priorities. Most of them are probably unaware of this discussion,
> in fact.

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 8:55 AM, John Leslie wrote:

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

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.

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

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.

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

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

Keith


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Paul Hoffman]

On Jun 24, 2011, at 2:40 AM, Stephen Farrell wrote:

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

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Paul Hoffman]

On Jun 24, 2011, at 5:55 AM, John Leslie wrote:

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

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Stephen Farrell]

On 24/06/11 15:17, Paul Hoffman wrote:
> On Jun 24, 2011, at 2:40 AM, Stephen Farrell wrote:
> 
>> 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.
> 
> 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? 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.

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? :-)

> 
> --Paul Hoffman
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Donald Eastlake]

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
 d3e...@gmail.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Agenda for IETF 81 not available

[Marc Petit-Huguenin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to the IETF web site, the preliminary agenda for IETF 81 should have
been published yesterday, but is still not available.

Something similar happened for the previous IETF meeting, so I wrote a
Greasemonkey script that fixes the dates in the IETF web site so they match 
reality:


// ==UserScript==
// @name   fix-ietf
// @namespace  http://shalmaneser.org/fix-ietf
// @descriptionAlign IETF meeting important dates with reality
// @includehttp://www.ietf.org/meeting/cutoff-dates-*
// ==/UserScript==
var days = ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday",
"Saturday" ];
var e = document.getElementsByTagName('strong');
for (var i = e.length -1; i >= 0; i--) {
if (e[i].nextSibling !== null &&
e[i].nextSibling.nodeValue.indexOf('Preliminary agenda') !== -1) {
var d = new Date(e[i].childNodes[0].nodeValue.slice(0, 10));
d.setTime(d.getTime() + 5 * 8640);
e[i].childNodes[0].nodeValue = d.getFullYear() + "-" + 
(d.getMonth() < 9 ? "0"
: "") + (d.getMonth() + 1) + "-" + d.getDate() + " (" + days[d.getDay()] + "):";
}
}

- -- 
Marc Petit-Huguenin
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk4EqFUACgkQ9RoMZyVa61d2zQCeITfOgnwB3GGRksdvp5LWU3ie
ffIAnjFBMAY/09WIb+fyxpxOcKflS1/v
=u6vZ
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART LC review of draft-ietf-ftpext2-hosts-02

[Roni Even]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

 

Please resolve these comments along with any other Last Call comments you
may receive.

 

 

Document: draft-ietf-ftpext2-hosts-02

Reviewer: Roni Even

Review Date:2011-6-21

IETF LC End Date: 2011-6-30

IESG Telechat date: 2011-6-30

 

Summary: This draft is ready for publication as a standard track RFC.

 

Major issues:

 

Minor issues:

 

Nits/editorial comments:

 

 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dnsext-rfc2672bis-dname-22

[Scott Rose]

FYI:
A new version (-23) of the dname-bis draft has been posted with the two 
sections re-added (resolver algorithm and examples of DNAME use). I haven't 
heard any comments from the DNSEXT WG on it, but it was only just posted.

Scott 

On Jun 8, 2011, at 5:50 PM, Ben Campbell wrote:

> Thanks for the response! Comments below, eliding the bits I think need no 
> further comment.
> 
> On Jun 8, 2011, at 12:11 PM, Scott Rose wrote:
> 
>> Perhaps the document should only update RFC 2672 instead of obsoleting it?  
> 
> That would resolve my concern, if it fits with the intent of the work group.
> 
> 
>> 
>> As for the nits:
>> 
>> 
>> On Tue, Jun 7, 2011 at 6:35 PM, Ben Campbell  wrote:  
>> 
> 
> [...]
> 
>> Yes, will correct.
>>  
>> -- ..., 7th paragraph: "...replaced with the word "DELETED"."
>> 
>> Won't that just leave the word "deleted" hanging on page without 
>> explanation? Wouldn't it be better to just simply delete it?
>> 
>> 
>> Maybe, but I think the logic was that if there is some text there (just 
>> something), it can be cleanly referenced (i.e. "DELETED [RFC]")if 
>> someone is making a revised version of the RFC for some purpose.  Purely 
>> deleting it accomplishes the task, but this provides a good "hook" for a 
>> paper trail.
>> 
> 
> Okay. On reflection, it's not like we really render the updates the old RFC 
> documents.
> 
> 
>> Scott
>> ___
>> Gen-art mailing list
>> gen-...@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
> 

===
Scott Rose
NIST
scott.r...@nist.gov
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[RJ Atkinson]

Earlier, Paul Hoffman wrote, in part:
> ...the IESG just approved publication of X, even with
> what appears to be a lack of consensus in the comments
> on the ietf@ mailing list.
> 
> (some other text elided here.)
> 
> For a document such as this, why even ask for IETF consensus 
> if the IETF consensus doesn't matter?
>  
> (remaining text elided here.) 


Next, as a reference, here is a boilerplate snippet from
a recent IETF Last Call:
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf at ietf.org mailing lists by 2011-07-21. Exceptionally, comments
> may be sent to iesg at ietf.org instead. In either case, please retain
> the beginning of the Subject line to allow automated sorting.


The "IETF Consensus" matters, and I believe the IESG 
did fully and properly consider that matter in the case
that appears to have driven your note.

There appears to be a confusion underlying your note.

Paul's assertion that public postings to the IETF Discussion 
list are the only metric for "IETF Consensus" is NOT correct 
-- and never has been in the past.  

"IETF Consensus" includes ALL of the inputs that the IESG
receives about a document or issue that is put to IETF
Last Call.   The Last Call announcement specifically says,
for example, that comments may be sent privately to the
IESG.

Consensus inputs are NOT limited to posted public comments,
BUT ALSO include formal liaisons, communications with various 
WG Chairs (not limited to the sponsoring WG), private email 
to the IESG, private email to an AD, and more.

Note also that this is THE SAME as how WG Chairs are supposed
to operate.  WG Chairs are supposed to consider ALL inputs,
NOT ONLY public postings to the WG list, BUT ALSO private
inputs from WG participants and other applicable folks,
and whatever other inputs arrive after a WG Last Call is
announced.

I hear that Paul H is unhappy with this particular outcome,
but there is no evidence of any kind of process problem
or process mistake here.

Yours,

Ran


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 10:44 AM, Stephen Farrell wrote:
> 
> On 24/06/11 15:17, Paul Hoffman wrote:
>> On Jun 24, 2011, at 2:40 AM, Stephen Farrell wrote:
>> 
>>> 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.
>> 
>> 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).

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

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

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 10:46 AM, Donald Eastlake wrote:

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

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.

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

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.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Paul Hoffman]

On Jun 24, 2011, at 8:21 AM, RJ Atkinson wrote:

> Paul's assertion that public postings to the IETF Discussion 
> list are the only metric for "IETF Consensus" is NOT correct 
> -- and never has been in the past.

Come on, Ran. I never said "only metric", did I? This whole thread is about 
asking the IESG how they determine IETF consensus, with this being an example.

The IETF Discussion list and the the IESG balloting history are the only 
observable metrics we have, thus my question on this thread.

> "IETF Consensus" includes ALL of the inputs that the IESG
> receives about a document or issue that is put to IETF
> Last Call.   The Last Call announcement specifically says,
> for example, that comments may be sent privately to the
> IESG.

Completely correct.

> Consensus inputs are NOT limited to posted public comments,
> BUT ALSO include formal liaisons, communications with various 
> WG Chairs (not limited to the sponsoring WG), private email 
> to the IESG, private email to an AD, and more.

Completely correct. You also left out the shepherd report, which also contains 
valuable information about the level of consensus in the WG.

And you have now listed so many variables, it begs the question: how does the 
IESG actually make the call when the observable comments on ietf@ make 
consensus seem questionable?

> Note also that this is THE SAME as how WG Chairs are supposed
> to operate.  WG Chairs are supposed to consider ALL inputs,
> NOT ONLY public postings to the WG list, BUT ALSO private
> inputs from WG participants and other applicable folks,
> and whatever other inputs arrive after a WG Last Call is
> announced.

We probably disagree here: I don't think that WG chairs should make consensus 
decisions based on private inputs that cannot be validated. Doing so is begging 
for WG chair over-reaching.

> I hear that Paul H is unhappy with this particular outcome,

...which means that you did not read the messages I sent. I explicitly said I 
didn't care about this one, which is why I didn't say anything during the Last 
Call.

> but there is no evidence of any kind of process problem
> or process mistake here.

Nor did I say that there was. I asked a question that this particular Draft 
helps illuminate, and I did so after talking to ADs who thought there were 
indeed interesting process problems. YMMV.

--Paul Hoffman

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 11:21 AM, RJ Atkinson wrote:

> Earlier, Paul Hoffman wrote, in part:
>> ...the IESG just approved publication of X, even with
>> what appears to be a lack of consensus in the comments
>> on the ietf@ mailing list.
>> 
>> (some other text elided here.)
>> 
>> For a document such as this, why even ask for IETF consensus 
>> if the IETF consensus doesn't matter?
>> 
>> (remaining text elided here.) 
> 
> 
> Next, as a reference, here is a boilerplate snippet from
> a recent IETF Last Call:
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf at ietf.org mailing lists by 2011-07-21. Exceptionally, comments
>> may be sent to iesg at ietf.org instead. In either case, please retain
>> the beginning of the Subject line to allow automated sorting.
> 
> 
> The "IETF Consensus" matters, and I believe the IESG 
> did fully and properly consider that matter in the case
> that appears to have driven your note.
> 
> There appears to be a confusion underlying your note.
> 
> Paul's assertion that public postings to the IETF Discussion 
> list are the only metric for "IETF Consensus" is NOT correct 
> -- and never has been in the past.  
> 
> "IETF Consensus" includes ALL of the inputs that the IESG
> receives about a document or issue that is put to IETF
> Last Call.   The Last Call announcement specifically says,
> for example, that comments may be sent privately to the
> IESG.
> 
> Consensus inputs are NOT limited to posted public comments,

I agree with this much:  IESG, at least, should be able to consider private 
comments about document and standards actions, as input to its determinations. 

But one of the important attributes of consensus, one of the things that makes 
it so powerful, is that ideally, it's visible to everyone.  Take the example 
where a bunch of people in a room are asked a question and asked to raise hands 
to indicate yea or nay.   If only one or two people express a particular 
opinion, they can each see that for themselves, and that the "rough consensus" 
is clearly against them.   Likewise, the other participants will be able to see 
that the rough consensus is on their side of things. 

On a mailing list, it's a bit harder.  But still, when the traffic is visible 
to all list participants, it isn't too hard to know whether your opinion is 
widely supported, or whether you're part of a small minority.

In my experience, private input to IESG is more valuable in helping the IESG 
deal with technical evaluation or other concerns, than with consensus 
determination.   At least when I was on IESG, the volume of private Last Call 
responses was fairly small and I don't recall a case when I thought it would 
affect a determination of community wide consensus.But private input was 
occasionally quite valuable in other ways.

While I do think that IESG should be able to consider private input in 
consensus determination, from a process standpoint it's problematic.  If the 
IESG decision doesn't reflect the visible consensus or lack thereof, this quite 
properly raises a question as to whether IESG has properly evaluated consensus. 
 So in the event that there were a substantial amount of private input, IESG 
would do well to find a way to make it clear to the public that is conclusions 
were based on that input, in what way, and for what reasons.

In this particular case I don't see any reason to believe that IESG has 
received a substantial amount of private input.  e.g. I didn't see any mention 
of such input in the IESG writeup or the IESG members' comments.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[John C Klensin]

--On Friday, 24 June, 2011 13:34 +1200 Brian E Carpenter
 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



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[RJ Atkinson]

On 24  Jun 2011, at 11:50 , Paul Hoffman wrote:
> And you have now listed so many variables, it begs the question:

Paul,

I disagree that it begs that question.  

The IETF processes have always been open to ALL inputs from whatever 
source, in all parts of its processes.  You write that text above as if 
listening to all inputs is news, and it just isn't.

> how does the IESG actually make the call when the observable
> comments on ietf@ make consensus seem questionable?

The make their best effort determination, just as they always do.
That is how things have ALWAYS worked.  It works well.

Consensus in the IETF has NEVER been a numbers game, 
counting merely the public postings.  The IETF doesn't vote.

Just counting the numbers of public postings would be voting,
and this organisation has made a quite explicit decision 
NOT to vote.  

I'm told IEEE 802 votes, and I'm told they are happy with the results.
That's great for them, if true, but it isn't sensible for IETF.

To repeat some of what Don Eastlake wrote (I read his note 
just after sending my earlier note):
> But a narrow rule 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.

I totally agree with Don's quoted text just above.  

There is not now, has never been, and could never be a crisp rule 
defining a formula or algorithm on how the IESG determines consensus 
(or on how a WG Chair determines consensus).

I know of a large number of cases where one or more people sent private 
inputs to WG Chair(s) or to IESG folks on some Last Call item -- simply 
to avoid IETF-related controversy.  

Cheers,

Ran Atkinson




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Martin Rex]

RJ Atkinson wrote:
> 
> The "IETF Consensus" matters,

I believe it should, but I currently completely fail to see
that it did matter to the IESG.


>
> and I believe the IESG did fully and properly consider that matter
> in the case that appears to have driven your note.

I would be curious about the IETF Last Call writeup from the responsible
Area Director about the issue that were raised during IETF Last Call
and their resolution, rfc-4858 Section 3.2 (2.i) => (2.b)-(2.h)

  http://tools.ietf.org/html/rfc4858#page-10


I don't see that IETF LC Writeup in the Datatracker

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


And I don't see the significant objection specifically on the
procedural issue that moving to historic is an abuse of the
IETF process in the comments of other ADs here:

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


So I agree to Pauls original request for clarification:
Has the IESG given itself entirely new procedures for protocol
actions, and when are those going to be published  (maybe using
the same bypass of the traditional IETF consensus
process that the above document seems to have used).


> 
> Paul's assertion that public postings to the IETF Discussion 
> list are the only metric for "IETF Consensus" is NOT correct 
> -- and never has been in the past.  

If you read rfc4858 section 3.2 above, there was supposed to be a collection,
determination and resolution process for issues raised in an IETF LC in
just the same fashion as for the WG LC, and an IETF writeup of
significant issues raised during IETF LC and their resolution
as a prerequisition for an IESG decision.

If the new IESG approach to faster publication of RFC is to
simply ignore issues raised during IETF LC and rely primarily
on WG Last Call, and to make this change to the IETF procedures
bypassing public discussion and IETF consensus, then it would
be helpful for the resource management of IETF participants
when determining where to spend their valuable time: on WG
discussions or IETF LCs.


> 
> "IETF Consensus" includes ALL of the inputs that the IESG
> receives about a document or issue that is put to IETF
> Last Call.

IETF Consensus precludes ignoring procedural issues and
in-scope technical issues.  Otherwise it is IESG consensus
at best.


Why was there no serious consideration to downgrade 6to4 to
experimental instead of moving it to historic?
Are there any serious procedural issues against "experimental"?


>
> The Last Call announcement specifically says,
> for example, that comments may be sent privately to the
> IESG.
> 
> Consensus inputs are NOT limited to posted public comments,
> BUT ALSO include formal liaisons, communications with various 
> WG Chairs (not limited to the sponsoring WG), private email 
> to the IESG, private email to an AD, and more.


The irritation is about consensus-precluding input that has been
openly discussed in a quite elaborate fashion and a complete
lack of writeup and resolution of the IETF LC issues on the part
of the responsible AD.

...which bears resemblance with what this words of rfc2418
specifically cautions against:

   http://tools.ietf.org/html/rfc2418#section-2.3

   Proposed working groups often comprise technically competent
   participants who are not familiar with the history of Internet
   architecture or IETF processes.  This can, unfortunately, lead to
   good working group consensus about a bad design.


The job of the IESG is _not_ to defend a WGs interests against the interests
of the IETF at large, but the other way round, to ensure that the
interests of the IETF at large are sufficiently addressed by the output 
of the WG (or the author of an independent submission) before a document
is published as RFC.


> 
> Note also that this is THE SAME as how WG Chairs are supposed
> to operate.  WG Chairs are supposed to consider ALL inputs,
> NOT ONLY public postings to the WG list, BUT ALSO private
> inputs from WG participants and other applicable folks,
> and whatever other inputs arrive after a WG Last Call is
> announced.

Yes, but in an open standardizations body, the WG Chairs need to
document "openly" whatever input (content, not necessary contributor)
that they based their decision on.

A WG Chair or AD writing "I've received important input from important
lobbies, but I am unwilling or unable to disclose any content,
so I declare consensus to be that certain way." would not be appropriate
for the original open standardization process of the IETF.

Neither the absence of a write-up or deliberate ignorance of
raised procedural and in-scope technical issues.  Also contentious
matters of taste should be documented in the write-up.


-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] 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?
> 
> 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.

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.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 12:18 PM, RJ Atkinson wrote:

> Consensus in the IETF has NEVER been a numbers game, 
> counting merely the public postings.  The IETF doesn't vote.
> 
> Just counting the numbers of public postings would be voting,
> and this organisation has made a quite explicit decision 
> NOT to vote.  

It's true in many ways that IETF does not vote.   Last Call inputs are not 
limited to strictly yea or nay; and there are no well-defined criteria for when 
an action has sufficient support (or lack thereof) from participants.

At the same time, when evaluating consensus, it's often useful to do a count of 
the number of approvals vs. objections.   Anytime there is a significant number 
of objections, "rough consensus" is in doubt. 

Sometimes when weeding through a long exchange of emails, it's hard to get a 
sense of just what the balance is without doing an actual count.  Actually 
counting names helps remove some kinds of bias, e.g. the tendency to count 
opinions with which one agrees, more than those with which one disagrees. 

But even counting is an approximate process.   Not all responses are entirely 
yea or nay, and sometimes peoples' opinions shift as the conversation 
progresses.  (which, IMO, is a good sign.)

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: one data point regarding native IPv6 support

[Noel Chiappa]

> From: Christian Huitema 

> From Noel analysis

A belated (sorry) note to clarify the record: all I did was repeat stuff
from other people's studies (principally the one by Geoff Huston); they
should get all the credit.


And while I'm here anyway...

> it seems that a lot of the issues could be mitigated by simple
> connectivity test.

Well, IPv6 Neighbour Discovery is just the thing. I gather it's turned off
on 6to4 links, which in retrospect was probably a mistake. I would
recommend that it be turned on, but apparently the WG decided against
making that recommendation in the '6to4 fixes' document?

Other work with similar 'automatic' (i.e. not manually configured) overlay
networks has shown that conditions in the Internet these days are such
that one simply cannot assume that just because one's next-hop packet
switch appears to have a routing table entry for some destination, that
that means that any traffic sent to it will get there. You simply _have_
to do liveness testing (and not just on the other node, but also on the
paths in both directions).

On overlay networks with large fanouts, this can present a rather tricky
problem - O(N) overhead - but there are a variety of tricks (e.g.
piggybacking liveness mechanisms on user traffic) one can use. That
shouldn't be a problem in this case, which is why I think just turning on
ND on 6to4 is the way to go.


> It also does not solve the problem of routers advertising an IPv6
> route to 2002::/16 and then failing to deliver the IPv4 packets.

Well, RFC-3068 does say:

  "Any 6to4 relay router corresponding to this specification must
   include a monitoring function, to check that the 6to4 relay function
   is operational.  The router must stop injecting the route leading to
   the 6to4 anycast prefix immediately if it detects that the relay
   function is not operational."

So boxes that do what you mention (advertising 2002::/16 and then failing
to deliver the packets to the matching IPv4 address) are _already_
violating the spec...

NOel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard

[Mykyta Yevstifeyev]

Hello,

This document is well written; I'm strongly for its publication on 
Standards Track.  I have an only remark.  This document doesn't seem to 
mention what is the behavior of the server if HOST command is sent after 
one HOST has already been sent.  Eg.


C> HOST example.com
S> 220 Host OK
C> USER foo
S> 331 Specify password
C> PASS bar
S> 230 Logged in
C> HOST example.org
S> 

I suppose the server may treat this as REIN and then switching to 
specified host, if the user is authenticated, and just switch to such 
host if the user isn't already logged in.  Another option is sending 503 
reply, as invalid sequence of commands.


Thanks,
Mykyta Yevstifeyev

16.06.2011 16:05, The IESG wrote:

The IESG has received a request from the FTP Extensions, 2nd edition WG
(ftpext2) to consider the following document:
- 'File Transfer Protocol HOST Command for Virtual Hosts'
 as a Proposed Standard

[ . . . ]


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 12:36 PM, Murray S. Kucherawy wrote:

>> -Original Message-
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] 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?
>> 
>> 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.
> 
> 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.

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

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Andrew Sullivan]

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
a...@anvilwalrusden.com

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

[Douglas Otis]

On 6/23/11 8:24 AM, John Levine wrote:

In article<4e02ee24.2060...@gmail.com>  you write:

On 6/22/11 11:14 AM, Dave CROCKER wrote:

Folks,

The bottom line about Doug's note is that the working group extensively
considered the basic issue of multiple From: header fields and Doug is
raising nothing new about the topic.

Dave is quite right.  Doug's purported attack just describes one of
the endless ways that a string of bytes could be not quite a valid
5322 message, which might display in some mail programs in ways that
some people might consider misleading.  If it's a problem at all, it's
not a DKIM problem.
Perhaps you can explain why the motivation stated in RFC4686 includes 
anti-phishing as DKIM's goal?  Why of all the possible headers ONLY the 
From header field MUST be signed?  Why RFC5617 describes the From 
header field as the Author Author address that is positively confirmed 
simply with a Valid DKIM signature result?  Both RFC4686 and RFC5617 
overlooked a rather obvious threat clearly demonstrated by Hector Santos 
on the DKIM mailing list:  Pre-pended singleton header fields.


Neither SMTP nor DKIM check for an invalid number of singleton header 
fields. These few header fields are limited to one because they are 
commonly displayed.  Multiple occurrence of any of these headers is 
likely deceptive, especially in DKIM's case.  DKIM always selects header 
fields from the bottom-up, but most sorting and displaying functions go 
top-down selection.


Complaints from John, Dave, and Barry and others is likely and 
understandably out of fatigue.  They just want the process to be over.  
We are now hearing there is a vital protocol layering principle at stake 
which even precludes DKIM from making these checks!  Really?


Although DKIM will be securely hashing the headers fields which MUST 
include the From header,  developers are being told they must ignore 
multiple singleton header fields discovered in the process.  It is not 
their burden!  As if securely hashing, fetching any number of public 
keys, and verifying any number of signatures isn't?


-Doug


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

[Al Iverson]

On Fri, Jun 24, 2011 at 12:33 PM, Douglas Otis  wrote:
> On 6/23/11 8:24 AM, John Levine wrote:
>>
>> In article<4e02ee24.2060...@gmail.com>  you write:
>>>
>>> On 6/22/11 11:14 AM, Dave CROCKER wrote:

 Folks,

 The bottom line about Doug's note is that the working group extensively
 considered the basic issue of multiple From: header fields and Doug is
 raising nothing new about the topic.
>>
>> Dave is quite right.  Doug's purported attack just describes one of
>> the endless ways that a string of bytes could be not quite a valid
>> 5322 message, which might display in some mail programs in ways that
>> some people might consider misleading.  If it's a problem at all, it's
>> not a DKIM problem.
>
> Perhaps you can explain why the motivation stated in RFC4686 includes
> anti-phishing as DKIM's goal?  Why of all the possible headers ONLY the From
> header field MUST be signed?  Why RFC5617 describes the From header field as
> the Author Author address that is positively confirmed simply with a Valid
> DKIM signature result?  Both RFC4686 and RFC5617 overlooked a rather obvious
> threat clearly demonstrated by Hector Santos on the DKIM mailing list:
>  Pre-pended singleton header fields.
>
> Neither SMTP nor DKIM check for an invalid number of singleton header
> fields. These few header fields are limited to one because they are commonly
> displayed.  Multiple occurrence of any of these headers is likely deceptive,
> especially in DKIM's case.  DKIM always selects header fields from the
> bottom-up, but most sorting and displaying functions go top-down selection.
>
> Complaints from John, Dave, and Barry and others is likely and
> understandably out of fatigue.  They just want the process to be over.  We
> are now hearing there is a vital protocol layering principle at stake which
> even precludes DKIM from making these checks!  Really?

I'm not suffering from fatigue, personally, and I agree with their
negative reaction toward your commentary. You're speaking as though
you expect DKIM to be the *only* type of message validation that's
going to happen to a message and thus it must account for and handle
message flaws far outside of scope.

This is like complaining that four wheels don't work as a car. True,
but you're missing the point. And you're doing it in a manner so laden
with hyperbole as to be offensive. It's really distressing and
disrespecting to the rest of us to have to read your same complaint
over and over and over. You've made your point. Few (none?) seem to
agree. Could you please move on?

Regards,
Al Iverson
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Melinda Shore]

On 06/24/2011 06:46 AM, Donald Eastlake wrote:

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?


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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Donald Eastlake]

Hi Melinda,

On Fri, Jun 24, 2011 at 1:57 PM, Melinda Shore  wrote:
> On 06/24/2011 06:46 AM, Donald Eastlake wrote:
>>
>> 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?
>
> 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.

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.

> Melinda

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e...@gmail.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Nomcom 2011-2012: Second Call for Volunteers

[Suresh Krishnan]

This is the Second call for Volunteers for the 2011-12 Nomcom.  We are
just about halfway through the volunteer period so if you are considering
volunteering, please do so very soon.

We have had a very good response to the initial call for volunteers and
I am pleased to report that we have 50 volunteers thus far whose
qualifications have been confirmed by the secretariat. I have notified
each of these volunteers by email.

However, we would like to have many more volunteers. The more volunteers,
the better chance we have of choosing a random yet representative cross
section of the IETF population. You have until 11:59 pm EDT July 10, 2011
to volunteer for Nomcom but it would be much better if you can volunteer
as early as possible.

If you volunteered before 21:00 EDT on June 21 to serve as a voting member
and have not received a confirmation email from me, please re-submit and
bring to my attention right away!

Details about the process for volunteering for the Nomcom and the list
of open positions for which the nominating committee is responsible are
summarized in the initial announcement:

https://datatracker.ietf.org/ann/nomcom/2938/

The 50 volunteers who have thus far been qualified by the secretariat
are:

Alia Atlas , Juniper Networks
Lixia Zhang , UCLA
Wassim Haddad  , Ericsson
Glen Zorn , Network Zen
Richard Barnes , BBN Technologies
Stephen Kent , BBN Technologies
Scott Mansfield , Ericsson
Tina TSOU , FutureWei Technologies
Fernando Gont , UTN/FRH
Karen Seo , BBN Technologies
Jie Dong , Huawei Technologies
Mach Chen , Huawei Technologies Co.
Sheng Jiang , Huawei Technologies Co. Ltd.
Dimitri Papadimitriou , Alcatel-Lucent
Thomas D. Nadeau , CA Technologies
David Meyer , Cisco Systems/University of Oregon
Wesley George , Time Warner Cable
Cullen Jennings , Cisco
Stephen Hanna , Juniper Networks
Stephan Wenger , Bidyo
Keyur Patel , Cisco Systems
Michael Hamilton , BreakingPoint Systems
Behcet Sarikaya , Huawei USA
Mark Townsley , Cisco Systems
Fred Baker , Cisco Systems
Brian Trammell , ETH Zurich
Sam Hartman , Painless Security
Chris Griffiths , Comcast
George Michaelson , APNIC
Jiankang Yao , CNNIC
Sohel Khan , Comcast
Dacheng Zhang , Huawei
Lianshu Zheng , Huawei Technologies
Hui Deng , China Mobile
Gang Chen , China Mobile
Mirja Kuhlewind , University of Stuttgart
John E Drake , Juniper Networks
Matt Lepinski , BBN Technologies
Subir Das , Telcordia Technologies Inc
Yi Zhao , Huawei
John Scudder , Juniper Networks
Christer Holmberg , LM Ericsson
Teemu Savolainen , Nokia
Samita Chakrabarti , Ericsson
Jaap Akkerhuis , NLnet labs
Jason Weil , Time Warner Cable
Randy Bush , Internet Initiative Japan
Christian Schmidt , Nokia Siemens Networks
Sean Shen , CNNIC
Lou Berger , LabN Consulting

The primary activity for this nomcom will begin during IETF-81 in
Quebec City and should be completed by January 2012. The nomcom will
be collecting requirements from the community, as well as talking to
candidates and to community members about candidates. There will be
regularly scheduled conference calls to ensure progress. Thus, being a
nomcom member does require some time commitment.

Please volunteer by sending an email to me before
11:59 pm EDT July 10, 2011 as follows:

To: suresh.krish...@ericsson.com
Subject: Nomcom 2011-12 Volunteer

Please include the following information in the body of the mail:

Full Name:  // As you enter in the IETF Registration Form,
// First/Given name followed by Last/Family Name

Current Primary Affiliation: // typically what goes in the Company
 // field in the IETF Registration Form

Email Address(es): // all email addresses used to Register for the
   // past 5 IETF meetings
   // Please designate a Preferred email address for
   // contact if there is more than one email address

Telephone number:  // With country code (for confirmation if selected)

Please expect an email response from me within 3 business days stating
whether or not you are qualified.  If you do not receive a response in
this timeframe, please re-send your email with the tag "RESEND:" added
to the subject line.

If you are not yet sure you would like to volunteer, please consider
that Nomcom members play a very important role in shaping the
leadership of the IETF.  Ensuring the leadership of the IETF is fair
and balanced and comprised of those who can lead the IETF in the right
direction is an important responsibility that rests on the IETF
participants at large. Volunteering for the Nomcom is a good way of
contributing in that direction.

I will be publishing a more detailed target timetable, as well as
details of the randomness seeds to be used for the RFC 3797 selection
process within the next few days.

Thank you in advance for your participation.

Suresh Krishnan
Nomcom Chair 2011-2012
Email: nomcom-ch...@ietf.org, suresh.krish...@ericsson.com

___
IETF-Announce mai

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

[Martin Rex]

Donald Eastlake wrote:
> 
> 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?

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


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

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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Julian Reschke]

On 2011-06-24 20:27, Martin Rex wrote:

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


X-Archived-At?

Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RFC production center XML format usage, was: [IAOC] xml2rfc and legal services RFPs

[Julian Reschke]

On 2011-02-23 11:09, Julian Reschke wrote:

...
I just realized that I have an archive of XML versions of RFCs in AUTH48
state; so I *can* report the percentage of XML versions since ~RFC5000.

Note that these may be inaccurate (for instance, not all RFC numbers get
assigned, right?); it just observes how much XML files ended up in AUTH48.

Here are the numbers:

RFC5000 - RFC5099: 41
RFC5100 - RFC5199: 44
RFC5200 - RFC5299: 47
RFC5300 - RFC5399: 48
RFC5400 - RFC5499: 64
RFC5500 - RFC5599: 59
RFC5600 - RFC5699: 58
RFC5700 - RFC5799: 64
RFC5800 - RFC5899: 63
RFC5900 - RFC5999: 68
RFC6000 - RFC6099: 69
...


Updated stats, just in time before the next meeting:

RFC5000 - RFC5099: 41
RFC5100 - RFC5199: 44
RFC5200 - RFC5299: 47
RFC5300 - RFC5399: 48
RFC5400 - RFC5499: 64
RFC5500 - RFC5599: 59
RFC5600 - RFC5699: 58
RFC5700 - RFC5799: 64
RFC5800 - RFC5899: 63
RFC5900 - RFC5999: 68
RFC6000 - RFC6099: 70
RFC6100 - RFC6199: 56
RFC6200 - RFC6299: 77

...so a drop in 6100..6199 (I wonder why?) and a all-time high in 
6200..6299.


Best regards,

Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Noel Chiappa]

> From: Brian E Carpenter 

> I suspect that operators are *severely* under-represented on this
> list (ietf@ietf.org) because it is very noisy and operators have
> other priorities.

Ah, operators. This would be the same group of people of whom, if the
recent anecdotal reports are much to go on, many (most?) are not bothering
to deploy IPv6 at all?

(Something which would seem to be very common among smaller operators,
whom one assumes, in typical long-tail fashion, form the majority of the
group.)

But their views are paramount?

I see.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Martin Rex]

Julian Reschke wrote:
> 
> On 2011-06-24 20:27, Martin Rex wrote:
> > ...
> > 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.
> > ...
> 
> X-Archived-At?

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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Julian Reschke]

On 2011-06-24 20:55, Martin Rex wrote:

Julian Reschke wrote:


On 2011-06-24 20:27, Martin Rex wrote:

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


X-Archived-At?


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.


WFM.

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


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Donald Eastlake]

Hi Martin,

On Fri, Jun 24, 2011 at 2:27 PM, Martin Rex  wrote:
> Donald Eastlake wrote:
>>
>> 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?
>
> 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.

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

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

So it really depends on the circumstances.

>...
>
> -Martin

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e...@gmail.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Cameron Byrne]

On Fri, Jun 24, 2011 at 11:53 AM, Noel Chiappa  wrote:
>    > From: Brian E Carpenter 
>
>    > I suspect that operators are *severely* under-represented on this
>    > list (ietf@ietf.org) because it is very noisy and operators have
>    > other priorities.
>

Yes, and this thread is noise.  In fact, Noel comments are
specifically off-topic and should be a new thread which can get added
the old thread about 6to4.

> Ah, operators. This would be the same group of people of whom, if the
> recent anecdotal reports are much to go on, many (most?) are not bothering
> to deploy IPv6 at all?
>

Which operator is not actively working on IPv6 projects *right now*?
Seriously, that old statement does not hold water today.

> (Something which would seem to be very common among smaller operators,
> whom one assumes, in typical long-tail fashion, form the majority of the
> group.)
>
> But their views are paramount?
>
> I see.
>

Not taking the bait.  Let's move.

>        Noel
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 3:15 PM, Cameron Byrne wrote:

> Which operator is not actively working on IPv6 projects *right now*?
> Seriously, that old statement does not hold water today.

Perhaps you missed the "one data point" thread from a few days ago.  It appears 
that a great many ISPs aren't working on supporting IPv6 yet.

Seriously, the idea that we can wait for ISPs to deploy IPv6 the way they like 
it, before anyone actually uses it to a significant degree, is what doesn't 
hold water.  That kind of attitude will keep widespread deployment of IPv6 
perpetually 5-10 years away.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Doug Barton]

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



--On Friday, 24 June, 2011 13:34 +1200 Brian E Carpenter
  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.


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


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/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Doug Barton]

On 06/24/2011 04:35, 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 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

--

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/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

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

> On 06/24/2011 04:35, 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 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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[John Leslie]

Paul Hoffman  wrote:
> On Jun 24, 2011, at 5:55 AM, John Leslie wrote:
> 
>> 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.
> 
> 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.

--
John Leslie 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 4:17 PM, John Leslie wrote:

> Paul Hoffman  wrote:
>> On Jun 24, 2011, at 5:55 AM, John Leslie wrote:
>> 
>>> 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.
>> 
>> 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.
> 

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

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

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.

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

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.

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


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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Doug Barton]

On 06/24/2011 13:11, Keith Moore wrote:

On Jun 24, 2011, at 3:57 PM, Doug Barton 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,
yesterday" and those who would like to give it as graceful an exit as
possible.


Taken together, the message is confusing.


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



--

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/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Doug Barton]

On 06/24/2011 13:14, Keith Moore wrote:

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


On 06/24/2011 04:35, 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 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.


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

--

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/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

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

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

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[John C Klensin]

--On Friday, 24 June, 2011 12:57 -0700 Doug Barton
 wrote:

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

> By "your document" above are you referring to Brian's
> 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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[John C Klensin]

--On Friday, 24 June, 2011 16:17 -0400 John Leslie
 wrote:

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

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

[Dave CROCKER]

On 6/24/2011 10:33 AM, Douglas Otis wrote:

Complaints from John, Dave, and Barry and others is likely and understandably
out of fatigue. They just want the process to be over. We are now hearing there
is a vital protocol layering principle at stake which even precludes DKIM from
making these checks! Really?



For those who weren't paying attention, I thought it worth noting that Doug has 
now devolved into an ad hominem line of attack, complete with proffered insight 
into the personal motivations driving 3 of us, absent any external signs to 
support that insight.


My own, actual, view is that a number of us have been considerably more than 
thorough in responding to Doug's entirely misguided campaign, within the DKIM 
working group, here on the IETF list, at the TrendLabs blog, at Circleid, and at 
the MAAWG Technical committee mailing list.


The decision to stop responding to the substance of his postings is merely 
because there is no new substance.  Absent any indication of his view gaining 
support, there's very obviously no benefit to be had in responding further.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[james woodyatt]

On Jun 24, 2011, at 09:08 , John C Klensin wrote:
> 
> 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.

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 
member of technical staff, core os networking



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Joel Jaeggli]

On Jun 24, 2011, at 4:40 PM, Keith Moore wrote:

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

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.

> 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
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[james woodyatt]

On Jun 24, 2011, at 17:10 , Joel Jaeggli wrote:
> 
> 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.

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!


--
james woodyatt 
member of technical staff, core os networking



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Noel Chiappa]

> From: james woodyatt 

> I supported 6to4-advisory and strenuously argued against taking up
> 6to4-to-historic.
> ...
> I can see how 6to4-to-historic may divert its intended audience from
> reading the much more important 6to4-advisory draft

I must admit, it does seem a little odd to issue two documents, one fixing a
protocol that you're about to declare obsolete with the other...

> the [6to4-to-historic] draft is clearly written to specify something
> other than what its authors and most of the WG were intending.

I'm afraid that was a little too Delphic for me. I can understand if you'd
said something like 'its authors clearly wrote it to specify something other
than what most of the WG were intending' - but how can a document have an
intent that its authors know nothing of (which is how I read the above)?

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

Umm, is this a serious suggestion, or are you just having a little fun in a
second-cousin-to-trolling way?

I mean, this is _exactly_ the sort of consequence of moving 6to4 to
'historic' that I think a lot of the people who oppose that move are worried
about: that although they are still using it (because it works in their
circumstances, and provides capabilities that other things such as 6rd do
not), people will use the existence of 6to4-to-historic to move on and do
things which negatively impact the users' ability to move packets around.

You weren't by any chance trying to show an example of the downsides of
that decision, were you?

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Masataka Ohta]

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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Cullen Jennings]

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

On Jun 23, 2011, at 4:36 PM, Paul Hoffman wrote:

> Greetings again. The subject line is an honest question, not a gripe.
> 
> For those on the ietf@ mailing list, please see 
> . 
> 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
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Christian Huitema]

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


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard

[Mykyta Yevstifeyev]

24.06.2011 22:08, Robert McMurray wrote:

Thanks, Mykyta.

Section 3.3 already addresses that scenario in the second paragraph - and the 
server behaviors are exactly what you were suggesting:

As discussed in section 3 of this document, if a HOST command is sent
after a user has been authenticated the server SHOULD do one of the
following:

a.  Send a 503 reply for an invalid sequence of commands.

b.  Treat the HOST command as though a REIN command was sent and
reset the user-PI to the state that existed after the previous
HOST command was sent and before the user had been authenticated,
and then return the appropriate reply for the HOST command.
OK, and if HOST is sent for the second time when the user hasn't got 
authenticated, eg.


S> 220 Server ready
C> HOST example.com
S> 220 HOST OK
C> HOST example.org
S> ???

I suppose it may be 503 reply or switching to the identified host with 
220 reply.  This situation isn't mentioned in your document.


Mykyta Yevstifeyev

Thanks again!

Robert McMurray

-Original Message-
From: Mykyta Yevstifeyev [mailto:evniki...@gmail.com]
Sent: Friday, June 24, 2011 9:53 AM
To: ietf@ietf.org; ftp...@ietf.org
Subject: Re: [ftpext] Last Call:  (File 
Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard

Hello,

This document is well written; I'm strongly for its publication on Standards 
Track.  I have an only remark.  This document doesn't seem to mention what is 
the behavior of the server if HOST command is sent after one HOST has already 
been sent.  Eg.

C>  HOST example.com
S>  220 Host OK
C>  USER foo
S>  331 Specify password
C>  PASS bar
S>  230 Logged in
C>  HOST example.org
S>  

I suppose the server may treat this as REIN and then switching to specified 
host, if the user is authenticated, and just switch to such host if the user 
isn't already logged in.  Another option is sending 503 reply, as invalid 
sequence of commands.

Thanks,
Mykyta Yevstifeyev





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

On Jun 24, 2011, at 8:10 PM, Joel Jaeggli wrote:

> On Jun 24, 2011, at 4:40 PM, Keith Moore wrote:
> 
>> 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. 
> 
> 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.

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf