Margaret Wasserman wrote:
If an AD or the IESG makes a mistake, there is also an appeals mechanism
available. There isn't any documented appeals mechanism for IAB decisions.
Should there be?
Depends for what. Standards related actions? Sure. Contracts and
liaison decisions? No, other
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
If the individual submission is approved as an Experimental RFC, does that
mean that the IETF will adopt the proposed experiment? If so, I don't
think this draft should be approved.
--On Thursday, 01 June, 2006 10:49 -0400 Eric Rosen
[EMAIL PROTECTED] wrote:
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action.
If the individual submission is approved as an Experimental
RFC, does that mean that the IETF will adopt
John,
In your choices below, choice i and ii are not quite
separable. In the do nothing mode i, eventual advancement
required to de-queue the would-be Draft Standard will only
happen if choice ii is in effect. In other words, choice ii
is effectively the same as choice i except that the
Eric (Rosen),
Irrespective of opinions about the nature of the current
process, if one RFC is advanced significantly ahead of another
one that it has a normative dependency on, it is possible that
the state of the art will migrate between one advancement, and
the other.
In the
that text is not derogatory, but a simply statement of fact.
Sorry, but however you may try to talk your way out of it, a statement like
that technology may be unstable is derogatory.
Until and unless the definitions of maturity levels are changed, that text
is not derogatory, but a
Reading this, a few items caught my eye.
The POSTEDIT requirements seem to be worded as if it is desirable to
minimize the changes that the document editor makes, or even the
changes the document editor can make. The general tone of don't
mess with the words we have carefully honed is
Folks, in the interest of keeping it simple, I withdraw the proposed
text -- I'll just submit a follow up paper using Russ's draft as a template.
-Angelos
[EMAIL PROTECTED] wrote:
Russ,
I don't think this is good use of informative text. Other
standards bodies often mark some sections of a
Previously, someone wrote:
I finished reading the RFC editor document and have one major concern.
Ultimately, the rfc-editor function needs to be accountable to the
IETF community because we're the ones paying for it.
Incorrect. As I pointed out some weeks ago, and Leslie has
recently
On Thu, May 25, 2006 at 06:42:06AM -0700, Lucy E. Lynch wrote:
On Thu, 25 May 2006, Harald Alvestrand wrote:
Lucy E. Lynch wrote:
Let me try re-stating my question. Is there a one-to-one relationship
between the listed authors on an IETF document and ownership of the
given document's
I'd like to second this. The adjacent IETF and IEEE 802 meeting in
Vancouver in November 2005 was quite convenient and cost saving for me.
As long as they are adjacent in time and on the same continent, there
are savings. It is much better if they are in the same city. And, I
suspect, if things
I have read both PANA protocol and PANA framework drafts. I understand
the concept and it seems to me an useful protocol. In particular, EAP
over IP is necessary, IMO, and my understanding is that PANA base protocol
is all about EAP over IP. The framework document should be an informational
Dave Crocker wrote:
I would find it particularly helpful to have a concise statement from
someone who says that PANA will not work. Cannot be implemented
(properly) by virtue of technical errors or documentation too
confusing to understand. Or cannot be deployed and used, by virtue of
Joel,
Please see my comments below...
--
Eric
-- -Original Message-
-- From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
-- Sent: Wednesday, May 24, 2006 4:11 PM
-- To: ietf@ietf.org
-- Subject: Re: LC on draft-mankin-pub-req-08.txt
--
-- Reading this, a few items caught my
*
*Bearing in mind that asking someone to refrain from
* doing something is a far cry from prohibiting it, see my
* comment above.
*
Sorry, I don't get that fine distinction. Are you saying, Don't
do your job most of the time? Wierdness abounds here.
Bob Braden
Bob,
Weirdness?
No part of the RFC Editor's job has ever involved
deliberate modification of text that reflects a carefully
crafted compromise position. In the past, when any such
modification has occurred inadvertently, it would usually
have been reversed during an Auth48.
*
* People should refrain from allowing their passion for precise
* terminology usage to prevent essential communication from
* ever taking place
*
That statement incorporates an assumption that is not true. I vaguely
recall that you can prove anything starting from a false
Bob,
To me, this is a perfectly sensible discussion, and my
analogy was perfectly reasonable.
Joel suggested that refraining from making changes that
might result in altering phraseology that was carefully arrived
at was effectively prohibiting the technical editor from doing
the
There are two (2) Internet-Draft cutoff dates for the 66th
IETF Meeting in Montreal, Quebec, Canada:
June 19th: Cutoff Date for Initial (i.e., version -00)
Internet-Draft Submissions
All initial Internet-Drafts (version -00) must be submitted by Monday,
June 19th at 9:00 AM ET. As always,
The IESG has received a request from the Global Routing Operations WG to
consider the following document:
- 'Operation of Anycast Services '
draft-ietf-grow-anycast-03.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please
20 matches
Mail list logo
