Re: comments on <draft-mankin-pub-req-08.txt>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Sun, 14 May 2006, Dave Crocker wrote:
Craig Partridge wrote:
    * section 2, 2nd para "This draft only addresses those documents
    published by the IETF family.  These include IETF documents processed
    by the IESG, IAB documents, and IRTF documents processed by the IRSG."

    I don't think the IAB and IRSG are part of the IETF family.  If they
    are part of a family, it would be ISOC.  So I'd just say "This draft
    only addresses IETF documents processed by the IESG."

The IRTF certainly used to be parallel to, and independent of, the IETF. However, that has changed. In terms of both public perceptions and community operational interactions, the term "IETF" now subsumes classic IETF components, as well as the IAB and the IRTF.

On the other hand, your proposed language change probably characterizes this particular document more accurately.

Dropping IAB and IRSG out of this document's scope would likely demote those documents to second-class citizens (or drop them completely), which is likely not desirable. So, I think most folks would agree that such documents should be included in the scope, while language might be tuned.

That said, a couple of comments of my own. (I think the document is rather good as it is.)

...

In section 3.1 you say that early experience from early copy editing has been promising but the effectivess is still being evaluated -- yet still there is a requirement to technical publisher to provide such service. This seems a bit premature as we haven't even figured out yet whether it's worth the trouble. Maybe reword s/should perform/should be capable [or willing] to perform/ or the like..

In section 3.3, Req-POSTEDIT-5, s/will require..verbatim/may require..verbatim/ to emphasize that even if a particular text is a result of careful negotiation, marking it as "no-touch" is optional.

In section 3.9, Req-DOCCONVERT-2 says that the tech pub should accept supplemental source files, e.g., code, formal descriptions, graphics, etc. It's not clear to me where this comes from. What should it do with those in any case? Is this reserved for future proofing if the output format at some later date would be something other than ASCII. I'd expect that all the relevant material be in the input ascii files. Even a .PS source file format (for some RFCs) is ascii..

In section 3.16, Req-INDEX-7 says that the IETF can request publisher to purge a document from the index, and that it should remove all traces of the document. If the goal is removing all the traces of the document (from the sites under IETF control in any case), this requirement should also include removing the publication itself as well, not just removing it from a [web or tex] index (that's the way I understand "index").

I'd like to hear legal advice from the IETF legal counsel on this. Having this kind of option would likely increase the probability of requests to eliminate documents as it can be argued we have an established process to do so. So, I'm not sure if we need this, because court orders (etc.) should be compelling (or not) with or without such a requirement.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]