Commenting on one issue from John's email from Sat 10/30/2010 4:18am
(and ignoring the issue of what John was doing up at 4am):
However, a change to the handling of documents that are
candidates for Proposed Standard is ultimately in the hands of
the IESG. In principle, they could announce
--On Thursday, 04 November, 2010 05:50 -0400 Ross Callon
rcal...@juniper.net wrote:
Commenting on one issue from John's email from Sat 10/30/2010
4:18am (and ignoring the issue of what John was doing up at
4am):
:-)
However, a change to the handling of documents that are
candidates for
I don't see proceeding by small, incremental changes to be a
problem. Indeed, I usually consider it an advantage as long as
there is reasonable confidence that the changes that are made
won't foreclose real solutions later...
This is my understanding of what is proposed.
...That risk can
- Original Message -
From: Keith Moore mo...@network-heretics.com
To: Yoav Nir y...@checkpoint.com
Cc: ietf@ietf.org
Sent: Thursday, October 28, 2010 3:57 AM
Subject: Re: what is the problem bis
On Oct 27, 2010, at 8:58 AM, Yoav Nir wrote:
This comes back to the question
--On Friday, October 29, 2010 12:20 -0400 Hadriel Kaplan
hkap...@acmepacket.com wrote:
On Oct 27, 2010, at 9:57 PM, Keith Moore wrote:
That's why I think we need a different set of labels, e.g.
Protocol-Quality. We need a statement about the perceived
quality of the protocol
On Sat, Oct 30, 2010 at 1:17 AM, John C Klensin john-i...@jck.com wrote:
snip
However, a change to the handling of documents that are
candidates for Proposed Standard is ultimately in the hands of
the IESG. In principle, they could announce tomorrow that any
document submitted for processing
On Sat, Oct 30, 2010 at 8:16 AM, Hadriel Kaplan hkap...@acmepacket.com wrote:
So is your expectation that if Russ's draft gets published, the bar for PS
will suddenly drop?
If so, why do we need Russ's draft to begin with? We already have rfc2026.
Why would a new RFC which says follow
Ted Hardie ted.i...@gmail.com wrote:
When I re-write the advance mechanics draft, I will propose something
along the following lines:
1) A WG snapshot-like status achieved after agreement by the working
group and a posting by the WG chair to IETF-announce notifying the
wider
Keith Moore [mailto://mo...@network-heretics.com] writes:
On Oct 29, 2010, at 12:36 PM, Michael Richardson wrote:
In-person meeting time is used regularly for powerpoints rather than
discussion.
+1.
The single biggest thing that IETF could do to raise productivity in
meetings is to
Ted,
I agree with almost everything you say, but want to focus on one
issue (inline below).
--On Friday, October 29, 2010 16:15 -0700 Ted Hardie
ted.i...@gmail.com wrote:
...
As we stare down this rathole one more time, let's at least be
certain that there is more than one rat down there,
On Oct 30, 2010, at 4:01 AM, Glen Zorn wrote:
The second biggest thing that IETF could do to raise productivity in
meetings is to ban Internet use in meetings except for the purpose of
remote participation.
Harder to do not clearly an improvement: it clear out meeting rooms a bit,
but on
This discussion has a periodicy about 6 months. The premise is asinine, we
can't go back to the early to mid 90s.
Joel's widget number 2
On Oct 30, 2010, at 7:34, Keith Moore mo...@network-heretics.com wrote:
On Oct 30, 2010, at 4:01 AM, Glen Zorn wrote:
The second biggest thing that IETF
I don't think it's resistance to changing a process that we are not following
- I think it's which part of the process we think isn't working, or which part
is IMPORTANT that isn't working.
Going from three steps of which only one step is used, to two steps of which
only one step will be
Hi Ted,
I was with your statements all the way to this:
Russ's draft tries to
do two things:
Restore the 2026 rules for Proposed as the functionally in-use bar for the
first rung.
...
What makes you say that?
I read the draft and I don't see it doing that, really. I know it says:
The
On Oct 30, 2010, at 10:01 AM, Glen Zorn wrote:
The second biggest thing that IETF could do to raise productivity in
meetings is to ban Internet use in meetings except for the purpose of
remote participation.
Harder to do not clearly an improvement: it clear out meeting rooms a bit,
but
This discussion has a periodicy about 6 months. The premise is asinine, we
can't go back to the early to mid 90s.
What's asinine is to dismiss out-of-hand something has worked well in the past.
The only reason we can't change the way we have discussions is that too many
people are in the
On Oct 30, 2010, at 12:38 PM, Joel Jaeggli wrote:
the final arbiter of any test in the room is on the mailing list.
True. But a room with a high ratio of active participants to total attendees
makes a much better sounding board for providing constructive feedback, than a
room with a low
To: Yoav Nir y...@checkpoint.com
Cc: ietf@ietf.org
Sent: Thursday, October 28, 2010 3:57 AM
Subject: Re: what is the problem bis
On Oct 27, 2010, at 8:58 AM, Yoav Nir wrote:
This comes back to the question or why have maturity levels at all. Ideally,
an implementer should prefer to implement
On Oct 27, 2010, at 9:57 PM, Keith Moore wrote:
That's why I think we need a different set of labels, e.g.
Protocol-Quality. We need a statement about the perceived quality of the
protocol described in the document. (Is this protocol well-designed for the
anticipated use cases, or does it
On Oct 29, 2010, at 12:36 PM, Michael Richardson wrote:
In-person meeting time is used regularly for powerpoints rather than
discussion.
+1.
The single biggest thing that IETF could do to raise productivity in meetings
is to remove video projectors from meeting rooms, replace them with
It kind of seems like we're thinking of this in a 20th-century,
politburo sort of way. We, the illumnati, will decide whether this
document is awesome. Could we not just use RFC as a basic threshold
of quality, then let the community provide open and ongoing feedback?
Like, with voting
On Oct 29, 2010, at 2:37 PM, Keith Moore wrote:
On Oct 29, 2010, at 12:36 PM, Michael Richardson wrote:
In-person meeting time is used regularly for powerpoints rather than
discussion.
I've been yelled-at in WG meetings for using the microphone meeting time for
discussion, vs. position
The single biggest thing that IETF could do to raise productivity
in meetings is to remove video projectors from meeting rooms,
replace them with white boards and pens, and ban use of PowerPoint
and similar tools.
It's hard to get remote participants to see physical whiteboards,
nor to
On 10/29/2010 1:14 PM, Richard L. Barnes wrote:
Advance availability of slides can also be helpful for the growing fraction of
participants for whom English is not a native language.
+1
Also, the style of the slides makes a difference.
I was originally taught to produce very cryptic
On Oct 29, 2010, at 4:05 PM, John C Klensin wrote:
--On Friday, October 29, 2010 12:20 -0400 Hadriel Kaplan
hkap...@acmepacket.com wrote:
On Oct 27, 2010, at 9:57 PM, Keith Moore wrote:
That's why I think we need a different set of labels, e.g.
Protocol-Quality. We need a
On Oct 29, 2010, at 4:14 PM, Richard L. Barnes wrote:
The single biggest thing that IETF could do to raise productivity in
meetings is to remove video projectors from meeting rooms, replace them
with white boards and pens, and ban use of PowerPoint and similar tools.
It's hard to get
: Re: what is the problem bis
On Oct 27, 2010, at 8:58 AM, Yoav Nir wrote:
This comes back to the question or why have maturity levels at all.
Ideally,
an implementer should prefer to implement a mature standard over a
less-mature
one. In practice, adopting the more advanced standard may
As is moderately obvious from the stream of commentary on this
thread and there companions, there is no *one* problem at
the root of all this. One way to draw this is:
Issue: Documents are too slow in achieving the first rung of the
standards process
Contributing issues:
-WG formation
Hi -
From: Ted Hardie ted.i...@gmail.com
To: IETF ietf@ietf.org
Sent: Friday, October 29, 2010 4:15 PM
Subject: No single problem... (was Re: what is the problem bis)
...
As is moderately obvious from the stream of commentary on this
thread and there companions, there is no *one* problem
Sent: Friday, October 29, 2010 4:15 PM
Subject: No single problem... (was Re: what is the problem bis)
...
As is moderately obvious from the stream of commentary on this
thread and there companions, there is no *one* problem at
the root of all this. One way to draw this is:
...
I wonder
On 10/29/10 5:24 PM, Phillip Hallam-Baker wrote:
So why is there so much resistance to changing a process that we are not
following?
I think there's a sentimental attachment to it. That said,
I suppose if I were in your position I'd be asking myself
why I'm still whacking away at the same
Consensus can be achieved in two ways
The first is that everyone understands the issues in the same way and are
agreed on a common approach.
The second is that people would prefer not to face unfortunate facts and so
they agree to ignore them and get the squeaky wheels to shut up.
Now we could
That the labels can be updated is a good thing, but you would have to start
with something.
People are complaining about the length of time it takes to get anything
published. Adding these extra steps of protocol quality review,
applicability review etc. will only make that process even
On Oct 28, 2010, at 5:05 AM, Yoav Nir wrote:
That the labels can be updated is a good thing, but you would have to start
with something.
People are complaining about the length of time it takes to get anything
published. Adding these extra steps of protocol quality review,
On Tue, Oct 26, 2010 at 03:24:55PM -0400, Phillip Hallam-Baker wrote:
The problem with the current, failed process is that there is absolutely no
correlation between the standards status of a protocol and adoption.
Why exactly is that a problem? That's not a rhetorical question. If
_that_ is
, it already is)
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Andrew
Sullivan
Sent: 27 October 2010 13:47
To: ietf@ietf.org
Subject: Re: what is the problem bis
On Tue, Oct 26, 2010 at 03:24:55PM -0400, Phillip Hallam-Baker wrote:
The problem
At 2:58 PM +0200 10/27/10, Yoav Nir wrote:
So in answering you second question, I don't see any reason why things won't
keep sticking in PS or even Experimental forever.
Here's a reason, and possibly the strongest one: author pride. If I wrote a
protocol that I was proud of and I had a
Actually, my heartache with Russ' proposal is the automatic If it's Draft,
it's now Standard.
I would be quite happy with Proposed and Internet Standard, with NO
grandfathering.
On Oct 26, 2010, at 5:57 PM, Ofer Inbar wrote:
On Oct 26, 2010, at 2:39 PM, Dave CROCKER wrote:
I'm a fan of
On Oct 27, 2010, at 8:58 AM, Yoav Nir wrote:
This comes back to the question or why have maturity levels at all. Ideally,
an implementer should prefer to implement a mature standard over a
less-mature one. In practice, adopting the more advanced standard may give
you an obsolete protocol,
while we are the topic of problems
Russ basically proposes too change the maturity warning label on IETF
standard track RFCs -- remove baby before folding carriage -- this
hardly seems like our biggest problem
The IETF publishes a lot of standards track RFCs each year. Mostly
these are PS (186
On Oct 26, 2010, at 12:08 PM, Scott O. Bradner wrote:
while we are the topic of problems
Russ basically proposes too change the maturity warning label on IETF
standard track RFCs -- remove baby before folding carriage -- this
hardly seems like our biggest problem
The IETF publishes a
: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Scott
O. Bradner
Sent: Tuesday, October 26, 2010 12:09 PM
To: ietf@ietf.org
Subject: what is the problem bis
while we are the topic of problems
Russ basically proposes too change the maturity warning label on IETF
standard track RFCs
Ross,
On 10/26/10 6:32 PM, Ross Callon wrote:
The downside of Russ's draft is that it is possible that after approving it
we might find that nothing changes: Protocol specifications still stay at
Proposed Standard; The IESG still takes a lot of time in approving a request
to publish a
On 10/26/2010 9:13 AM, Marshall Eubanks wrote:
Would the first step be to try and get some statistics, to see how many of
those ~ 200
standards fall into class 1-6 ?
Sure would be nice to have a place for noting the basic data.
What if someone created a wiki... [1]
d/
[1]
On 10/26/2010 9:32 AM, Ross Callon wrote:
There are two problems that Russ's draft may very well solve: One issue with
our current system is that there is no incentive to go from Proposed Standard
to Draft Standard (since you are only going from one intermediate state
short of full standard to
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave
CROCKER
Sent: Tuesday, October 26, 2010 1:55 PM
To: ietf@ietf.org
Subject: Re: what is the problem bis
On 10/26/2010 9:32 AM, Ross Callon wrote:
There are two problems that Russ's draft may very well
On 10/26/2010 11:27 AM, Ross Callon wrote:
What is
taking attention away from discussion of the actual barriers is the lengthy
debate about Russ's proposed change.
Here's where the term 'opportunity cost' applies:
Taking action that does not achieve what is desired consumes energy
--On Tuesday, October 26, 2010 10:54 -0700 Dave CROCKER
d...@dcrocker.net wrote:
On 10/26/2010 9:32 AM, Ross Callon wrote:
There are two problems that Russ's draft may very well solve:
One issue with our current system is that there is no
incentive to go from Proposed Standard to Draft
The problem with the current, failed process is that there is absolutely no
correlation between the standards status of a protocol and adoption.
Most of the documents to reach STANDARD status in recent years have been
SNMP documents. But even though SNMP has its uses, deployment and use hardly
--On Tuesday, October 26, 2010 14:27 -0400 Ross Callon
rcal...@juniper.net wrote:
This is where I disagree with you. The simple change that Russ
has proposed is not what is taking away from discussion of the
actual barriers. What is taking attention away from discussion
of the actual
On Oct 26, 2010, at 12:08 PM, Scott O. Bradner wrote:
Seems to me that the issue of how the IETF can be better at producing
just what the community needs just when the community needs it is more
important than maturity warning labels.
agreed, though we should be careful to not confuse what
On Oct 26, 2010, at 2:39 PM, Dave CROCKER wrote:
I'm a fan of reducing down to 2 levels, too. But it has nothing to do with
how
overblown the effort to get to Proposed is. (Well, there's some pretty
simple
psych logic that says that it could actually make the barrier to Proposed
On Oct 26, 2010, at 12:32 PM, Ross Callon wrote:
I don't think that anyone is claiming that the two-maturity-levels draft
solves every problem. This draft should not discourage you or anyone else
from offering additional proposals to solve the problems that you are
mentioning in your email
On Oct 26, 2010, at 1:54 PM, Dave CROCKER wrote:
Working groups take too long. The IESG often takes too long and ADs often
raise unexpected and possibly even arbitrary barriers. We have moved to an
enormously heavyweight model. Timeliness is almost never a factor.
Nothing gets better
On Oct 26, 2010, at 2:27 PM, Ross Callon wrote:
In my opinion the fact that this very simple and straightforward change draws
such heavy debate is a disincentive to anyone who would propose other
additional changes.
Often the reason that simple and straightforward changes draw such heavy
Hi -
From: Phillip Hallam-Baker hal...@gmail.com
To: Scott O. Bradner s...@harvard.edu
Cc: ietf@ietf.org
Sent: Tuesday, October 26, 2010 12:24 PM
Subject: Re: what is the problem bis
...
Most of the documents to reach STANDARD status in recent years have been
SNMP documents. But even
On Oct 26, 2010, at 2:39 PM, Dave CROCKER wrote:
I'm a fan of reducing down to 2 levels, too. But it has nothing to
do with how overblown the effort to get to Proposed is. (Well,
I feel like we already have a 2-level system.
What's the practical difference between Proposed and full Standard?
Eliot == Eliot Lear l...@cisco.com writes:
The downside of Russ's draft is that it is possible that after
approving it we might find that nothing changes: Protocol
specifications still stay at Proposed Standard; The IESG still
takes a lot of time in approving a request to
For which Working Groups does the current system work?
It is completely failing for every one that I have been involved in. The
distinction between DRAFT standard and Internet STANDARD seems completely
arbitrary as far as I can see.
We might as well replace the final step of the process with
59 matches
Mail list logo
