Subject: [Tools-team] Secretariat Comments on draft-ietf-tools-draft-submission-07

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 16 Mar 2005 16:28:02 +0100

Hi,

    As I've mentioned earlier, we've received comments from the
secretariat on the draft, and on Harald's request I met up with
Barbara and Mike in Minneapolis to go over their comments.  You'll
find their comments, with my initial responses below, with added
annotations from the meetings inline.

	Henrik

-------------------------------------------------------------------

>>Comments on "Requirements for IETF Draft Submission Toolset"
>>draft-ietf-tools-draft-submission-07
>>1. Section 3, "Scope"
>>Notification and expiration/archiving of old draft versions may be out
>>scope for this toolset.  However, the toolset must be compatible with the
>>Secretariat's tools for sending notifications and creating tombstones.
>
>Agreed.

Ok

>>2. Section 4, "Notation and Terminology"
>>WG draft:  All drafts that are WG drafts begin with "draft-ietf."  However,
>>not all drafts that begin with "draft-ietf" are working group drafts.  (Also
>>see comment #6b.)
>
>The usage of this definition within the requirements document means that
>the document does not require that the tool recognize WG drafts on any other
>basis than the "draft-ietf-" prefix.  If you feel that it is necessary to
>use a more complex lookup or algorithm to recognize WG drafts, I think that
>would be OK; however I'm not sure that it would actually be necessary for
>this tool to have that ability.
>
>Maybe it would be better to use some other term than "WG Draft" here - maybe
>we should call it "A draft following the WG draft naming convention" ...
>although that is maybe a bit long ,:-)

Agreed to try to find another expression than "WG drafts" for drafts which
are named "draft-ietf-", and update the document accordingly.

>>3. Section 6, "Overall Toolset Operation"
>>(a) Manual adjustment and posting
>>It is not clear why manual adjustment of meta-data and manual posting are
>>linked.  That is, why is it *mandatory* that manual adjustment of meta-data
>>be followed by manual posting by the Secretariat?  The option to post
>>manually should always be available.  However, the option to adjust metadata
>>and post automatically should also be available.
>
>Ok, if this is not clear then it needs more explanation in the draft; but
>if I briefly try to explain how we have been thinking, then maybe we can see
>if this requirement makes sense or not.  Below:
>
>>If the submitter finds an error in the extraction process, i.e., the
>>meta-data are stated accurately in the draft but the extracted meta-data are
>>incorrect, then the author should be able to correct the errors in the
>>extracted meta-data, compare the extracted meta-data to the meta-data in the
>>draft, and proceed with the submission when both are accurate and identical.
>>If the submitter believes that the extraction process is not functioning
>>properly, then the submitter should send a bug report to the Secretariat.
>>(Also see comments #10 and #11.)
>
>Ok, so we have different cases cases:
>
>1. The meta-data extraction works correctly.  In this case, it would be wrong
>   for the tool to permit any changes to the meta-data; as any such changes
>   would be undesirable, as the meta-data in the draft and the extracted meta-
>   data should be in agreement.  So
>
>     a) The data in the draft are correct, the meta-data is correct, no
>        changes should be needed.
>
>     b) The data in the draft are incorrect.  The submitter should correct
>         the draft and return to submit the corrected draft, with correct
>         meta-information, which will be extracted correctly.  Permitting
>         manual changes to the extracted meta-information instead of
>         requiring re-submission of a corrected draft would be less
>         desirable, as the draft would then quite unnecessarily contain
>         incorrect information.
>
>2. The meta-data extraction does not work correctly.  This is a bug and needs
>   fixing, and should be bug-reported.  In this case, we have 2 possibilities:
>
>     a) Until the extraction bug is fixed, drafts that cannot be handled
>         correctly by automatic automatic submission has to be forwarded 
> by the
>         tool for manual handling (as a human will be able to extract the
>         meta-information correctly even if the tool cannot do it yet)
>
>   or
>
>     b) We can permit automated posting; but in order to permit automated
>        posting, we need to i) accept modification of extracted meta-data
>         and ii) remove the requirement that extracted meta-data match what
>         is in the draft.
>
>         We see both of these as undesirable, because it opens the door to
>         mismatching meta-information between data-base and drafts.
>         It also permits wilful mis-representation, which is not a problem for
>         genuine IETF submitters, but makes it possible to mis-use the tool in
>         a manner similar to Wiki Spam: if it is possible to get around the
>         various checks in the automated tool, it is possible to post spam
>         ("Advertisements") much more easily, for people who have no 
> interest in
>         the IETF, but are willing to do anything to get out their message.
>         This is not a problem when postings pass through human hands, but 
> with
>         a fully automated tool we have to consider this possibility, and
>         preferably arrange things so that it doesn't become a problem.
>
>>(NOTE: If the submitter finds an error in the meta-data as stated in the
>>draft itself, then the submitter should cancel the submission, correct the
>>error, and resubmit.
>
>Agreed, this makes sense and is what we also had in mind.
>
>>The Secretariat staff rarely corrects errors in
>>meta-data within a draft.  If a filename, or version number, or author's name
>>is incorrect, then the Secretariat normally asks the submitter to correct the
>>error and resubmit the draft.  Only when (i) the error is minor, AND (ii) the
>>Secretariat staff is 100% certain that it is an error, AND (iii) it is crunch
>>time does the staff correct an error within a draft.)
>
>Makes sense to me!

This item took some time to resolve, but in the end it was accepted
that automatic submission should not be done if metadata was changed.
The tool needs to make clear that the secretariat will not accept meta-
data which is different than those given in the draft, so if the
extracted data needs tweaking, and there is no extraction error, the
data should be corrected in the draft, and the draft re-submitted.

>>(b) Hosting the toolset at an open-source-friendly project management site.
>>Should "toolset" be changed to "source code"?  It does not make sense for
>>the toolset to be hosted at such a site since the Secretariat will need to
>>modify the toolset from time to time to accommodate changes in procedure,
>>requests for new features, etc.
>
>Quite correct, the intention was to have the source code open, not to host the
>tool elsewhere.

Should be corrected in the docment.

>>4. Section 7, "Upload Page"
>>The Secretariat does not currently accept XML submissions.  The Secretariat
>>can move towards accepting XML submissions in the future.
>
>Yes.  The tools team see this as a policy decision, which has to be made by
>the IESG I believe, before it can be put into effect.

Agreed.  This goes to the IESG.

>>5. Section 8, "Check Action"
>>(a) The third paragraph states that "It is an error to submit a draft which
>>has neither plain text nor XML sources format (R68/a)."  The "/a" implies
>>that XML format will be included in the phase "a" development.  However,
>>Section 17, "Implementation Stages," states that development phase "a"
>>"focuses on plain text draft submission via the web interface."  Focusing
>>*only* on plain text draft submission in phase "a" seems appropriate.
>
>Yes, agreed, this was the intention.

Ok

>>(b) The third paragraph also states that "PDF- or PostScript-only drafts
>>cannot be posted without Secretariat involvement."  This statement is not
>>clear.  First of all, if "it is an error to submit a draft that has neither
>>plain text nor XML sources format," then PDF- or PS-only submissions are not
>>allowed, and such drafts cannot be posted with or without Secretariat
>>involvement.
>>The Secretariat currently does not accept "PDF- or PostScript-only" drafts.
>>A text version is *always* required.
>
>Ok.  This point was not clear to us.  The text should be corrected
>accordingly.

Ok. Correction needed.

>>Furthermore, the Secretariat currently
>>does not review PDF or PS submissions to ensure that they are identical to
>>the text version.  Rather, the staff posts them "as is."  If the rules
>>change, and PDF- or PS-only drafts are allowed, then they should be
>>auto-posted.  If PDF and PS drafts continue to be allowed as auxilliary
>>formats, AND if the procedures require that the content of these drafts is
>>identical to the content of the text versions, then the comparisons should be
>>automated as well.
>
>No objections, makes sense to me.

Ok.  Check if clarification needed.

>>6. Section 8.4, "Extraction"
>>(a) The first sentence states that "The toolset extracts meta-data from the
>>following stored draft formats: plain text, XML, and other."  If either (i) a
>>text version of a draft, or (ii) an XML version that can be converted to text
>>is always required, then why is it necessary to be able to extract data from
>>any format other than text?  Only if the rules change, e.g., if PDF- or
>>PS-only submissions are permitted, would it be necessary to provide this
>>feature.
>
>Correct.  One completely valid way of extracting the meta-data from the XML
>file would be to convert it to text and do the extraction there.  We don't
>want to *require* that it be done this way, however - it's just as fine from a
>requirement viewpoint to do extraction directly from XML.  Up to the
>implementor, really.

Ok.  Check if clarification needed.

>>(b) WG ID and WG flag: The word "tools" in
>>draft-ietf-tools-draft-submission-07 is not a WG ID.  The tools team is not a
>>working group.  The WG flag would be "False" for this document.
>
>Agreed.

Ok.  Check if clarification needed.

>>(c) creation date: Why is it necessary to note the "creation date"?  The
>>"submission date" is the date that is relevant in this process.  The
>>submission date is assigned by the system.  It is not extracted from the
>>draft.  (Also see comment #7)
>
>The idea is to have this part of the document meta-data be in agreement with
>the system's view of how long the document is valid.  Currently, there is no
>check on this, with the result that it is simply not possible to rely on the
>expiration date you see when you read a draft - and this is unfortunate...
>
>We should probably change the document to indicate that it's not really the
>creation date, but rather the Expiration date which is given in the draft
>which it is desirable to have in reasonable agreement with the system's
>view of expiration date.  I guess that one reason why it was expressed in
>terms of the creation date is that when one uses the xml2rfc tool to create
>a document, xml2rfc can calculate both dates for you based on the date when
>you generate the text version, so the expiration date indicated in the
>document is directly given by the creation date...

Ok.  Clarification needed in draft?

>>(d) expiration date: The expiration date is calculated by the system .  It
>>is not extracted from the draft.
>
>Ok.

Ok.

>>7. Section 8.5.1, "Absolute Requirements"
>>Item 7.  Once again, why are we concerned about when the draft was created?
>
>See above.
>
>>8. Section 8.5.4, "WG Approval"
>>WG chair approval is mandatory for posting of version 00 WG drafts.
>>Therefore, a mechanism for obtaining WG chair approval for posting of these
>>drafts should be included in this toolset.
>
>My personal viewpoint: Absolutely.

Ok.

>The team could not agree on exactly what the IETF requirements were on this
>point, if any, and has left this open to the implementor, to decide exactly
>how to implement this mechanism.
>
>>9. Section 9.1, "External Meta-Data"
>>(a) Submitter email address.  If the submitter is not a "lawful submitter,"
>>then why send the draft to the Secretariat?  What action would the
>>Secretariat take?  Currently, the Secretariat does not make decisions on the
>>the lawfulness of a submitter.  If the tool determines that a submitter is
>>not lawful based on rules established by the IESG, then the submission should
>>be rejected.
>
>Ok.  We believed that the secretariat verified (for non -00 drafts) that the
>submitter was either one of the authors, or one of the WG chairs or ADs.  If
>this is incorrect, the IESG will have to decide whether such a check should be
>done before this is incorporated in the tool.

Harald and Brian in the meeting indicated that they would like to not change
the rules for this at this point.  For now, there is no such concept as a
lawful submitter.  The draft needs to be updated, and this requirement removed
or described as a possible future enhancement.

>>(b) List of drafts obsoleted by this draft.  An RFC can be "obsoleted" by
>>another RFC.  However, an Internet-Draft cannot be "obsoleted" by another
>>Internet-Draft.  It can only be "replaced" by another Internet-Draft.  RFCs
>>are archival documents and exist in perpetuity.  Therefore, when its content
>>is no longer valid, an RFC can be declared "obsolete."  Internet-Drafts
>>(theoretically) have finite lifespans.  That is, an Internet-Draft that is no
>>longer valid disappears when it expires.  If an Internet-Draft is declared no
>>longer valid before it expires, then it can be "withdrawn" or 
>>"replaced."
>
>Right.  I believe this is just bad terminology in the draft - should probably
>be re-written to use "removed" and/or "replaced.

Ok.

>>(c) Indicating that an Internet-Draft replaces another Internet-Draft
>>should not be optional...it should be mandatory.  The submitter must indicate
>>if an Internet-Draft replaces another Internet-Draft.
>
>Agreed.

Ok.

>>10. Section 12, "Adjust Page"
>>If automated extraction fails to extract the correct information, then the
>>submitter should be allowed to adjust the meta-data, confirm that the data in
>>the draft now match the "adjusted" extracted meta-data, and automatically
>>post the draft.  If the submitter believes that the extraction process is not
>>functioning properly, then the submitter should send a bug report to the
>>Secretariat.
>
>No, we see this as undesirable.  We believe that it is better that the 
>submitter
>corrects the draft if the meta-information in the draft is incorrect, or
>submits a bug-report if the meta-information extraction does not work
>correctly; and in this case lets the tool forward the submission to the
>secretariat for manual verification of the corrected meta-data against the
>meta-data in the draft.

Accepted.

>>11. Section 13, "Post Manually Action"
>>The "post manually" action should always be available, and should be used
>>if the automated posting process is not functioning properly.  However, the
>>Secretariat does not make exceptions with respect to the posting of
>>Internet-Drafts.  If an Internet-Draft is non-compliant, then the staff
>>rejects it.  Therefore, if an Internet-Draft is non-compliant, then the
>>submitter should not attempt to circumvent rejection by sending the draft
>>directly to the Secretariat.  As long as the toolset is working, an
>>Internet-Draft can be posted automatically.  If the toolset is not working,
>>then all Internet-Drafts must be posted manually...and the Secretariat should
>>receive lots of bug reports!!
>
>Agreed.  This agrees with the intention of the requirements document, but may
>be insufficiently clearly stated there.

Ok.  Check if clarification needed in document.

>>12. Section 15, "Bypassing the Toolset"
>>One hopes that the number of "unusual" Internet-Drafts or the frequency of
>>"unusual" circumstances would be small.  The Secretariat will post manually
>>if the submitter requests the Secretariat to do so, or when automatic posting
>>fails.  However, if automatic posting fails because a draft is non-compliant,
>>then the Secretariat will not post the draft manually either.
>
>Again, agreed :-)

Ok.

>         Henrik

_______________________________________________
Tools-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-team