> 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
--On Thursday, 04 November, 2010 05:50 -0400 Ross Callon
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 Proposed Sta
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 Mon, 2010-11-01, John Leslie wrote:
> Ted Hardie wrote:
>> 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 community and inviting review (presumably by review teams).
>>Any document m
Ted Hardie 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 community and invit
On Sat, Oct 30, 2010 at 8:16 AM, Hadriel Kaplan 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 this other RFC" be
On Sat, Oct 30, 2010 at 1:17 AM, John C Klensin wrote:
> 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 after IETF 79 woul
t; > suggestions, something a good chair or AD would stamp on, and IESG process,
> > where certain hot buttons - eg security, flow control - produce some
> > ludicrous
> > DISCUSS' which delay the process for months.
> > Tom Petch
> >
> > - Original Message
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 rati
> 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 10/30/10 9:25 AM, Yoav Nir wrote:
>
> 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
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
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
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 use
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 wrote:
> On Oct 30, 2010, at 4:01 AM, Glen Zorn wrote:
>
>>> The second biggest thing that IETF could do to raise pro
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,
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
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, and be
> realistic
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
> meeting
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
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 stuf
uot;IETF"
> > 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
> > th
Hi -
> From: "Ted Hardie"
> To: "IETF"
> 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
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
suggestions, something a good chair or AD would stamp on, and IESG process,
> where certain hot buttons - eg security, flow control - produce some
> ludicrous
> DISCUSS' which delay the process for months.
> Tom Petch
>
> - Original Message -----
> From: "Keith Mo
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 har
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 slides
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 vi
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. pos
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
> "t" == t petch writes:
t> By contrast, the delays in producing an RFC seem to revolve
t> around WG process, where Last Call causes people to come out of
t> the woodwork with delaying suggestions, something a good chair or
t> AD would stamp on, and IESG process, where certain
quot;Yoav Nir"
Cc:
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 a mature standard ov
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",
> "app
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 lon
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 protoc
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
> 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
ee maturity levels, except
that Experimental will be the bottom rung (on second though, 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
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
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 thro
> "Eliot" == Eliot Lear 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 pub
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
Hi -
> From: "Phillip Hallam-Baker"
> To: "Scott O. Bradner"
> Cc:
> 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
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 he
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 bett
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 em
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: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 Tuesday, October 26, 2010 14:27 -0400 Ross Callon
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 barriers is the length
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
com
--On Tuesday, October 26, 2010 10:54 -0700 Dave CROCKER
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 Standard
>> (si
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 and
s
-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'
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 t
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] http://trac.to
On 10/26/2010 9:08 AM, Scott O. Bradner wrote:
while we are the topic of problems
No Scott the problem is that the IETF is not a lobbyist organization and
your blocking the standardization of anything based on whether the
Internet "needs it or not" makes your IETF the controller of what gets
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 p
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 below.
There are two problems that Russ's draft may
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 publishe
58 matches
Mail list logo