See my opinions below: Stephen
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Spencer Dawkins > Sent: Thursday, January 26, 2006 6:17 PM > To: [email protected] > Subject: [Techspec] Questions on draft-mankin-techspec-pubreq-03 > > > This really looks good. I have a few short questions: > > - In 3.2 Discussion - does the technical publisher have to > take steps to > make sure that a draft remains available for more than 6 months? SH: I don't think anything is needed from the technical publisher. This is primarily used by other SDOs where the outside world doesn't have access to the draft documents until actually published. It isn't intended to be a version you would reference, so I don't think there is a need to make sure the last draft remains available. > > - Current Req-REFVAL-2 - Is the IETF responsible for > forwarding documents > with resolved references, or is the technical publisher > supposed to catch > these? (I thought IESG was trying to keep from approving > documents with > unapproved normative references, for example) SH: This was meant to be more than a check on IETF references. While the IESG can choose to hold back docs with in progress IETF references, we probably don't want them to spend time that all the listed references are actually available. So this is still needed even if the IESG decides to hold docs up awaiting normative IETF references. > > - In 3.6, why is technical publisher involved with IANA? (Is there an > interface between technical publisher and IANA that we don't > see from the > IETF?) SH: In the current process, IANA works on the IANA considerations and then the technical publisher plugs those values into the document. That is what this was intended to represent. So it is one additional source of change that occurs after approval of the document. > > - In 3.8 - do we care if there are identifiers that get > allocated but don't > get used (document is withdrawn, or something similar)? SH: It doesn't seem to be a problem to me to have gaps. The identifiers need to be unique and permanent. In my opinion, having them semantically meaningful would be more important than ensuring no numbering gaps. > > - In 3.12, we say "used sparingly" for expedited handling, > but we do pick > numbers for metrics elsewhere. Would it make sense to name a > percentage of > documents that may be expedited in normal operation? SH: Glad to put in a number, does anybody want to volunteer a number? How about 1%? I was hoping that if we can get the publication time down, we could remove this requirement all together. > > - In 3.17, is full-text search required? SH: That seems to be a detail that can be worked out later, but I think full text search would be useful. > > - In 3.19 - I note that we are spending time looking at lists > of "the oldest > documents in specific status" elsewhere - include exception > reporting as a > requirement? SH: This section is primarily intended for metrics for measuring performance. I think that what you want is covered under section 3.11 (Potential Req-STATUSTRK-3 - The IETF technical publisher should provide external visibility of not only the fact that a document is in an extended waiting period, but also the token-holder and circumstances of the wait. ) > > Thanks! As I say, it's looking good. > > Spencer > > > > _______________________________________________ > Techspec mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list [email protected] https://www1.ietf.org/mailman/listinfo/techspec
