When considering the Last Call comments, the IESG finally
concluded that this document should be published as an ION.
Other Last Call comments will result in editorial changes.
Brian
___
Ietf mailing list
Ietf@ietf.org
This last call technically expires today. Since there were
objections to only holding a two week last call, it won't
be on the IESG agenda before March 8, and comments on
the substance are still most welcome.
I will be asking the IESG to consider whether it should
be published as an ION rather
Hi.
I will get to substance in a separate note, and hope others will
also. In the interim, two procedural remarks...
(1) This document and draft-klensin-rfc-independent-05.txt
describe two pieces of the how a document that does not
originate in a WG may be reviewed and published space. Each
Frank,
Don't they also set the pubreq bit in the I-D tracker ?
Very possibly, but that is just a progress tracking issue.
I agree we need a progress tracking mechanism, but that
isn't the underlying point here, which IMHO is to get the
author in discussion with the appropriate AD.
Brian
Frank
On 2007-02-10 01:07, Frank Ellermann wrote:
... I don't like this draft, send publication
request to secretariat is more attractive than spamming ADs.
You probably need to understand what happens when someone
does that. The Secretariat simply forwards the note to the
IESG. After a
Brian E Carpenter wrote:
send publication request to secretariat is more attractive
than spamming ADs.
You probably need to understand what happens when someone
does that.
Yes, I haven't tested it yet.
The Secretariat simply forwards the note to the IESG.
Don't they also set the pubreq
Jari Arkko wrote:
I would be happy to sponsor a ternary bit draft, but only on
April 1 :-)
IETF replaces 'bits' by 'tits', [EMAIL PROTECTED], it could be a case
where April 1st is no good excuse.
What I don't like in your draft is the (apparent) personal veto
right for the AD. Authors
Frank,
On 2007-02-09 17:04, Frank Ellermann wrote:
Jari Arkko wrote:
I would be happy to sponsor a ternary bit draft, but only on
April 1 :-)
What I don't like in your draft is the (apparent) personal veto
right for the AD. Authors (hopefully) have an idea about their
topic, but they
- Original Message -
From: Brian E Carpenter [EMAIL PROTECTED]
To: Frank Ellermann [EMAIL PROTECTED]
Cc: ietf@ietf.org
Sent: Thursday, February 08, 2007 10:12 AM
Subject: Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area
Director Sponsoring of Documents) to Informational
Well, when the question (ION v. informational) came up
within the IESG's discussion of the document, this
is what I offered:
On the ION v. RFC question -- I think this is *really*
teetering on the edge! I've copied below the
relevant section of draft-iab-rfc-editor-03. On
the one hand, this
Personally I've been convinced that this document definitely should
not be an informational RFC.
It should either be an ion or a bcp at the community's choice based on
how much review they want when the IESG decides to change things.
It doesn't make sense to me for the IETF to publish
Hi Tom,
There should be one document that is the starting point for those considering
the RFC and IETF processes, one that gives an even-handed treatment of the
available routes to varying outcomes,
Right. If you are thinking in terms of an educational
document, I'm not sure sure we have one
Frank,
What I don't like in your draft is the (apparent) personal veto
right for the AD. Authors (hopefully) have an idea about their
topic, but they don't need to be procedural experts. They don't
need to know what an area is, if it has a catchall WG or not,
and who the area directors are
--On Friday, 09 February, 2007 13:20 -0500 Leslie Daigle
[EMAIL PROTECTED] wrote:
Well, when the question (ION v. informational) came up
within the IESG's discussion of the document, this
is what I offered:
On the ION v. RFC question -- I think this is *really*
teetering on the edge!
A couple of comments, with the understanding that Brian and are
in substantial agreement about all of this and complete
agreement about the things I've left out.
--On Friday, 09 February, 2007 17:44 +0100 Brian E Carpenter
[EMAIL PROTECTED] wrote:
...
That's apparently a side effect of the must
On Fri, 09 Feb 2007 21:57:58 +0200
Jari Arkko [EMAIL PROTECTED] wrote:
In any case, at the end of the day there is going to be someone
who has to decide whether a particular proposal fits the purpose
of the WG, the IETF or the RFC series. This someone can be the
people in the WG, the
Jari Arkko wrote:
And as Brian noted, if this someone misuses their power for
personal reasons or some other reason, we have an appeals
process. I'm not sure there's fundamentally any other way
to handle this.
Nor me. Forcing them to either vote Yes for a document they
don't really like, or
Frank,
Not publishing it at all is an alternative.
And this is what we should do, if the community feels that
way. However ...
It would send an
unmistakable message to wannabe-authors, that they should use the
independent path, unless they're a friend of a friend of an AD.
I personally
Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg
at this time was made in part because we wanted to get the
two in sync. I think we are more or less in sync but the
remaining input should come from the community.
As for the
On 2007-02-08 01:25, Frank Ellermann wrote:
John C Klensin wrote:
If the IESG intends this document to merely represent the
particular procedures they intend to follow within the range of
alternatives over which they believe they have discretion, then
it should probably be published as an ION
John,
On 2007-02-08 00:02, John C Klensin wrote:
Hi.
I will get to substance in a separate note, and hope others will
also. In the interim, two procedural remarks...
(1) This document and draft-klensin-rfc-independent-05.txt
describe two pieces of the how a document that does not
originate
--On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko
[EMAIL PROTECTED] wrote:
Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg
at this time was made in part because we wanted to get the
two in sync. I think we are
John,
Sure. But my point in that area was obviously not clear. Prior
to the announcement of the Last Call, there was no indication to
the community that this document should be considered and
discussed, much less where.
Right. We weren't ready for a very wide discussion with
the earlier
John,
On 2007-02-08 13:16, John C Klensin wrote:
--On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko
[EMAIL PROTECTED] wrote:
Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg
at this time was made in part because
But its Informational. My read of RFC 2026 says that
the 4 week case applies to Standards Track only.
rfc 2026 says what must be done in some cases - it does not say what
can not be done in the cases it does not cover - specifically, RFC 2026
in no way would block a 4-week last call for an
Scott,
rfc 2026 says what must be done in some cases - it does not say what
can not be done in the cases it does not cover - specifically, RFC 2026
in no way would block a 4-week last call for an informational RFC
- note that RFC 2026 does not require any last call for informationals
On 2007-02-08 14:05, Scott O. Bradner wrote:
But its Informational. My read of RFC 2026 says that
the 4 week case applies to Standards Track only.
rfc 2026 says what must be done in some cases - it does not say what
can not be done in the cases it does not cover - specifically, RFC 2026
in no
John == John C Klensin [EMAIL PROTECTED] writes:
John --On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko
John [EMAIL PROTECTED] wrote:
Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg at
this
Jari Arkko wrote:
please complain!
That was the complaint, the draft is from an IESG POV, and it
explains how to deal with confused authors claiming that a
single bit is enough to count to three or similar cases.
But it doesn't address the POV of authors who want to get an
evaluation of their
--On Thursday, 08 February, 2007 10:19 -0500 Sam Hartman
[EMAIL PROTECTED] wrote:
John Sure. But my point in that area was obviously not
clear. John Prior to the announcement of the Last Call,
there was no
That sort of depends on what's going on here.
Is Jari's draft an
Hi Frank,
That was the complaint, the draft is from an IESG POV, and it
explains how to deal with confused authors claiming that a
single bit is enough to count to three or similar cases.
I would be happy to sponsor a ternary bit draft, but
only on April 1 :-)
But it doesn't address the
On Wednesday, February 07, 2007 10:20:54 AM -0500 The IESG
[EMAIL PROTECTED] wrote:
The IESG has received a request from the Internet Engineering Steering
Group (iesg) to consider the following document:
- 'Guidance on Area Director Sponsoring of Documents '
And we should ask this question every time we see an informational process
RFC last call...
The best reason to publish a process document as an RFC is because it will
be a BCP (IONs aren't BCPs). Since this one won't be a BCP, and given that
guidance could change over time, I'd think an ION
Hi.
I will get to substance in a separate note, and hope others will
also. In the interim, two procedural remarks...
(1) This document and draft-klensin-rfc-independent-05.txt
describe two pieces of the how a document that does not
originate in a WG may be reviewed and published space. Each
John C Klensin wrote:
If the IESG intends this document to merely represent the
particular procedures they intend to follow within the range of
alternatives over which they believe they have discretion, then
it should probably be published as an ION
Not publishing it at all is an
The IESG has received a request from the Internet Engineering Steering
Group (iesg) to consider the following document:
- 'Guidance on Area Director Sponsoring of Documents '
draft-iesg-sponsoring-guidelines-01.txt as an Informational RFC
The IESG plans to make a decision in the next few
36 matches
Mail list logo
