> From: Thomas Narten
>
> 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 we also have
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.
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 n
On 05/16/2013 01:44 AM, John C Klensin wrote:
--On Thursday, May 16, 2013 00:55 -0400 Keith Moore
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 de
--On Thursday, May 16, 2013 00:55 -0400 Keith Moore
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 is totally off ba
--On Wednesday, May 15, 2013 14:28 -0700 Doug Ewell
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, because he had s
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 progre
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
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 wrote:
>
>
> 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
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.
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)
f@ietf.org
Subject: Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF
process]
John C Klensin 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
John C Klensin 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 might not be
> practical.
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 descriptio
On 05/15/2013 11:33 AM, Yoav Nir wrote:
On May 15, 2013, at 6:06 PM, Keith Moore
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 c
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 5/15/2013 11:08 AM, Ted Lemon wrote:
On May 15, 2013, at 1:23 PM, Joe Touch 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 I
--On Wednesday, May 15, 2013 18:25 +0200 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 me
On May 15, 2013, at 1:23 PM, Joe Touch 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 find very
i
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 5/15/2013 10:15 AM, Ted Lemon wrote:
On May 15, 2013, at 12:36 PM, Joe Touch 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 protoc
On May 15, 2013, at 12:36 PM, Joe Touch 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
ambig
On 5/15/2013 7:55 AM, Ted Lemon wrote:
On May 15, 2013, at 10:41 AM, Keith Moore 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 seems necessary to acquit
t
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
+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. A
On May 15, 2013, at 6:06 PM, Keith Moore
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 and/or the AD, who should h
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)
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 neces
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 wrote:
> On May 15, 2013, at 10:41 AM, Keith Moore wrote:
>>> The motivation for a particular feature of a protocol is not clear enough.
On May 15, 2013, at 10:41 AM, Keith Moore 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
>> responsibilities.
>
>
On May 15, 2013, at 10:39 AM 5/15/13, 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 par
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 sacrosanct.
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 cle
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, prot
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 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 5:53 PM, Ted Lemon wrote:
On May 14, 2013, at 8:27 PM, Joe Touch 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 valu
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 ever
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 guid
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"
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 pic
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 May 14, 2013, at 8:27 PM, Joe Touch 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 through the
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'
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. That
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 continuin
On May 14, 2013, at 6:30 PM, 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.
No, it absolutely is not. That may have been the theory when you were AD, but
I can
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
On 5/14/2013 3:12 PM, Ted Lemon wrote:
On May 14, 2013, at 6:00 PM, "Joel M. Halpern"
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.
On May 14, 2013, at 6:00 PM, "Joel M. Halpern" 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 pretty presum
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. Other
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
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 th
On May 14, 2013, at 1:41 PM, Stephen Farrell 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) then I think the author
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 justific
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 10:18 AM, Dave Crocker wrote:
And a Discuss should be required to assert which criteria apply and how.
+1
Joe
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 to
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
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 t
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 asse
inline
On May 14, 2013, at 10:34 AM, Ted Lemon
wrote:
> On May 14, 2013, at 9:58 AM, "Cullen Jennings (fluffy)"
> 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
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 show
On May 14, 2013, at 9:58 AM, "Cullen Jennings (fluffy)"
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 review teams
> m
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 tha
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 poss
On 10/05/2013 01:13, John C Klensin wrote:
>
> --On Thursday, May 09, 2013 03:32 -0500 Spencer Dawkins
> 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
--On Thursday, May 09, 2013 03:32 -0500 Spencer Dawkins
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 to each of th
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 q
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
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
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 fundam
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
--On Monday, May 06, 2013 00:26 -0700 Bill McQuillan
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 of a Prop
--On Monday, May 06, 2013 04:35 -0400 Olaf Kolkman
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.
According to
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 wr
..
> 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
On May 5, 2013, at 7:54 AM, Hannes Tschofenig 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" wrote:
>>>
Yeah, all kinds of issues, but if we created a new thing here in
between WGLC and
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 st
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 dif
--On Friday, May 03, 2013 13:29 -0400 Thomas Narten
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.
>
> Few
--On Friday, May 03, 2013 18:10 -0400 Hector Santos
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 efforts. The "Busi
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".
T
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 process
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 p
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" 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 namin
On May 1, 2013, at 1:59 PM 5/1/13, Dave Crocker 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 still too late.
..
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 4, 2013, at 10:26 PM, joel jaeggli 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 controversial
On 2/05/2013 18:17, Carsten Bormann wrote:
On May 2, 2013, at 07:21, "Eggert, Lars" 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 RFC"?).
There is
On 5/1/13 2:10 PM, Ted Lemon wrote:
On May 1, 2013, at 5:00 PM, Scott Brim 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 least once.
Y
On 05/03/2013 07:52 PM, John Leslie wrote:
Dave Crocker 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 their mentors, if any
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.
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 a
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 the
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 mess
S Moonesamy wrote:
> ...
>
> >I have not followed this discussion, but my cursory read of the tracker
> >ticket shows the WG blew off the issue by claiming that historical
> >unsophisticated attacks can be easily thwarted, while completely
> >ignoring the case where the target domains exist. Abort
Hi Tony,
At 14:11 03-05-2013, Tony Hain wrote:
See the thread about Re: call for ideas: tail-heavy IETF process for
discussion about wider review at an earlier point in the process. Also, just
because there is a discussion on issue-tracker does not mean the document is
'high quality'
* Hector Santos 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
>efforts. The "Business Information" (BI) can then be levera
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
efforts. The "Business Information" (BI) can then be leveraged by ADs,
WGs (and other
ay, May 03, 2013 02:11:28 PM Tony Hain wrote:
> Scott,
>
> See the thread about Re: call for ideas: tail-heavy IETF process for
> discussion about wider review at an earlier point in the process. Also, just
> because there is a discussion on issue-tracker does not mean the docu
1 - 100 of 165 matches
Mail list logo
