On 05/16/2013 01:44 AM, John C Klensin wrote:
--On Thursday, May 16, 2013 00:55 -0400 Keith Moore
mo...@network-heretics.com wrote:
Which is to say, if there is only a single AD blocking a
document, that block is essentially a 2 week affair if you
are willing to push the point. No need for
On 05/15/2013 12:25 PM, Thomas Narten wrote:
I don't think the IETF needs to be in the profile/resume
business. There are plenty of other places that do a fine job already.
What I do think the IETF should do is *require* that participants
identify themselves. That means knowing who they are (a
I must say that I have enjoyed reading the discussion between the three of you,
and think it is immensely valuable in explaining what the IESG ought to be
doing. You three should write it up.
From: Thomas Narten nar...@us.ibm.com
What I do think the IETF should do is *require* that participants
identify themselves. That means knowing who they are (a name and email
contact) and an affiliation. For 80% of the participants, this info is
not very hard to figure out (see below). But
I feel that the discussion is stuck on the different perceptions on whether an
AD's actions are either blocking reasonable progress, or an essential
correction to a mistake that went undetected.
I'd like to make a couple of observations. First of all, we at the IESG process
10-25 documents
On 5/14/2013 5:53 PM, Ted Lemon wrote:
On May 14, 2013, at 8:27 PM, Joe Touch to...@isi.edu wrote:
That is what happens exactly because the DISCUSS holds up the
document, and most ADs don't want to burn time stalling their documents
if there's a way around that delay.
It can only happen if
On 5/14/2013 4:57 PM, Joel M. Halpern wrote:
And your bottom line is exactly what te rules say, what I said, what Ted
said, and what Joe agreed is reasonable.
Unfortunately, it's not what happens/is happening right now.
Joe
On 5/14/2013 4:03 PM, Ted Lemon wrote:
The whole point of a DISCUSS is to have a discussion.
The *whole* point of a DISCUSS is to hold a document in IETF review
until a discussion is *resolved*.
There are thus three parts:
- having a discussion
- pausing the document
On 5/14/2013 9:54 PM, Keith Moore wrote:
Publishing broken or unclear documents is not progress.
Keith
Broken, agreed.
Unclear, nope - please review the NON-DISCUSS criteria, notably:
The motivation for a particular feature of a protocol is not clear
enough. At the IESG review stage,
On 05/15/2013 10:39 AM, Joe Touch wrote:
On 5/14/2013 9:54 PM, Keith Moore wrote:
Publishing broken or unclear documents is not progress.
Keith
Broken, agreed.
Unclear, nope - please review the NON-DISCUSS criteria, notably:
The motivation for a particular feature of a protocol is not
On 5/14/2013 10:05 PM, Keith Moore wrote:
...
For that matter, working groups are too often echo chambers where a set
of people manage to isolate themselves from input from those whose work
they might otherwise effect.Some people seem to think that working
group output should be
On May 15, 2013, at 10:39 AM 5/15/13, Joe Touch to...@isi.edu wrote:
On 5/14/2013 9:54 PM, Keith Moore wrote:
Publishing broken or unclear documents is not progress.
Keith
Broken, agreed.
Unclear, nope - please review the NON-DISCUSS criteria, notably:
The motivation for a
On May 15, 2013, at 10:41 AM, Keith Moore mo...@network-heretics.com wrote:
The motivation for a particular feature of a protocol is not clear enough.
At the IESG review stage, protocols should not be blocked because they
provide capabilities beyond what seems necessary to acquit their
IMO, IESG should have grounds to reject any document that isn't specifically
authorized in a WG's charter.
- Keith
On May 15, 2013, at 10:55 AM, Ted Lemon ted.le...@nominum.com wrote:
On May 15, 2013, at 10:41 AM, Keith Moore mo...@network-heretics.com wrote:
The motivation for a particular
Joe,
Broken, agreed.
Yep.
Unclear, nope - please review the NON-DISCUSS criteria, notably:
The motivation for a particular feature of a protocol is not clear enough. At
the IESG review stage, protocols should not be blocked because they provide
capabilities beyond what seems necessary
Hi,
The evidence seems to show that the IESG is getting faster
at their job and WGs are getting slower at theirs. I don't
see any need for DISCUSS Rules. All the AD reviews I've
experienced have improved the document, sometimes a lot.
All DISCUSS issues got cleared with reasonable (even good)
On May 15, 2013, at 6:06 PM, Keith Moore mo...@network-heretics.com
wrote:
IMO, IESG should have grounds to reject any document that isn't specifically
authorized in a WG's charter.
- Keith
Why? There's definitely a process failure there, and it should be blamed on the
WG chairs
+1 to what Jari says below.
From my perspective, the important things to keep in mind:
1) Discuss criteria should be principles, not rigid rules. The details
of the issue at hand always matter, and it will sometimes come down to
judgement calls where reasonable individuals just might disagree.
I don't think the IETF needs to be in the profile/resume
business. There are plenty of other places that do a fine job already.
What I do think the IETF should do is *require* that participants
identify themselves. That means knowing who they are (a name and email
contact) and an affiliation. For
On 5/15/2013 7:55 AM, Ted Lemon wrote:
On May 15, 2013, at 10:41 AM, Keith Moore mo...@network-heretics.com wrote:
The motivation for a particular feature of a protocol is not
clearenough. At the IESG review stage, protocols should not be blocked
because they provide capabilities beyond what
On May 15, 2013, at 12:36 PM, Joe Touch to...@isi.edu wrote:
I'm impressed that you have such a specific interpretation that this
criteria refers to the entire document, even when it talks about the
feature of a protocol.
The motivation for a feature of a protocol is not clear enough. What's
On 5/15/2013 10:15 AM, Ted Lemon wrote:
On May 15, 2013, at 12:36 PM, Joe Touch to...@isi.edu wrote:
I'm impressed that you have such a specific interpretation that this
criteria refers to the entire document, even when it talks about the
feature of a protocol.
The motivation for a feature
At 08:06 15-05-2013, Keith Moore wrote:
IMO, IESG should have grounds to reject any document that isn't
specifically authorized in a WG's charter.
I read a few charters:
core:
Dec 2099 - HOLD (date TBD) Constrained security bootstrapping specification
submitted to IESG
ancp:
On May 15, 2013, at 1:23 PM, Joe Touch to...@isi.edu wrote:
You don't agree that the motivation for the difference between using 16-bit
vs. 32-bit ExIDs is sufficient, even though that is already discussed in the
document.
I don't think this is a topic that the IETF as a whole is likely to
--On Wednesday, May 15, 2013 18:25 +0200 Thomas Narten
nar...@us.ibm.com wrote:
I don't think the IETF needs to be in the profile/resume
business. There are plenty of other places that do a fine job
already.
What I do think the IETF should do is *require* that
participants identify
On 5/15/2013 11:08 AM, Ted Lemon wrote:
On May 15, 2013, at 1:23 PM, Joe Touch to...@isi.edu wrote:
You don't agree that the motivation for the difference between using 16-bit vs.
32-bit ExIDs is sufficient, even though that is already discussed in the
document.
I don't think this is a
On 05/15/2013 02:48 PM, Joe Touch wrote:
On 5/15/2013 11:08 AM, Ted Lemon wrote:
I don't think this is a topic that the IETF as a whole is likely to
find very interesting. However, if anyone is curious, they are welcome
to read the DISCUSS here and see if they agree with your
characterization
On 05/15/2013 11:33 AM, Yoav Nir wrote:
On May 15, 2013, at 6:06 PM, Keith Moore mo...@network-heretics.com
wrote:
IMO, IESG should have grounds to reject any document that isn't specifically
authorized in a WG's charter.
- Keith
Why? There's definitely a process failure there, and it
On 5/15/2013 7:49 AM, Ralph Droms wrote:
The DISCUSS isn't there to make documents better - that's for COMMENTs. A
DISCUSS there to catch a set of problems and to*block* the document's progress until that
problem is resolved.
I'll agree with you *if* you consider an unclear description
John C Klensin john dash ietf at jck dot com wrote:
I think it is all very well to ask for affiliations in principle
and, also in principle, I agree that it is a good idea. But, in
practice, I think there are a lot of clarifications and other
changes that would be required and that might or
Subject: Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF
process]
John C Klensin john dash ietf at jck dot com wrote:
I think it is all very well to ask for affiliations in principle
and, also in principle, I agree that it is a good idea. But, in
practice, I think
Hi John.
I agree there are a number of specific cases where there is no
simple/obvious way to handle. I'd be OK with something fairly simple
as unaffiliated or consultant or something more nuanced. But I'd
like to think those are edge cases (but could of course be wrong in
how common they are). I
On 05/15/2013 07:38 PM, John C Klensin wrote:
So, what would you have me (and others like me) put on
registration forms so that I'm not part of that undifferentiated
180 names?
How about 7 densely worded paragraphs?
Sorry, couldn't resist:-)
S.
In all earnestness I don't think a resume will be necessary at all :).
--
Regards,
Edwin A. Opare
On Wed, May 15, 2013 at 11:33 PM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
On 05/15/2013 07:38 PM, John C Klensin wrote:
So, what would you have me (and others like me) put on
I initially replied to address Keith's comment. But a few things on Joe's:
On 5/15/13 7:41 AM, Keith Moore wrote:
On 05/15/2013 10:39 AM, Joe Touch wrote:
On 5/14/2013 9:54 PM, Keith Moore wrote:
Publishing broken or unclear documents is not progress.
Broken, agreed.
Unclear, nope - please
On 05/15/2013 09:07 PM, Pete Resnick wrote:
I initially replied to address Keith's comment. But a few things on
Joe's:
On 5/15/13 7:41 AM, Keith Moore wrote:
On 05/15/2013 10:39 AM, Joe Touch wrote:
On 5/14/2013 9:54 PM, Keith Moore wrote:
Publishing broken or unclear documents is not
--On Wednesday, May 15, 2013 14:28 -0700 Doug Ewell
d...@ewellic.org wrote:
...
I did this because
the WG at the time included a malicious contributor who had
already contacted the HR department of another contributor's
employer, asking them to professionally discipline the
employee,
--On Thursday, May 16, 2013 00:55 -0400 Keith Moore
mo...@network-heretics.com wrote:
Which is to say, if there is only a single AD blocking a
document, that block is essentially a 2 week affair if you
are willing to push the point. No need for negotiating; if
the WG decides that the AD
Few thoughts.
1) don't get wrapped around the axel of STD, PS, Foo bar label, it has nothing
to do with the problem that that IESG believes many drafts need changes to fix
significant problems. Lots of people imply that the IESG is setting the bar too
high but when you look at the changes
On May 14, 2013, at 9:58 AM, Cullen Jennings (fluffy) flu...@cisco.com
wrote:
2) On the point of what the IESG should be doing, I would like to see the
whole IESG say they agree with the Discuss Criteria document and will stay
within that (or change it if they disagree). The cross area
Just to echo in some form what others have said, I believe that an
intermediate stage between I-D and RFC is needed.
I don't have a name for it, but conceptually would be something like
'feature freeze', e.g. no more tweakings to the protocol, or base spec
are to be introduced (unless a major
inline
On May 14, 2013, at 10:34 AM, Ted Lemon ted.le...@nominum.com
wrote:
On May 14, 2013, at 9:58 AM, Cullen Jennings (fluffy) flu...@cisco.com
wrote:
2) On the point of what the IESG should be doing, I would like to see the
whole IESG say they agree with the Discuss Criteria document
On 5/14/2013 6:58 AM, Cullen Jennings (fluffy) wrote:
when you look at the
changes that are made to drafts from point they go in, to point they
come out of IESG it seems to be a rare example where people don't
agree that major changes were an improvement and needed.
This is an important
Hi Cullen,
On 05/14/2013 02:58 PM, Cullen Jennings (fluffy) wrote:
I would like to see the whole IESG say they agree with the Discuss Criteria
document and will stay within that (or change it if they disagree).
That I'm pretty sure is the case. When I started as a new AD
one of the first
I think this exchange between Cullen and Ted says it all, except
for one tweak: the IESG is allowed, even encouraged, to apply common
sense when considering the DISCUSS criteria. They are guidance,
not rules.
Also, everybody needs to take the word discuss literally. An
entirely possible outcome
Brian, et al.,
On 5/14/2013 1:10 PM, Brian E Carpenter wrote:
I think this exchange between Cullen and Ted says it all, except
for one tweak: the IESG is allowed, even encouraged, to apply common
sense when considering the DISCUSS criteria. They are guidance,
not rules.
Also, everybody needs
On 5/14/2013 10:18 AM, Dave Crocker wrote:
And a Discuss should be required to assert which criteria apply and how.
+1
Joe
Joe,
On 05/14/2013 09:45 PM, Joe Touch wrote:
As important as the DISCUSS criteria are, there are NON-DISCUSS criteria
that ought to be more carefully followed - including the point that
disagreements with the WG or clarifications are not justification for
DISCUSS.
I had assumed that the
On 5/14/2013 1:59 PM, Stephen Farrell wrote:
Joe,
On 05/14/2013 09:45 PM, Joe Touch wrote:
As important as the DISCUSS criteria are, there are NON-DISCUSS criteria
that ought to be more carefully followed - including the point that
disagreements with the WG or clarifications are not
On May 14, 2013, at 1:41 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
I've not found that a real problem. When its happened that we
did turn up something bigger than we thought after the telechat
(and updating your discuss points before or during the telechat
is considered fair game)
It seems to me that if it is really a discussion, then there may be many
possible things which could resolve it, and the AD raising the question
may not know exactly what is feasible to clear it. Otherwise it is a
demand, not a discussions. And in my experience while ADs can be pushy
(like
On 5/14/2013 3:00 PM, Joel M. Halpern wrote:
It seems to me that if it is really a discussion, then there may be many
possible things which could resolve it, and the AD raising the question
may not know exactly what is feasible to clear it. Otherwise it is a
demand, not a discussions. And in
Below:
On 5/14/2013 6:04 PM, Joe Touch wrote:
On 5/14/2013 3:00 PM, Joel M. Halpern wrote:
It seems to me that if it is really a discussion, then there may be many
possible things which could resolve it, and the AD raising the question
may not know exactly what is feasible to clear it.
On May 14, 2013, at 6:00 PM, Joel M. Halpern j...@joelhalpern.com wrote:
At the same time, discussions do have to be resolvable. If there is no way
to address it, then it is not a discuss. But required to clar is the wrong
picture as far as I can tell.
Exactly right. It would actually be
On 5/14/2013 3:12 PM, Ted Lemon wrote:
On May 14, 2013, at 6:00 PM, Joel M. Halpern j...@joelhalpern.com
wrote:
At the same time, discussions do have to be resolvable. If there
is no way to address it, then it is not a discuss. But required
to clar is the wrong picture as far as I can tell.
On Tue, May 14, 2013 at 03:30:52PM -0700, Dave Crocker wrote:
And of course, that's still everyone's preference. But the reality is
that the imposition of the Discuss is an assertion that changes are
being required.
For reference, that milder uses of Discuss, which is something akin to
On May 14, 2013, at 6:30 PM, Dave Crocker d...@dcrocker.net wrote:
And of course, that's still everyone's preference. But the reality is
that the imposition of the Discuss is an assertion that changes are
being required.
No, it absolutely is not. That may have been the theory when you were
On 5/14/2013 3:46 PM, Andrew Sullivan wrote:
To be fair, for what it's worth as a WG chair I've had the latter
experience at least as often as the former in the use of DISCUSS, and
I've observed some DISCUSSes cleared without any change at all to the
document in question.
We suffer a
And your bottom line is exactly what te rules say, what I said, what Ted
said, and what Joe agreed is reasonable. It also matchesthe practice I
have seen. Even the discuss that I had a lot of arguments with did
include proposals for paths forward. Sometimes they were ard to
understand.
On 5/14/2013 4:03 PM, Ted Lemon wrote:
If the authors think that the goal is to please the AD, something's
wrong. This would suggest that they will just do what the AD says
without debate, which is exactly the wrong thing. The whole point of
a DISCUSS is to have a discussion. Frankly, it's
On May 14, 2013, at 8:27 PM, Joe Touch to...@isi.edu wrote:
That is what happens exactly because the DISCUSS holds up the document, and
most ADs don't want to burn time stalling their documents if there's a way
around that delay.
It can only happen if an author values getting their document
I'll say that about a year and a half ago I found myself pushing back on
discusses
that in my opinion clearly were not within the discuss criteria
significantly more than I ever had to do as an AD. My role was as WG
chair/editor.
Interestingly it's been less of an issue in my experience lately.
On 05/14/2013 06:30 PM, Dave Crocker wrote:
On 5/14/2013 3:12 PM, Ted Lemon wrote:
On May 14, 2013, at 6:00 PM, Joel M. Halpern j...@joelhalpern.com
wrote:
At the same time, discussions do have to be resolvable. If there
is no way to address it, then it is not a discuss. But required
to clar
On 05/14/2013 04:45 PM, Joe Touch wrote:
Brian, et al.,
On 5/14/2013 1:10 PM, Brian E Carpenter wrote:
I think this exchange between Cullen and Ted says it all, except
for one tweak: the IESG is allowed, even encouraged, to apply common
sense when considering the DISCUSS criteria. They are
Similarly, AFAICS the 'IESG time' includes IETF last call and the
inevitable delay caused by the quantized nature of IESG teleconferenes.
On the average, this will be somewhere around 28-30 days (2 or 4 weeks
in Last call according to document type plus an average of 1 week until
the earliest
On 5/8/2013 10:50 AM, Jari Arkko wrote:
Heather, all,
You are correct, Peter. MISSREF and AUTH48 are not part of the RFC
Editor timed states, and the RFC Editor timed states have been largely
under 7 weeks for the last year.
Indeed. The actual time for what RFC Editor does for documents is
--On Thursday, May 09, 2013 03:32 -0500 Spencer Dawkins
spen...@wonderhamster.org wrote:
So in this case, we're looking at RFC Editor state =
Heather, please do something + some working group, please
do something + author(s), please do something, and we can't
tell how much time to attribute
On 10/05/2013 01:13, John C Klensin wrote:
--On Thursday, May 09, 2013 03:32 -0500 Spencer Dawkins
spen...@wonderhamster.org wrote:
So in this case, we're looking at RFC Editor state =
Heather, please do something + some working group, please
do something + author(s), please do something,
On 5/7/13 9:48 PM, Peter Saint-Andre wrote:
On 5/2/13 4:58 PM, Dave Crocker wrote:
On 5/2/2013 3:25 PM, Jari Arkko wrote:
But the delay was really not my main concern. Primarily because I
think other issues such as transparency to the working group or late
surprises are more fundamental
Heather, all,
You are correct, Peter. MISSREF and AUTH48 are not part of the RFC
Editor timed states, and the RFC Editor timed states have been largely
under 7 weeks for the last year.
Indeed. The actual time for what RFC Editor does for documents is quite short
(and thank you and others at
Olaf Kolkman wrote:
Where things become difficult is at the point where the maintenance
of our standards need to be explained and questions about progression
on the standards ladder get asked.
Personally I hope that RFC 6410 has the effect that we, as a community,
get serious about
On 5/2/13 4:58 PM, Dave Crocker wrote:
On 5/2/2013 3:25 PM, Jari Arkko wrote:
But the delay was really not my main concern. Primarily because I
think other issues such as transparency to the working group or late
surprises are more fundamental issues than mere timing. But also
because I
Hannes,
The aim of this group is to find out how to reference IETF RFC (and standards
from other organizations, like the W3C) since the European Commission seems
to be unable to just reference standards beyond a small set of organizations
(such as ETSI).
As you can imagine, the
On Sun, 2013-05-05, John C Klensin wrote:
Finally, there are a few things that we used to do, that were
helpful, and that were abandoned due to industry evolution and
changes in priorities. The original idea of a Proposed Standard
as a fairly rough specification that would be used for study
On May 5, 2013, at 7:54 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote:
On 05/05/2013 01:37 PM, Benoit Claise wrote:
On 2/05/2013 18:17, Carsten Bormann wrote:
On May 2, 2013, at 07:21, Eggert, Lars l...@netapp.com wrote:
Yeah, all kinds of issues, but if we created a new thing here
..
WG chairs might like to comment, but I suspect that one lunchtime training
session every four months does not constitute proactive management.
+1 !!!
It works on down the line too.
WG Chairs meeting with I-D editors once every 4 months isn't so great
either.
If the total time has gone up
At 07:20 03-05-2013, Adrian Farrel wrote:
WG chairs might like to comment, but I suspect that one lunchtime training
session every four months does not constitute proactive management.
One lunch every four months does not look like proactive management. :-)
At 11:34 03-05-2013, Andy Bierman
--On Monday, May 06, 2013 04:35 -0400 Olaf Kolkman
o...@nlnetlabs.nl wrote:
Personally I hope that RFC 6410 has the effect that we, as a
community, get serious about promoting our proposed standards,
or obsolete them.
I wonder how many standards got promoted after 6410 was
published.
--On Monday, May 06, 2013 00:26 -0700 Bill McQuillan
mcqui...@pobox.com wrote:
On Sun, 2013-05-05, John C Klensin wrote:
Finally, there are a few things that we used to do, that were
helpful, and that were abandoned due to industry evolution and
changes in priorities. The original idea
On 05/03/2013 03:59 PM, Thomas Narten wrote:
b) There is no interest to research where delay really happen.
I don't think that is true. Jari has pointed to his work. I think
there is actually quite a lot of understanding of where the delays
are. But fixing them is really really hard. Blaming
Thomas, this all sounds very easy and reasonable. Unfortunately, it does
not work that way (as you might recall from your own WG chair experience).
Both chairs and WG participants are very busy and so they do not
follow-up on the tasks they had agreed on earlier.
Since everything is done on
On 05/03/2013 01:25 AM, Jari Arkko wrote:
However, I did want to point out that when I said tail-heavy, I
did*not* necessarily mean delay. I meant that a lot of activity is
going on, many document changes, and much review is going on.
Obviously in some cases this translates to delay as well.
On 05/03/2013 07:52 PM, John Leslie wrote:
Dave Crocker d...@dcrocker.net wrote:
On 5/3/2013 7:29 AM, Ray Pelletier wrote:
Provide WG Chairs the monitoring tools they need to be proactive - Action
Tracker, what do I need to do today data tracker views. Same for AD.
Same for authors and
On 5/1/13 2:10 PM, Ted Lemon wrote:
On May 1, 2013, at 5:00 PM, Scott Brim s...@internet2.edu wrote:
Let's rename last call to
something like IETF review and stop giving people the wrong
expectations. Review outside the WG is vital, can be done repeatedly,
and must be done by the whole IETF at
On 2/05/2013 18:17, Carsten Bormann wrote:
On May 2, 2013, at 07:21, Eggert, Lars l...@netapp.com wrote:
Yeah, all kinds of issues, but if we created a new thing here in between WGLC
and PS, the broader industry would never understand.
That is a matter of naming and marketing (candidate
On May 4, 2013, at 10:26 PM, joel jaeggli joe...@bogus.com wrote:
However, that is a bit of a problem, because I think it's fairly rare for
documents to get additional review at last call time. Changing the name
probably won't fix that.
It feels like unless something is particularly
Thomas,
Good point. I guess the obvious answers are not enough
cycles and, for newer authors, uncertainty about how to
get stuff done, but are there other less obvious answers?
(Input here might really help the IESG discussion btw since
in the nature of things, we're less likely to realise what
On May 1, 2013, at 1:59 PM 5/1/13, Dave Crocker d...@dcrocker.net wrote:
The blog nicely classes the problem as being too heavy-weight during final
stages. The quick discussion thread seems focused on adding a moment at which
the draft specification is considered 'baked'.
I think that's
On 05/05/2013 01:37 PM, Benoit Claise wrote:
On 2/05/2013 18:17, Carsten Bormann wrote:
On May 2, 2013, at 07:21, Eggert, Lars l...@netapp.com wrote:
Yeah, all kinds of issues, but if we created a new thing here in
between WGLC and PS, the broader industry would never understand.
That is a
On 05/05/2013 02:47 PM, Benoit Claise wrote:
The tail is heavy in two different ways:
* significant review and modification takes place in IESG review,
after the WG and the IETF have declared the document done
* the burden of the review, managing the discussion, making sure any
changes fix the
Hi Jouni,
Jari,
This was an interesting (and a needed) writeup. I also want to share
my view as an IETF newbie who has had a chance to experience IETF
document process a few times. Sorry for chiming in late..
For the most part I got the feeling that we have the right tools and
a working
On 05/05/13 08:00, Hannes Tschofenig allegedly wrote:
while it is desirable to get wider reviews happen earlier in the process
there is obviously a challenge: You don't want to ask for reviews before
the document is stable and you cannot ask many times since good reviews
are expensive.
There
--On Friday, May 03, 2013 18:10 -0400 Hector Santos
hsan...@isdg.net wrote:
May I suggest that the IETF produce a web site for gathering
IETF participants profiles and even resumes. It can have a
questionnaire to extract the valuable information that will
help maximize the IETF/IESG
--On Friday, May 03, 2013 13:29 -0400 Thomas Narten
nar...@us.ibm.com wrote:
Let me expand further on work plan and project management.
...
But it extends to the WG as a whole. WGs have a finite number
of cycles. [...] if you spread their
resources too thinly, a WG starts having problems.
Hi Tony,
At 17:36 03-05-2013, Tony Hain wrote:
Yes it can, and they often do. The question in this case is more about the
way that was documented, and Douglas' effective call for a wider review of
the decision. It may simply be the wording in the issue tracker, but reading
that the effective
Jari,
This was an interesting (and a needed) writeup. I also want to share
my view as an IETF newbie who has had a chance to experience IETF
document process a few times. Sorry for chiming in late..
For the most part I got the feeling that we have the right tools and
a working process already
Just a few points...
Michael Richardson mcr+i...@sandelman.ca writes:
I'll repeat what has been said repeatedly in the newtrk and related
discussions. The step from ID to RFC is too large because we are
essentially always aiming for STD rather than PS.
If we are unwilling to bring RFC back
On 05/03/2013 01:59 PM, Thomas Narten wrote:
If you look at the delays documents encounter (both in WG and in IESG
review), the killer is long times between document revisions. Focus on
understanding the *why* behind that and what steps could be taken to
make improvements.
Good point. I
Good point. I guess the obvious answers are not enough
cycles and, for newer authors, uncertainty about how to
get stuff done, but are there other less obvious answers?
(Input here might really help the IESG discussion btw since
in the nature of things, we're less likely to realise what
Well said, Thomas.
Two concrete suggestions:
1) have WGs do the managing role more proactively
2) mentor authors and others a bit more to encourage them how best to
operate
Which I suspect means...
0) have ADs manage/mentor the WG chairs more proactively.
Almost certainly a case of if I
1 - 100 of 165 matches
Mail list logo
