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