--On Monday, 10 November, 2008 11:19 -0500 Russ Housley
<[EMAIL PROTECTED]> wrote:
> John:
>
> In the previous note from me, I responded to you and Jari on
> your main points. In this note, I am responding to your
> editorial points.
>
>> Textual nit-picking
>>
>> * The second full paragraph
At 08:19 10-11-2008, Russ Housley wrote:
To make them all parallel in structure, the first numbered item in
section 3 becomes: "1. The IESG finds no conflict between this
document and IETF work."
In RFC 3932, these numbered items (except the first one, which is
the same until the modification
To make them all parallel in structure, the first numbered item in
section 3 becomes: "1. The IESG finds no conflict between this
document and IETF work."
In RFC 3932, these numbered items (except the first one, which is
the same until the modification above) begin "The IESG
thinks" During
Russ,
FWIW, I can live with this formulation. I would still prefer to
get rid of "harmful"... see below.
--On Thursday, 13 November, 2008 12:41 -0500 Russ Housley
<[EMAIL PROTECTED]> wrote:
>
>>> To make them all parallel in structure, the first numbered
>>> item in section 3 becomes: "1. The
John:
I am pleased to go with:
The IESG has concluded that publication could potentially disrupt the
IETF work done in WG and recommends not publishing the
document at this time.
Thanks for the suggestions.
Russ
At 01:01 PM 11/13/2008, John C Klensin wrote:
Russ,
FWIW, I can live
I am pleased to go with:
The IESG has concluded that publication could potentially disrupt the
IETF work done in WG and recommends not publishing the
document at this time.
I'm OK with this as well.
Jari
___
Ietf mailing list
Ietf@ietf.org
https://
I am bringing this draft to its second last call. After the completion
of the headers and boilerplates document and extensive discussions
within the IESG, it has become clear that several ADs had an issue with
the 3932bis draft. I have asked Russ to post a new version which I
believe resolves t
And to start off the comments, I wanted tell my personal opinion about this.
First, I have not been extremely happy with either the h&b or the
3932bis document, as some people who have been reading the various lists
may gather. However, I think they were already good enough to be shipped
befor
The changes described in your other note (copied after your text to
preserve context) are reasonable in the abstract. However, the devil is
in the details.
As I understand it, the reason for calling the extra note "exceptional"
is that the IESG has in the past sometimes used that note to place
Joel,
However, the devil is in the details.
As I understand it, the reason for calling the extra note
"exceptional" is that the IESG has in the past sometimes used that
note to place far more pejorative language than you suggest, in places
that it really does not belong. That can turn a reaso
--On Monday, June 01, 2009 18:30 +0300 Jari Arkko
wrote:
> Joel,
>
>> However, the devil is in the details.
>> As I understand it, the reason for calling the extra note
>> "exceptional" is that the IESG has in the past sometimes used
>> that note to place far more pejorative language than yo
--On Monday, June 01, 2009 17:47 +0300 Jari Arkko
wrote:
> I am bringing this draft to its second last call. After the
> completion of the headers and boilerplates document and
> extensive discussions within the IESG, it has become clear
> that several ADs had an issue with the 3932bis draft. I
John,
The IAB and the RFC Editor have made updates to the formatting
of the title page for all RFCs [N3]. With these changes, the
upper left hand corner of the title page indicates the stream
that produced the RFC. This label replaces some of the
information that was previously provided in manda
The IAB and the RFC Editor have made updates to the formatting
of the title page for all RFCs [N3]. With these changes, the
upper left hand corner of the title page indicates the stream
that produced the RFC. This label replaces some of the
information that was previously provided in mandatory I
--On Monday, June 01, 2009 21:47 +0300 Jari Arkko
wrote:
>> As written, this violates provisions of RFC 4846 as well as
>> some of the language in the current RFC Editor Model draft.
>> The IESG may _request_ that notes or other language be added.
>
> Indeed -- thanks for catching this. It sho
On 1 jun 2009, at 16:56, Jari Arkko wrote:
I do think though that additional information at the level of "This
RFC describes FOO. A standardized version of FOO can be found from
RFC ." is useful. I think -07 version of the 3932bis is an
improvement over the previous one, and should be
On Jun 2, 2009, at 8:03 , Olaf Kolkman wrote:
RFC4846 section 5 uses the word "recommend"
If the IESG, after completing its review, identifies issues, it may
recommend explanatory or qualifying text for the RFC Editor to
include in the document if it is published.
Olaf, I believe this
RFC4846 section 5 uses the word "recommend"
If the IESG, after completing its review, identifies issues, it may
recommend explanatory or qualifying text for the RFC Editor to
include in the document if it is published.
Olaf, I believe this means in the contents of the document. I am unde
On 2009-08-28 03:56, Russ Housley wrote:
>
>>> RFC4846 section 5 uses the word "recommend"
>>> If the IESG, after completing its review, identifies issues, it may
>>> recommend explanatory or qualifying text for the RFC Editor to
>>> include in the document if it is published.
>>
>> Olaf, I
I am under
the understanding the the IESG Note in RFC is provided by the IESG not
by the RFC Editor. Is there a document that says otherwise? (I'm
certainly open to the possibility that perhaps these documents should
not have an IESG note but that seems a different issue)
My understanding o
On Aug 28, 2009, at 4:13 AM, Dave CROCKER wrote:
I am under
the understanding the the IESG Note in RFC is provided by the
IESG not
by the RFC Editor. Is there a document that says otherwise? (I'm
certainly open to the possibility that perhaps these documents
should
not have an IESG no
I'm happy with this version. I think it updates the procedures in
accordance with what we've learned since RFC3932.
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--On Tuesday, 21 October, 2008 08:02 -0700 The IESG
<[EMAIL PROTECTED]> wrote:
> The IESG has received a request from an individual submitter
> to consider the following document:
>
> - 'IESG Procedures for Handling of Independent and IRTF Stream
>Submissions '
> as a BCP
Russ, Harald
At 07:02 21-10-2008, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'IESG Procedures for Handling of Independent and IRTF Stream
Submissions '
as a BCP
The IESG plans to make a decision in the next few weeks, and solicit
John,
That was a long list of issues.
Let me start off by saying that RFC 3932 is already a part of the daily
procedures we operate on. Draft-housley was written to make an
incremental improvement on it. This incremental improvement is the
publication of the headers and boilerplates document,
John & Jari:
Let me start off by saying that RFC 3932 is already a part of the
daily procedures we operate on. Draft-housley was written to make an
incremental improvement on it. This incremental improvement is the
publication of the headers and boilerplates document, which allows
us to simpl
SM,
Thanks for your review and thank you Russ for the edits. I'll just
comment on the one remaining issue:
"3. The IESG finds that publication is harmful to the IETF work done
in WG and recommends not publishing the document at this time."
I don't think that harmful is appropriate here. I g
John:
In the previous note from me, I responded to you and Jari on your
main points. In this note, I am responding to your editorial points.
Textual nit-picking
* The second full paragraph of the Introduction ("The IETF is
responsible..."), second sentence, should read "..., and any
other I
Thanks for your review. My responses below.
The IESG has received a request from an individual submitter to consider
the following document:
- 'IESG Procedures for Handling of Independent and IRTF Stream
Submissions '
as a BCP
The IESG plans to make a decision in the next few weeks, an
Hi Russ,
At 14:10 09-11-2008, Russ Housley wrote:
Not all Informational and Experimental documents are
standards-related. Some are. Not all Informational and
Experimental documents are published as part of the IETF
stream. Some are. I'm not sure what text change would help add clarity.
I
Hi Jari,
At 03:33 10-11-2008, Jari Arkko wrote:
The issue is that mere conflict with work in a WG is not a
sufficient reason to recommend against publishing. The IESG needs to
make a judgment call that such publication would actually be harmful
to the standardization process in the WG. For inst
31 matches
Mail list logo
