Just as a follow-up here ...
I was John's co-author on RFC 3933 (http://tools.ietf.org/html/rfc3933).
When we were working on the draft, the problem I thought we were
solving, was that the IESG needs to update the IETF's BCP processes from
time to time, but (1) it was like 32 simultaneous
I agree with your approach. However, if it should be tested by
community and reported successful then why we need to go through 5
years, just publish fast ways,
AB
Sun, 27 Jan 2013 20:27:17 -0800
If this is an experiment, then you presumably answers to the following
questions:
I agree with your concerns and may suggest that the tests' results of
the running code SHOULD be reported inside a mandatory section of the
Fast-Tracked I-D to RFC.
AB
On 01/26/2013 Martin Rex wrote:
Stephen Farrell wrote:
On 01/25/2013 09:36 PM, Martin Rex wrote:
I don't know about the
Hello,
Sorry I missed your last paragraph in the snow storm.
So, Adrian, noting the ratio between discussion of this draft on
the IETF list in the last few weeks and discussions of
everything else, how long does professional courtesy to another
IESG member (presumably in combination with
Thomas said:
The crux of the issue is that any attempt at fast tracking is
fundamentally about short-circuiting some aspect of our review
processes.
Speaking as a Gen-ART reviewer, I am indeed worried by this aspect.
I feel I would have to spend much longer reviewing a draft if I
knew it had
On 1/22/13 10:31 PM, Thomas Narten wrote:
a WG can
skip WG LC if they think its not needed.
???
When was the last time that happened? Did it require a consensus call
to determine?
Eliot
--On Friday, January 25, 2013 14:36 +0100 Eliot Lear
l...@cisco.com wrote:
On 1/22/13 10:31 PM, Thomas Narten wrote:
a WG can
skip WG LC if they think its not needed.
???
When was the last time that happened? Did it require a
consensus call to determine?
Chair discretion. It is
John,
On 1/25/13 4:27 PM, John C Klensin wrote:
a WG can
skip WG LC if they think its not needed.
???
When was the last time that happened? Did it require a
consensus call to determine?
Chair discretion [... and five of paragraphs of text]
None of which answered my above questions. When
On 01/25/2013 03:27 PM, John C Klensin wrote:
In the context of draft-farrell-ft, the above makes the idea of
WG LC in parallel with IETF LC either irrelevant or bad news.
If the WG Chair (or AD) concludes that a WG LC is needed, then
the procedure should not be invoked. If a WG LC is not
--On Friday, January 25, 2013 16:31 +0100 Eliot Lear
l...@cisco.com wrote:
John,
On 1/25/13 4:27 PM, John C Klensin wrote:
a WG can
skip WG LC if they think its not needed.
???
When was the last time that happened? Did it require a
consensus call to determine?
Chair discretion [...
--On Friday, January 25, 2013 15:34 + Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
...
All of this points out one of my main concerns. Almost as a
side-effect, the proposal formalizes a number of informal
procedures and mechanisms work pretty well most of the time
but, because they
Hiya,
On 01/25/2013 04:37 PM, John C Klensin wrote:
If I correctly understand the above, it lies at the root of the
problem I was trying to describe. This is really an experiment
if the effect of deciding we didn't want to make it permanent
was that we were at status quo ante, i.e., as if
Eliot Lear wrote:
On 1/25/13 4:27 PM, John C Klensin wrote:
a WG can skip WG LC if they think its not needed.
When was the last time that happened?
Did it require a consensus call to determine?
Chair discretion [... and five of paragraphs of text]
None of which answered my above
Hi Martin,
On 01/25/2013 09:36 PM, Martin Rex wrote:
I don't know about the last time it happened, but I know about
one time in Nov-2009 in the TLS WG (now rfc5746).
I recall that and agree with the sequence of events you
describe, but I'm not sure that that situation is
relevant when
Stephen Farrell wrote:
On 01/25/2013 09:36 PM, Martin Rex wrote:
I don't know about the last time it happened, but I know about
one time in Nov-2009 in the TLS WG (now rfc5746).
I recall that and agree with the sequence of events you
describe, but I'm not sure that that situation is
--On Tuesday, January 22, 2013 16:31 -0500 Thomas Narten
nar...@us.ibm.com wrote:
FWIW, I share Joe's concerns. And Stephen's responses don't
really change my mind.
This document seems to have a bit of missing the forest for the
trees. In the overall scheme of things, I don't believe the
I do not really have time or desire to enter an extended discussion on
this document. It's pretty clear to me we just disagree. But I did
want to be on record as not supporting this document so that silence
wouldn't be taken as agreement or support.
A few specific followups below.
This
Hi, all,
On 1/11/2013 8:21 AM, Adrian Farrel wrote:
Hi Alexa,
Please be aware of this document that has just entered a four-week IETF last
call. The document describes a proposed IETF process experiment under the rules
of RFC 3933.
The proposed experiment calls on the IETF Secretariat to take
Hi Joe,
On 01/22/2013 04:39 PM, Joe Touch wrote:
Hi, all,
On 1/11/2013 8:21 AM, Adrian Farrel wrote:
Hi Alexa,
Please be aware of this document that has just entered a four-week
IETF last
call. The document describes a proposed IETF process experiment under
the rules
of RFC 3933.
On 1/22/2013 9:00 AM, Stephen Farrell wrote:
Hi Joe,
On 01/22/2013 04:39 PM, Joe Touch wrote:
...
This is a silly idea.
So you're in two minds about it eh:-)
First, running code should already be considered as part of the context
of review.
Second, running code is not correlated to
On 01/22/2013 05:14 PM, Joe Touch wrote:
On 1/22/2013 9:00 AM, Stephen Farrell wrote:
Hi Joe,
On 01/22/2013 04:39 PM, Joe Touch wrote:
...
This is a silly idea.
So you're in two minds about it eh:-)
First, running code should already be considered as part of the context
of
Joe Touch to...@isi.edu wrote:
On 1/11/2013 8:21 AM, Adrian Farrel wrote:
The proposed experiment calls on the IETF Secretariat to take specific
actions under certain circumstances in corner cases of the experiment.
Specifically:
]
] 8. If at any point in the fast-track process the
FWIW, I share Joe's concerns. And Stephen's responses don't really
change my mind.
This document seems to have a bit of missing the forest for the
trees. In the overall scheme of things, I don't believe the draft will
materially help, and is at best a distraction from dealing with
meaningful
Hiya,
On 01/22/2013 05:14 PM, Joe Touch wrote:
It puts more work on the community at large to review an idea that could
have been either rejected or significantly improved in a smaller
community before wasting the larger communities time.
Actually it occurs to me that there might be
Hi Thomas,
On 01/22/2013 09:31 PM, Thomas Narten wrote:
FWIW, I share Joe's concerns. And Stephen's responses don't really
change my mind.
Ah well. I'm willing to keep trying:-)
This document seems to have a bit of missing the forest for the
trees. In the overall scheme of things, I don't
Hi John,
Bits and pieces below...
On 01/22/2013 07:04 PM, John Leslie wrote:
Joe Touch to...@isi.edu wrote:
On 1/11/2013 8:21 AM, Adrian Farrel wrote:
The proposed experiment calls on the IETF Secretariat to take specific
actions under certain circumstances in corner cases of the
I have two concerns and comments:
- How will success or failure be measured? Number of appeal increases
or lesser amount? I have a concern that once this door is open, there
will be increase appeals and also apathy of outcomes. There should be
a statement of what sort of problems or issues
Hi Hector,
On 01/14/2013 05:05 PM, Hector Santos wrote:
I have two concerns and comments:
- How will success or failure be measured? Number of appeal increases
or lesser amount? I have a concern that once this door is open, there
will be increase appeals and also apathy of outcomes.
Hi Alexa,
Please be aware of this document that has just entered a four-week IETF last
call. The document describes a proposed IETF process experiment under the rules
of RFC 3933.
The proposed experiment calls on the IETF Secretariat to take specific actions
under certain circumstances in corner
29 matches
Mail list logo
