Subject: [Techspec] Re: I-D ACTION:draft-mankin-pub-req-03.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jan 2006 15:24:54 +0100

With my IAOC hat on, I'm delighted with this draft - lots
of rather precise items that will help prepare the RFP.

Now here are my *personal* comments on the text.
(I could have split this into 9 separate messages
but that seemed over the top.)

> 3.8. Allocation of Permanent Stable Identifiers

Something needs to be said about the assignment of STD numbers
and STD names. I don't know if it fits here, but either it
has to be specified as an action by the publisher, or this job
has to be moved into the IETF process.

...
>    o  Potential Req- PERMID-2 - The IETF technical publisher should 
>       permit early allocation of stable identifiers for or by the IESG 
>       to satisfy referencing requirements of external bodies. 

Should the two-month appeal period be mentioned here?

> 3.9. Document Format Conversions 
...
>    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.

There has to be something wrong there. When the PS or PDF version
contains graphics etc, surely the publisher must have accepted
another format than pure ASCII?

> 3.11. Publication Status Tracking

Should we also have a requirement to include normative reference
chains in the status tracking?

> 3.13. Exception Handling 

...
>    o  Current Req-EXCEPTIONS-2 - The IETF technical publisher should 
>       have the discretion to reject publication of an independent 
>       submission based upon feedback from reviewers. 

I don't think this is properly called an exception, and I think it
very much over-simplifies the issue - see my earlier message on
this topic.

>    o  Current Req-EXCEPTIONS-3 - The IETF technical publisher should 
>       permit documents to be put on hold awaiting the outcome of an 
>       appeal. 

Add: or a legal process.

> 3.15. Post Publication Corrections 

We need to say something about technical vetting of errata. They
can't just be published without checking them.
Is this a task for the publisher? Does the publisher need IETF support
for this?

> 3.16. Indexing: maintenance of the catalog 

I believe there is an important missing piece here, i.e. the creation
and maintenance of the hyperlinked index
(http://www.rfc-editor.org/rfcxx00.html today).

> 3.21. Tutorial and Help Services

Missing requirement: responding to indvidual email queries (with a ticket system)

> 4.1. Post-approval timeframes 
> 4.2. Publication Throughput

I think the metrics should include median dwell times as well as the 90th percentile
and throughput.

     Brian

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Jan 2006 10:21:05 -0800

>chains in the status tracking?

Yes, definitely. This helps people looking at the queue to understand 
why a document is not being worked on by the editor.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Jan 2006 10:29:28 -0800

>can't just be published without checking them.

Fully agree. I recently had an issue where a disgruntled WG member 
who wasn't getting his way actually said "OK, I'll just get this as 
an errata after the RFC is published".

>Is this a task for the publisher? Does the publisher need IETF support

It depends on whether or not you want the publisher to do technical 
evaluation work, or whether they really are a publisher. If we follow 
Brian's suggestion for a independent review board (IRB) and take the 
independent submission vetting out of the hands of the publisher, 
then the IRB could also vet any non-editorial errata as well. That 
seems like a clear separation of duties that would make it clearer 
what the published does and does not do. In the past few years, the 
number of non-editorial errata is quite small, so this should not add 
much work to the ERB.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Margaret Wasserman" <[email-masked]>
Date: Wed, 18 Jan 2006 13:35:49 -0500

Hi Paul,

> It depends on whether or not you want the publisher to do 
> technical evaluation work, or whether they really are a 
> publisher. If we follow Brian's suggestion for a independent 
> review board (IRB) and take the independent submission 
> vetting out of the hands of the publisher, then the IRB could 
> also vet any non-editorial errata as well. That seems like a 
> clear separation of duties that would make it clearer what 
> the published does and does not do. In the past few years, 
> the number of non-editorial errata is quite small, so this 
> should not add much work to the ERB.

Actually, I think it would make more sense for the IRB to vet errata for
independently published documents (ones they approved in the first place)
and for the IETF (either the pertinent WG if it still exists, or the area
directors?) to vet technical errata to IETF publications.

Margaret

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Jan 2006 12:01:34 -0800

>directors?) to vet technical errata to IETF publications.

Sounds fine. That leaves out the independently published documents 
that were approved by the RFC Editor before the IRB appeared, but the 
number of errata for those is probably quite small and can be handled 
by the IRB as well.

--Paul Hoffman, Director
--VPN Consortium

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 19 Jan 2006 19:15:35 -0500

I *assume* individual submissions that go to an AD
are considered IETF technical specifications (otherwise,
why is the IESG spending time on them?).

So then,

> very much over-simplifies the issue - see my earlier message on

Req-EXCEPTIONS-2 doesn't belong in this document, as far as I can tell.

Leslie.