Bob,
Most of these comments are editorial matters that could easily
and properly be remedied by RFC Editor processing should the IAB
decide to publish. I'll incorporate them into the source if
the IAB tells me to, but am not feeling a strong need to discuss
them further. Exceptions are discussed below...
If you have further comments, please do not include the entire
text of the I-D: that just makes finding the real change
proposals harder for all of us.
--On Wednesday, 17 January, 2007 10:39 -0800 Bob Braden
<[EMAIL PROTECTED]> wrote:
> ----- Begin Included Message -----
>
> From [EMAIL PROTECTED] Wed Jan 10 12:47:23 2007
>...
> From: Bob Braden <[EMAIL PROTECTED]>
> Date: Wed, 10 Jan 2007 12:46:32 -0800 (PST)
> To: [EMAIL PROTECTED]
> Subject: Re: comments on draft-klensin-independent-05.txt
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
>...
> group, or *> the IESG, decline to publish it. In the
> latter cases, the review *> process is likely to be more
> efficient if the authors provide a
>
> s/is likely to be/will be/
I don't object to this change, but, since this has not been the
common practice, its contribution to efficiency is unproven.
> practiced over the years, it *> specifies some new
> arrangements in RFC Editor processing that will *>
> improve the balance between openness and independent decisions.
> I have a little trouble with "specifies new arrangements" -- I
> would prefer "clarify and documents procedures", but if you
> are going to say "new arrangements", it seems to me you need
> to summarize what the new arrangements are, so all parties can
> agree.
I'll leave this one to the IAB but (i) there are several
provisions in this document, including those about availability
of reviews, requests for reviews to the IAB, etc., that were
definitely new when the first draft of this document was posted
and (ii) several aspects of the "traditional" review process
remain fairly opaque to this day. For example, I note that one
recent document was sent to the IESG for formal (RFC3932) review
without being first circulated to the Editorial Board.
To put the issue I see here differently, if the RFC Editor
wanted to supply a precise description of the procedures that
were consistently followed before this document was written, I
would be happy to generate a section of this document that
describes the changes.
>...
> *> believe there is a high likelihood of conflicts or
> other interactions *> with IETF efforts (including
> believing that the document is one that *> the IESG
> should probably process), they may forward it to the IESG,
> *> or relevant ADs, for preliminary evaluation and comment.
>
> Comment: Nice theory, but in practice some IESG members have
> been less than responsive to such requests from the RFC Editor.
I presume from the above that some IESG members _have_ been
responsive. This is an optional step designed to save both the
IESG and the RFC Editor time. If the relevant AD(s) don't care,
then you move on to the next step, presumably pointing out to
the IESG when the 3932 review is requested that you tried to get
input earlier but didn't.
If you don't believe that the text is sufficiently clear on that
subject, please suggest alternate or additional text.
>...
> of *> the RFC Series or is not relevant to the areas that
> the series *> covers. Alternatively, the RFC Editor
> Staff may, at their *> discretion, iterate with the
> author on the document to improve its *> quality.
>
> Comment: While the above is factually correct, the community
> should be aware that the RFC Editor often expends considerable
> effort and sometimes 3-65 go-arounds with authors to get their
> submissions up to publishable quality. Unlike IETF documents,
> which have received considerable scrutiny before they are
> submitted to us, independent submissions are more likely to
> come from a single author, often isolated from the IETF, with
> revision level -00. We just like to receive credit for what
> we do.
If you believe some textual change to the document would be
appropriate, please suggest text.
> *> In addition to the IESG review for conflict with IETF
> work, *> individuals in the IESG, or in the broader IETF
> community, are free *> to review a draft and, if they
> have comments of any kind --including *> the extreme case
> of believing that the proposal is damaging to the *>
> Internet as a whole-- these comments should be directed to the
> *> authors and the RFC Editor.
>
> Comment: a balanced document would include transparency
> requirements on the IESG, in this process, although that is
> covered elsewhere, I guess.
In response to comments on earlier drafts, the current version
of this document has been constructed to avoid imposing
requirements on the IESG beyond those to which the IESG has
already explicitly committed (and to avoid commenting on the
latter).
>...
> *> 6.1. Documents in process or rejected
> *>
> *> For documents in process, reviews may be made public
> and posted on *> the RFC Editor web site at the request
> of the author. The names of
>
> I don't understand this discussion of documents in progress.
> There is a bit of a time warp here. The RFC Editor (or the
> author) cannot know whether 6.1 or 6.2 applies until the end
> of the review process, so reviews cannot be posted until that
> time, if at all. The time warp gets worse if the author
> appeals to the IAB.
>
> Question: Section 6.2 says the RFC Editor has an option of not
> posting a review, but there is no such statement for 6.1; is
> the implication that the RFC Editor is obliged to publish
> negative reviews? Must the reviewer(s) be identified?
Please indicate how you would like this to be clarified, ideally
with text.
>...
> the Editorial Board, and the RFC *> Editor; such
> communications will remain confidential. At minimum, *>
> the author of either an accepted or rejected document shall
> receive a *> written summary of the review(s).
> *>
>
> The last sentence above seems important enough to appears much
> earlier and not be an afterthought.
s/appears/appear/??
Please suggest where you would like it or leave this for the
final editing process.
thanks for your careful reading.
john
_______________________________________________
INDEPENDENT mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/independent
