Subject: RE: [Techspec] Review of draft-mankin-pub-req-04

From: "Stephen Hayes (TX/EUS)" <[email-masked]>
Date: Tue, 7 Mar 2006 16:37:31 -0600

My response to Eric's comments inline.

Stephen
> 
> Overall, this document seems pretty sound. I've got one meta-issue
> and a bunch of smaller issues. The meta issue is the labelling
> of the requirements. You have "current" and "potential" but I
> think it would be good to distinguish three cases:
> 
> 1. Requirements that you believer are commonly accepted.
> 2. Requirements that you believe we currently have but that
>    not everyone agrees with.
> 3. Requirements that you're proposing we may or may not need
>    sometime in the future.
> 
> It's not clear to me whether "Current" embodies both (1) and (2)
> or...
> 
My idea was to eventually drop the "current" and "potential" designation.  We ultimately only want to have just requirements.  The designation of current and potential was just to help people understand the requirements in terms of what we are currently doing and what is newly proposed.  I think once we have decided which ones to keep we will just have requirements.

If it is a requirement which we intend to phase in or which we plan to phase out, then that is something we should probably indicate in the text since we need to specify the conditions for phasing in or phasing out the requirement.

> 
> Figure 1 could use a little clarification, since the actual
> IANA parameter assignnment is done after approval, no?
> 
Your concern seems logical.  Any objections to moving the IANA into the post approval part of the diagram?
> 
> S 3.3:
> Can you define "substantive" changes please. Do you mean "significant"
> or "ones that affect the actual meaning of the documents"?
> 
Rather than trying to pin down the boundary of substantive, can we could probably just remove the word "substantive" from the sentence.  The logic remains the same.  Allison, do the statistics need to change if we remove "substantive"?

> I don't understand the difference between Req-POSTEDIT-3 and 
> Req-POSTEDIT-4.
> 
I agree they are close.  They are intended to control two different aspects of editorial behaviour by the publisher.  POSTEDIT-3 is targeted for stylistic changes such as formatting, numbering, etc. to achieve consistency with other published documents.  POSTEDIT-4 is intended to control behavious associated with improving the text so it reads better or has better grammar (and thus risk destroying consensus wording).  People had different views on how much to suppress each of these behaviours so they are captured in two separate requirements.  The boundary between them is pretty vague but I am not sure it does any harm to have two separate requirements so the wording can be tweaked independently.
> 
> S 3.7:
> 
>    o  Potential Req-POSTCORR-3 - The IETF technical publisher should 
>       have the discretion to reject post-approval corrections as too 
>       late in the process and propose that it be handled as errata. 
> 
> I'm not sure I agree with this. Fundamentally, that seems like the
> kind of discretion that should rest with the IESG. The publisher
> can of course say "this will require reflowing the document" or
> "this will delay the document X weeks" but up until the moment
> of publication I'm not sure why IESG shouldn't be able to direct
> changes.
> 
Ultimately, the publisher should be at the command of the IESG.  But this is analogous to the 11th hour appeal.  If the document is ready to be published, there will be a process in the publisher to put it in the index and announce its availability.  At what point can the IESG say "Stop"?  Maybe it's like the movies and stopping the process is ok as long as they can rush in, throw themselves across the room, and stop the publisher from hitting the "Enter" key.  
> 
> S 3.9:
> 
>    o  Current Req-DOCCONVERT-1 - The IETF technical publisher should 
>       accept as input ascii text files and publish documents as ascii 
>       text files, postscript files, and pdf files. 
> 
> I think this needs some clarity. It's one thing to publish 
> the documents
> in PDF file that looks exactly like the ASCII, as RFC-Ed does now. But
> that's not really what most people would expect when they wanted it
> done in PDF or PS. 

True, this was just to capture the current practice.  The wording can be clarified to indicate that.  If we want them to do more, then we should probably add a new potential requirement.  I really didn't want techspec to become mired in the "what formats should be allowed" discussion so I didn't add any new requirement here except for xmltorfc (DOCCONVERT-2).
> 
> 
> S 3.12:
> 
>    approving organization to request expedites publication of a 
> 
> This should read "expedited", no.

Correct
> 
> 
> 
> S 4:
> I'm not sure I agree that this kind of metric granularity is
> appropriate in this document. I would prefer it set general
> policy and leave the IAD/IASA to formulate specific metrics
> in the technical publisher contract as appropriate.
> 
See the improved wording in version 05.
> 
> S 7.
> 
>    There is a tussle between the sought-for improvements in 
> readability 
>    and the specific language that has often been negotiated carefully 
>    for the security content of IETF documents.  As with other text, 
> 
> I'm not sure I would use the word "tussle" here. There's a tension,
> true, but a tussle involves divergent interests, which isn't quite
> what's going on here.

I am happy to change it to "tension".

_______________________________________________
Techspec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/techspec

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Mar 2006 15:36:17 -0800

At 4:37 PM -0600 3/7/06, Stephen Hayes (TX/EUS) wrote:
>Ultimately, the publisher should be at the command of the IESG.

I think that might be "pentultimately"; ultimately, isn't the 
publishers at the command of IASA?

>But this is analogous to the 11th hour appeal.  If the document is 
>ready to be published, there will be a process in the publisher to 
>put it in the index and announce its availability.  At what point 
>can the IESG say "Stop"?  Maybe it's like the movies and stopping 
>the process is ok as long as they can rush in, throw themselves 
>across the room, and stop the publisher from hitting the "Enter" key.

Fully agree. But, in the movie scenario, if the publisher sees the 
IESG collectively throw themselves across the room (well worth the 
price of admission alone!), the publisher would take its finger off 
the button. The wording of Req-POSTCORR-3 doesn't reflect that. A 
more accurate wording might be:

    o  Potential Req-POSTCORR-3 - The IETF technical publisher should
       have the discretion to publish the document as soon as all
       the parties that must approve the final document have done so.

This allows the IESG can dramatically leap in at any point before 
publication. Further, if the IESG wants the discretion to make 
changes in the document, it might make itself one of the parties that 
must approve the final document, most likely through one or more Area 
Directors. That is already the case now for any WG document and 
(possibly) any individual submission that has a sponsoring AD. The 
IESG and IASA can figure out exactly what the rules should be here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 14 Mar 2006 19:20:09 -0500

(Catching up)

> the post approval part of the diagram?

Actually, I don't think that's the right choice.  There is
IANA review of the text *before* approval.  It is an explicit
step of the review, and can cause text to change in the document;
the document is not approved until IANA nods that the text
is clear enough to instruct them.

The work of the IANA *after* approval is almost immaterial to
this process -- or, at most, it involves filling in values that
are not known until IANA actions are completed.

So -- at most, note IANA on both sides of the approval line,
but certainly we need to retain the pre-approval instance.

Leslie.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Mar 2006 13:31:34 +0100

> but certainly we need to retain the pre-approval instance.

Exactly. I can't be bothered to count but I would say probably
20% of drafts need some clarification or explanation for
IANA during IESG evaluation. It's not unusual for a problem
noticed by IANA being sufficiently serious that an AD places
a DISCUSS on behalf of IANA.

Typically, the pre-approval review by IANA is to figure out
if the instructions to IANA in the document are unambiguous,
complete and actionable. The post-approval stage is different:
actually creating a new registry if needed, and assigning
values to the TBDs in the draft.

    Brian