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 protected] https://www1.ietf.org/mailman/listinfo/techspec
