The IESG is interested in carrrying out an experiment to publish
narrative minutes for IESG meetings as well as the regular minutes
of decisions taken.
Currently the IESG minutes are a formal record of decisions taken
and (like the agenda) are generated semi-automatically by the
secretariat.
These are personal comments. I am also the shepherding AD for this draft.
2. Issues To Consider
...
For example, if the space
consists of text strings, it may be desirable to prevent
organizations from obtaining large sets of strings that correspond to
the best names (e.g.,
General AD hat on:
I'm concerned that since rfc2434bis is in progress, any changes to
RFC 2434 should be made in that draft, not by an additional document.
Otherwise we will end up with a patchwork quilt of documents.
So I'd encourage the authors of iana-reg-policy to figure out where
their
Bruce Lilly wrote:
On Tue July 12 2005 05:25, Brian Carpenter wrote (via ietf-announce):
The Tools Team was set up by Harald Alvestrand and has made
good progress (e.g. draft-ietf-tools-draft-submission-09,
which has been approved as an Informational RFC).
Now it's time to update the team's
Sure, but the logic is nevertheless a bit contorted - but rather than
debating what the current system *means* could be concentrate
on what we should do in future?
Incidentally 3596 (a DS) obsoletes 3152 (a BCP). That's unusual,
but it isn't illogical. However, 3152 isn't shown as Obsolete
in
Sam Hartman wrote:
Scott == Scott Bradner [EMAIL PROTECTED] writes:
Scott re draft-iesg-discuss-criteria-00.txt
Scott I think this is a very helpful document - if followed by
Scott the IESG it should reduce the number of what appears to be
Scott blocking actions by ADs
Phill,
Just picking out the nub of your message:
There is however one area that should be made very explicit as a non
issue for DISCUSS, failure to employ a specific technology platform.
I have been concerned on a number of occasions where it has appeared
that in order to get a specification
Bruce Lilly wrote:
On Mon July 11 2005 02:54, [EMAIL PROTECTED] wrote:
This really made me scratch my head. One would imagine if a protocol is
obsoleted
by another, it would not be listed as a Draft Standard any longer.
What is the reason for continuing to list something obsolete as a
I'm hesitant to relaunch this thread, but there are a number of points
that incite me to comment. Since there's been a fair amount of
repetition, may I ask people only to chime in with new thoughts?
Paul Hoffman wrote:
At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote:
RFC 2434 doesn't discuss
We're just putting together the agendas for the plenary sessions
in Paris. They will be Wednesday and Thursday at new timings:
17:30 through 20:00, before dinner, to match Paris restaurant hours.
Wednesday will focus on IETF operations, administration and process
(led by me as IETF Chair).
As most RFC authors know, when an IESG member identifies a problem in
a draft under IESG review, he or she casts a DISCUSS ballot, with
accompanying text, and the DISCUSS has to be cleared before the
document can advance.
draft-iesg-discuss-criteria-00.txt talks about this. Even within the
IESG,
This is a somewhat personal note, expanding on something I hinted
at in plenary in Minneapolis.
The person appointed as IETF Chair actually gets three jobs today:
IETF Chair
IESG Chair
General Area Director
The IETF Chair is clearly responsible to the IETF as a whole.
A fairly large amount of
in prudent management of a namespace.
However, this was not a factor in the IESG discussion.
Brian
John C Klensin wrote:
--On Wednesday, 06 July, 2005 20:37 -0400 John Leslie
[EMAIL PROTECTED] wrote:
John C Klensin [EMAIL PROTECTED] wrote:
--On Wednesday, 06 July, 2005 17:28 +0200 Brian E
Joe,
Joe Touch wrote:
Keith Moore wrote:
Keith,
The IESG can still exercise their best engineering judgment as
individuals, as the rest of us do.
The IESG role itself need not incorporate a privileged position from
which to wield that judgement. There's plenty left to do.
Joe,
The
Keith Moore wrote:
Keith,
The IESG can still exercise their best engineering judgment as
individuals, as the rest of us do.
The IESG role itself need not incorporate a privileged position from
which to wield that judgement. There's plenty left to do.
Joe,
The IESG has several duties that
John C Klensin wrote:
--On Tuesday, 05 July, 2005 08:47 -0700 Bill Manning
[EMAIL PROTECTED] wrote:
I don't believe that is true in this case, as long as RFC
2780 is in force.
Especially since there is a clear path for Larry Roberts to
ask for IETF consensus, which by definition would
Ned Freed wrote:
Can anyone suggest where I could find the requirement for IANA
Considerations?
There is no requirement that such sections appear in published RFCs. This
debate has never been about what's required in RFCs, but rather what's required
in drafts submitted to the IESG.
RFC 2434
grenville armitage wrote:
Brian E Carpenter wrote:
grenville armitage wrote:
...
My only concern is that we're using codepoint assignment denial as a
means
of protecting the Internet from poor, TCP-unfriendly end2end algorithms.
Who's we? The IESG said that the IESG wasn't going
Robert Elz wrote:
Date:Tue, 5 Jul 2005 00:58:36 -0700
From:Christian Huitema [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| The problem is the really small size of the option type field in IPv6.
| There really only are 5 bits available for numbering both the
Robert Elz wrote:
Date:Wed, 29 Jun 2005 17:39:37 -0400
From:Margaret Wasserman [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| The arguments against what the IESG has done seem,
| mostly, to be that we should have gotten IETF consensus before
| making a
grenville armitage wrote:
...
My only concern is that we're using codepoint assignment denial as a means
of protecting the Internet from poor, TCP-unfriendly end2end algorithms.
Who's we? The IESG said that the IESG wasn't going to approve a codepoint,
and that the only way to get it approved
Pete Resnick wrote:
...
Personally, I find nothing in 2026 which indicates in the best
interests of the IETF and the Internet as a criteria for the IESG to
evaluate much of anything. And I think that is part of the concern you
are hearing expressed in the objections to the decision process.
Robert Elz wrote:
...
Also remember that no consensus in an issue like this, really needs to
mean no authority - if you cannot get at least most of the community to
agree with the IESG position, then the IESG cannot just claim the
authority and say there is no consensus that we should not have
Thanks Ken (and those who have followed up). I don't think
there's any need to repeat the count - we can safely say
that opinions are divided.
Brian
Ken Carlberg wrote:
From: Brian E Carpenter
I'm supposed to be on vacation so this will be brief, but I don't
think that your assertion
John,
John C Klensin wrote:
...
However, consider instead the situation we find ourselves in. The IESG,
at least in the interpretation as given on this list by some of its
members, has said, essentially, We have concluded that this requires
technical review within the IETF before it is
Jari,
As I've told Larry, and as Margaret and you both say, there are two
ways forward:
1. The proponents submit an I-D and ask the IETF to review it.
The IETF's IPR rules would apply.
2. Another standards body sends a liaison to the IETF asking for
an assignment, backed up by a publicly
Dean,
Please stop repeating assertions about alleged liars.
Sergeants-at-arms, please pay attention since I believe that we
may need to consider action if this continues.
Brian
Dean Anderson wrote:
On Mon, 27 Jun 2005, Dave Crocker wrote:
I thought we also had a mechanism for taking
Hans Kruse wrote:
...
but otherwise I _cannot_ see how the _content_ of the option could harm a device that does not want to deal with it.
If it interferes with congestion management elsewhere along the path, it can
potentially damage
every other packet stream. This is a *very* complex
Dave,
I'm supposed to be on vacation so this will be brief, but I don't think
that your assertion about what the community has said is backed up
by postings from a sufficient number of people to be a community view.
Most people in the community haven't posted one way or the other. I
haven't
As a matter of information, my habit is to ignore messages under a given
subject field that discuss something else, e.g. messages under a header
like 'RFC 2434 term IESG approval' that actually discuss language tags.
Brian
___
Ietf mailing list
Larry,
One thing that may not be immediately obvious is that if the IETF
reviews a contribution (whether it's an Internet-Draft or an email),
it automatically falls under IETF IPR rules. Alternatively, if another
SDO sends a liaison requesting IETF review of their document, we
presume that the
Yakov Rekhter wrote:
Ned,
To state that somewhat differently, since we cannot effectively
prohibit the deployment of an extension or option of which the
IETF disapproves, the best things we can do for the Internet are
make it as easy as possible to identify the use of the extension
so it can
(and this is
addressed to everybody on the list) if you ever feel the desire
to launch a quarrel or take part in one, please take it
elsewhere. Here, we stick to professional discourse.
Brian
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
IETF Chair
Distinguished Engineer
2 until we've dealt with question 1.
Brian
John C Klensin wrote:
--On Monday, 27 June, 2005 17:00 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
The debate (except that since the work hadn't been brought to
the IETF,
the debate hasn't happened) is whether the proposed mechanism
Vint,
Vinton G. Cerf wrote:
I want to clarify something here. IANA is not at fault. It submits requests
like this to IESG to assure that there is consistency in
standards work. In the past there have been attempts to circumvent standards
work that is under way by directly submitting requests
and the announcement, took a number
of weeks. We agreed apart from final wordsmithing in the May 26
meeting (agenda item 6.2).
Brian
Ralph Droms wrote:
Brian...
On Sun, 2005-06-26 at 17:50 +0200, Brian E Carpenter wrote:
Ralph,
Ralph Droms wrote:
I'd like to understand the process through which Dr
I read it as a statment of fact. I could reasonably
rule it irrelevant and ask Harald not to repeat it.
Brian
Dean Anderson wrote:
This would be a personal attack, I think.
--Dean
On Sun, 26 Jun 2005, Harald Tveit Alvestrand wrote:
Since I'm no longer responsible for
I have the good fortune to not be subscribed to the
namedroppers list, so I have no familiarity with past
traffic on that list. I think it behooves us all to let
bygones be bygones - I don't see much point in debating
alleged misdeeds of former ADs.
Brian
Dean Anderson wrote:
Mr.
Dave Crocker wrote:
Vinton G. Cerf wrote:
I want to clarify something here. IANA is not at fault. It submits
requests like this to IESG to assure that there is consistency in
standards work. In the past there have been attempts to circumvent
standards work that is under way by directly
Vinton G. Cerf wrote:
I want to clarify something here. IANA is not at fault. It submits requests
like this to IESG to assure that there is consistency in
standards work. In the past there have been attempts to circumvent standards
work that is under way by directly submitting requests
to IANA
Ralph,
Ralph Droms wrote:
I'd like to understand the process through which Dr. Roberts' request
was reviewed. The first reference I can find to Dr. Roberts' request is
in the 2005-04-14 minutes of the IESG
(https://datatracker.ietf.org/public/view_telechat_minute.cgi?
command=view_minuteid=318
JFC (Jefsey) Morfin wrote:
At 23:40 25/06/2005, Brian E Carpenter wrote:
I strongly advise against waiting for a hypothetical
waiver. If the above site says you need a visa, I advise
applying for it immediately. French bureaucrats are not
known for flexibility.
If flexibility means to non
John Leslie wrote:
Thomas Narten [EMAIL PROTECTED] wrote:
...
The right thing to do is to have this document reviewed proper in the
IETF and then let the IETF decide what it wants to do with it.
Then why don't we do that?
There has never been an Internet-Draft or other form of IETF
is a documented liar, and 's associate
(formerly of ) has been proven in court to be a liar on 3 separate
court cases. And 's only regret in those cases is that he told the
court the truth when asked if he had subscribers. was shut for
contempt of court when
Enough, gentlemen, please.
Brian
Doug Royer wrote:
Dean Anderson wrote:
Brian Carpenter asked that the subject be changed. I've also removed
the IESG from the cc-list.
Doug, you've been misled. Inline.
On Wed, 22 Jun 2005, Doug Royer wrote:
I have not been following this topic
Dave Crocker wrote:
And this requirement is quite new. It would be unprecedented if it hadn't
triggered some level of initial review in these very early days. But wait
a couple of years for the new to wear off and people being people will
start to handle it as more boilerplate.
For anyone
Dave Crocker wrote:
Brian,
To date, we treat most of the IETF process as uinsg free resources.
To be blunt, I believe this is a direct consequence of our open door,
individual participation ethic. If you want firm resource commitments,
you have to ask corporations and other
Dave,
To date, we treat most of the IETF process as uinsg free resources.
Hence we do no real scheduling of valuable resources, except by fifo and
congestion behaviors. Is that really any way to run a major standards
group?
To be blunt, I believe this is a direct consequence of our open
Marshall,
Marshall Eubanks wrote:
On Thu, 16 Jun 2005 15:37:50 +0200
Brian E Carpenter [EMAIL PROTECTED] wrote:
Edward Lewis wrote:
At 9:20 -0500 6/15/05, wayne wrote:
It is hard to get people to use tools when they don't know they exist
and are very hard to find.
I'd like to add
Maybe you should stick to talking about things that you know something
about.
I thought that ad hominem attacks were considered unacceptable on this list?
On any IETF list, actually. It's best all round if people remain
professional and polite, however strong the disagreement.
Brian
Jeffrey Hutzelman wrote:
On Monday, June 13, 2005 08:25:38 PM -0400 Ralph Droms
[EMAIL PROTECTED] wrote:
Better yet would be late binding: INSERT LATEST IETF STANDARD FIXED
BOILERPLATE.
Has anyone actually _read_ the boilerplate in drafts you are submitting?
Much of that text affects
Edward Lewis wrote:
At 9:20 -0500 6/15/05, wayne wrote:
It is hard to get people to use tools when they don't know they exist
and are very hard to find.
I'd like to add a me too to that and a few suggestions...
I'd like to add that the datatracker be easier to find that having it
buried
Henning,
Henning Schulzrinne wrote:
I suspect each regular IETF participant knows WGs that are well-led and
others that could stand improvement. WG chairs are crucial in ensuring
progress, but there doesn't seem to be any real, transparent evaluation
of their efforts. Some possibilities:
Henrik Levkowetz wrote:
on 2005-06-16 01:53 Henning Schulzrinne said the following:
Henrik Levkowetz wrote:
Sounds like a good idea. However it requires direct integration with the
tracker, which means that the tools team can't just put up a prototype,
Not really - one could associate
Theodore Ts'o wrote:
On Thu, Jun 16, 2005 at 03:43:25PM +0200, Brian E Carpenter wrote:
(1) It is hard to fire WG chairs - they are often friends and
colleagues. Unfortunately, many stay on when their job responsibilities
have changed and they can no longer dedicate the necessary time
Lars-Erik Jonsson (LU/EAB) wrote:
These tools are useful, but don't track (for example)
working group last calls. They don't even track interim
meetings, at least based on my limited checks.
True on both counts. I have code in place to track WG last
calls, but haven't had resources to
JFC (Jefsey) Morfin wrote:
On 16:07 14/06/2005, John C Klensin said:
John, I don't see any text in RFC 2026 that gives an appeal
suspensive effect. However, as a matter of common sense, I
have asked the Secretariat to request the RFC Editor to
suspend RFC publication.
I support this. It
Fred,
I completely agree with the principles you are suggesting. But
I would be reluctant to embed statements about the ISOC appointees
in an IETF procedural BCP, because it would convolute two independent
organisation's procedures. But that's a personal opnion and I'd be
glad to hear other
Ned Freed wrote:
On Fri, 10 Jun 2005, Ned Freed wrote:
What exactly is it that you
think should be done (in addition to careful reviews) that would help
reduce the odds that the careful review find issues with the IANA
instructions (or lack thereof)?
Simple: The requirement that an IANA
John C Klensin wrote:
--On Friday, 10 June, 2005 23:13 -0700 Ole Jacobsen
[EMAIL PROTECTED] wrote:
Remember last time you registered for an IETF meeting?
Does this ring a bell at all?
http://www.unixwiz.net/ndos-shame.html
On the other hand, while the IETF site gets at least this right,
Keith Moore wrote:
The current document purports to be a candidate for BCP and yet it
recommends a practice which is clearly no longer appropriate.
clearly?
please provide a citation to any sort of official consensus statement
that
establishes this clarity.
you seem to be confusing
Ned Freed wrote:
...
And in fact there has already been at least one example of this happening. The
document draft-ietf-lemonade-mms-mapping-04.txt is now in the RFC Editor's
queue. It's IANA considerations section says no IANA actions. Alas, the
document defines any number of new header fields
OK, we can take these comments as inout for the revision of 2434.
Brian
JFC (Jefsey) Morfin wrote:
At 15:38 09/06/2005, Brian E Carpenter wrote:
Please see RFC 2434 = BCP 26
Dear Brian,
I was probably not clear enough. Bruce quoted RFCs, and others points
postdate RFC 2434. Current
It's a matter of taste whether http://www.ietf.org/ID-Checklist.html
is obscure or not, but it is quite explicit and cites RFC 2434
which is BCP 26.
BCP 26 says, among other things:
All future RFCs that either explicitly or implicitly rely on the IANA
to register or otherwise manage
Carl Malamud wrote:
Randall's method works, or you can do what the readme suggests:
rfc ipr='full3978' docName='draft-mrose-writing-rfcs-01'
see:
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr
A number of us, including the IETF Chair, have discovered this
Ned Freed wrote:
...
The IETF Internet-Drafts page notes that All Internet-Drafts that are
submitted to the IESG for consideration as RFCs must conform to the
requirements specified in the I-D Checklist. The current version of
the ID-Checklist clearly states:
That's most unfortunate. What do
Please see RFC 2434 = BCP 26
Brian
JFC (Jefsey) Morfin wrote:
Dear Bruce,
you know what? I think it would be great to write a IANA obligations
RFC. It would say that the IANA MUST maintain a list of all the
obligations RFC authors should respect when writting the IANA
considerations,
Franck,
That's a good idea. In fact, it's so good that the IETF's EDU team
already has the desire to start a newsletter, with ISOC support. It is
not likely to be monthly (too much effort) but it should be regular.
Brian
Franck Martin wrote:
I realise the importance of having a newsletter
Bruce Lilly wrote:
On Tue May 24 2005 09:18, Hollenbeck, Scott wrote:
On Tue May 24 2005 08:35, Margaret Wasserman wrote:
At 5:57 PM -0400 5/10/05, Bruce Lilly wrote:
OK, I'll bite -- where are the statistics (I know of one
WG that has been
active for more than 8 years and has set to
Dave Crocker wrote:
o be slightly provocative, if the average
times are forced upwards by a long tail of WGs/drafts/RFCs that
take extremely long times to get done due to one-of-a-kind reasons,
it would seem fair to remove thoses cases from consideration.
use the median, rather than the
Steve,
No doubt, but that problem doesn't go away with increased parallel
processing. If we're talking about, say, a 100 page MIB, where the
MIB doctors do provide excellent parallel processing, there is still
going to be the problem of the chosen reviewer cutting out a full
day to grind through
Dave Crocker wrote:
...
The only way to make sure deliveries of product -- in this case, IETF
documents -- are timely is to decide when they are needed by and set firm
deadlines. The IETF currently does not do that. Instead, we leave everything
open-ended.
I'm very curious how one can
Bill,
Bill Sommerfeld wrote:
On Wed, 2005-05-18 at 04:50, Brian E Carpenter wrote:
Would it be better if the process required an explicit request for
more time?
In the face of variable workload it makes no sense to expect
constant-time response from the IESG.
My understanding
Ned,
I therefore have to question whether we are talking about the actual factors
that are _currently_ creating delays.
There is a long tail in the delay distribution that worries me. As an
indicator of this tail, there are 34 open DISCUSSes created by
former ADs. (er, 3 created by you...).
You
Joe Touch wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Narten wrote:
Well, there are always going to be judgement calls about whether something
is or isn't an end-run, which is where I would expect discuss
positions to come from on such documents.
Process-wise, this isn't right,
John C Klensin wrote:
...
In theory, 3932 changed almost nothing. The IESG asserted that it was
not going to do what it had been barred from doing all along, which was
holding up individual submissions (non-IETF documents) until they were
rewritten to match the tastes and preferences of any
it takes to get a document published.
IMHO, if the RFC editor was given the same latitude it had in 1997,
publication would
take weeks, not months or years. of course YMMV.
--bill
On May 15, 2005, at 4:55, Brian E Carpenter wrote:
This would be a good topic for the newtrk WG, I think,
since it is so
You've seen Danny's message with the results of asking the
question in a straightforward way - 20% of IESG nominees
say they would not have volunteered. Unlike Dave, I am
willing to believe them.
fwiw I responded Yes to Danny's question, but not
without careful thought and some hesitation.
This would be a good topic for the newtrk WG, I think,
since it is so specific.
Brian
James M. Polk wrote:
At 08:22 PM 5/14/2005 -0400, Will McAfee wrote:
I think the minimum time before a document can pass to another
standards-track state is ridiculously long. If an rfc is huge, I can
The IESG does not prescribe the use of any single syntax for format
definitions. It does require that documents making use of such
provide a normative reference to a document laying out the syntax.
The IESG recommends that authors choose a syntax for which automated
validation is available, as an
Hesham,
Soliman, Hesham wrote:
...
Even assuming that publishing candidate lists would result in
better-quality feedback and permit the Nomcom to make better
choices among plausibly-appropriate candidates, please look at
the other side. There are people in the community who, for
below...
Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Eric A. Hall writes:
On 5/10/2005 12:45 PM, Thomas Narten wrote:
One example (and I'm just using it because it was it comes to mind,
and one that I think is symptomatic of the broader problem):
October 15, 2004: IESG approves
Lars-Erik Jonsson (LU/EAB) wrote:
Joe delegation) or make their work smaller (by encouraging
Joe feedback to be directional - as in 'take to WG X' - rather
Joe than technical review).
Sam:
I'll certainly remember this when reviewing documents you author;)
Seriously, I think most people
This is a combined response to a number of messages under
the same subject field:
Ralph Droms wrote:
...
Which is why I suggest ADs provide technical input in open mailing lists
during last calls, to make sure their technical input is on the same
footing as everyone else's technical input. I
[EMAIL PROTECTED] wrote:
Brian, and others,
I do have experience of WGs that care about DS.
So do I. But this has not been the norm in my experience.
If you think back to when we were discussing a one-stage
standards track in newtrk, I at least was arguing for the
importance of interoperability
Dave Crocker wrote:
But I would suspect that we aren't careful enough for Chair
positions in being certain that the candidate has enough free time and
full support from their employer.
Not that it would guarantee anything, but it might be useful to have a
candidate for working group chair
Having finally read the list traffic up to date, I have a question.
Can anybody identify a *new* root cause problem at the same level
of abstraction as those identified in RFC 3774? Or is it the case
that (at that level of abstraction) we have only been re-discussing
the RFC 3774 problem set?
Jari Arkko wrote:
Brian E Carpenter wrote:
As Leslie noted (...) another tricky point is exactly when
the list is published and how nominations after that date
are handled.
Agreed. If you make the publication at the end of the
nominations period then its not useful as a tool for
other potential
Joe Touch wrote:
Brian E Carpenter wrote:
(John's long and interesting message severely truncated)
John C Klensin wrote:
... We may need
a way to have an experimental or probationary WG: to say to
a group we don't have much confidence in this, but you are
welcome to try to run with it and prove
John C Klensin wrote:
Ralph,
An interesting, obviously reasonable, and not-unexpected perspective.
But the question wasn't addressed just to you -- I think it would be
useful to hear from others, especially those who have put in a few terms
as WG chairs or doc editors, on this. What I've
I'll add to what John wrote below that we did discuss the potential
for another layer of management between ADs and WGs during the
IESG retreat (and that was actually before Keith's message).
It's clear that ADs have discretion to use directorates or
technical advisors, but nobody felt that
Harald Tveit Alvestrand wrote:
--On 8. mai 2005 23:54 +0200 Julian Reschke [EMAIL PROTECTED] wrote:
ISTR a case of a WG that got replaced its chair by the IESG, and told to
do its work differently, two or three times - and *every* time, the new
chair stopped posting to the list after a short
[EMAIL PROTECTED] wrote:
...
That assumes we care about moving stuff to DS. That wasn't at all
obvious during the discussion of 2774 and is by no means obvious
in the newtrk discussions.
The often-heard plaint that nobody cares about moving to DS or S has
always
struck me as confusing cause with
Bruce,
Do you think it's OK for the IESG to kick a draft right back to
the WG by saying
This is a mess and fundamentally wrong, but we don't have
time to tell you why, so you have to go find a reviewer. ?
This is a serious question... my concern is that this is a
surefire way to annoy the
Soliman, Hesham wrote:
At 01:10 PM 5/4/2005, Soliman, Hesham wrote:
One way to open up the process would be to allow any participant
to personally request a list of candidates from Nomcom, against
a personal non-disclosure promise. (Not my idea; this
was suggested
during
Pekka Savola wrote:
On Fri, 6 May 2005, Ralph Droms wrote:
What is the context of technical astuteness? How do you compare
people with different technical focuses? You can't.
Giving ADs a private veto (private in the sense of not discussed in
public) seems to compare technical astuteness and
Jari Arkko wrote:
Hi Keith,
Keith, you have been advocating a model where the IETF would be
stricter in allowing what work be taken up, in order to ensure that
we can actually deliver. But I share the same opinion as John L that
we should rather try to shape the IETF so that it can deliver what
(catching up on old stuff)
Eliot Lear wrote:
Margaret,
The words I hate most when I am in a WG meeting are these:
take it to the mailing list
That is usually short for we can't agree in person so we'll now
continue to disagree by email.
Sometimes it's short for We are out of time. In fact, I
Joe Touch wrote:
...
Nobody died and made the IESG cop. They took it upon themselves, and
that's not how things (should) work in the IETF.
I suggest you read RFC 2026 again.
Brian
___
Ietf mailing list
Ietf@ietf.org
(catching up after a few days in meetings, but it will
still take a while to read everything)
Dave Crocker wrote:
Brian,
1. Apparently you missed the extended, public exchanges about these
issues, over the last 3 years...
Here's a quick list of things that have been done. It's written in
1301 - 1400 of 1719 matches
Mail list logo
