Subject: [Tools-team] Requirements for IETF Draft Submission Interface, v1.4

From: Alex Rousskov <[email-masked]>
Date: Wed, 25 Aug 2004 11:27:28 -0600 (MDT)

Hi,

 	My initial take at the ID submission requirements draft is 
attached as plain text and HTML files.

 	I do not like the current organization of the draft, but I 
would like to hear your high-level comments before polishing it. 
Specifically,

     - Should we be talking about different modes of
       draft submission? The draft itentifies 3.5 modes (see
       Section 5). We can simplify a lot if we focus on one mode
       only, but I think that all currently documented modes
       except for "Full Automation" are essential for
       a good draft submission environment. And "Full Automation"
       is the direction we should be moving in long-term.

     - I am having trouble coming up with good terminology
       to name the subject of our requirements. Especially
       with multiple modes, we are not talking aboutra
       single ID submission tool or interface. We are talking about
       several tools, and each tool has at least two
       sides/interfaces: submitter and publisher. Is there
       a better terminology than "ID submission tool"?

     - What do we do if ideal draft submission environment
       conflicts with current IETF rules. For example, if
       the tool allows for instant publication, some drafts
       may have more than 99 published versions and refering
       to a draft by its name and version should be exception
       rather than the rule (just the name should be used in
       most cases). Can we suggest such changes to the IETF?

     - Should I delete the "Status Quo" section? (Section 2)

Thanks,

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 26 Aug 2004 09:25:11 +0200

some comments in draft.....

--On 25. august 2004 11:27 -0600 Alex Rousskov 
<[email-masked]> wrote:

>
>
> TOOLS team                                                   A. Rousskov
> Internet-Draft                                   The Measurement Factory
> Expires: February 23, 2005                               August 25, 2004
>
>
>             Requirements for IETF Draft Submission Interface
>
> 1.  Introduction
>
>    Published Internet Drafts are primary means of structured
>    communication within IETF.  Current Internet-Draft (ID) submission

nit: please use I-D consistently...

>    and publication mechanisms hinder efficient and timely communication
>    while creating unnecessary load on the IETF Secretariat.  IETF TOOLs
>    team recommends formalization and automation of the current
>    mechanisms.  This document contains specific automation requirements.
>
> 2.  Tool Status Quo
>
>    To get an Internet Draft published, an IETF participant e-mails draft
>    text to the IETF Secretariat, along with an informal note asking to
>    publish the draft.  Secretariat staff reads the note, reviews, and

should be "reviews according to a checklist".

>    then approves or rejects the submission.  An approved draft is
>    automatically (XXX: or manually?)  copied to IETF web site, with the

automatically. (it's every 4 hours, which sometimes creates issues with 
pointers being found too early...)

>    corresponding announcement sent to appropriate IETF mailing list(s).
>
>    Collectively, IETF participants submit thousands (XXX: is there a
>    more accurate number?) of Internet Drafts per year (XXX: provide
>    individual and WG submission numbers separately).  The vast majority
>    of submitted drafts are approved for publication (XXX: are stats
>    available?).  It usually takes the Secretariat 12-24 hours (XXX: are
>    stats available?)  to review the draft.  Due to much higher demand
>    and fixed processing capacity, reviews around IETF face-to-face
>    meetings take much longer, creating a long queue of unprocessed
>    drafts that are then announced nearly simultaneously.
>
>    To reduce Secretariat load (XXX: are there other reasons?), drafts
>    submitted close to IETF meetings are ignored.

Main reason is to give the participants time to review. In particular, the 
earlier deadline for -00 drafts is to give participants significant time to 
review NEW work being proposed.

>    Anybody and anything can submit a draft for publication.  There is no
>    reliable authentication mechanism.  Initial submissions of WG drafts
>    require WG Chair approval, which is as easy to fake as the submission
>    request itself.
>
>    Lack of authentication is not perceived as a serious problem,
>    possibly because serious falsifications are likely to be noticed
>    before serious damage can be done.  Due to informal and manual nature
>    of the submission mechanism, a massive automated abuse of the
>    interface is unlikely to cause anything but a short denial of draft
>    publication service and, hence, is probably not worth defending
>    against.  However, future automation may result in a different trade
>    off.

two more things:

- it's never happened that someone submits with evil intent in someone 
else's name.
- sometimes, the submitter is not the person listed as author (for example 
jsut after a change in editor, or a co-author submitting). this argues for 
keeping the submission controls flexibile.

>
> 3.  Scope
>
>    TBD: In scope are interface(s) to submit the draft and requirements
>    on submitted draft review, approval/rejection, and publication.  Out
>    of scope are things like linking related drafts, draft persistency/
>    archiving, providing a "monitor this draft" service, and specifics of
>    authenticating draft submissions.

note - a number of information items are manually extraced from the draft 
today and put into databases. Automation of this function needs to be in 
scope; other uses of this info is out of this draft's scope (but in tools 
team scope).
>
> 4.  Terminology
>
>    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].  When used
>    with the normative meanings, these keywords will be all uppercase.
>    Occurrences of these words in lowercase comprise normal prose usage,
>    with no normative implications.
>
>    Submitter: A human or software submitting an Internet Draft for
>       publication.  A human submitter is likely to use some automation
>       tools (e.g., an e-mail client), but differs from the software
>       submitter in that it is a human who explicitly initiates the
>       submission process and interprets submission results.
>
>    Publisher: A human or software validating and publishing a submitted
>       Internet Draft.  A human publisher is likely to use some
>       automation tools (e.g., a validation tool), but differs from the
>       software publisher in that it is a human who explicitly initiates
>       the validation/publication process and interprets its results.
>
>
> 5.  Modes
>
>    Tool requirements depend on the submission and publication mode.  ID
>    submission tool MUST support all three modes documented in this
>    section.  Supporting different modes may call for creation of
>    different tools.  (XXX: are all modes in scope?) (XXX: is there a
>    better term than mode?)
>
>    (XXX: need to do a much better job at showing what requirements apply
>    to what tools or tool parts; we are lacking good terminology here).
>
> 5.1  Full automation mode
>
>    Submission interface SHOULD support draft submissions by software
>    submitter to software publisher.  For example, it should be possible
>    to configure decent content management software to automatically
>    submit and instantly publish the draft whenever a new revision of the
>    draft text is checked in.
>
>    Implementing a CGI interface for POSTing draft text and meta
>    attributes to a well-known IETF URL would be one way to accommodate a
>    software submitter (XXX: add WebDAV as another example?).  The
>    software-friendly outcome of the submission can then be expressed via
>    HTTP status codes (e.g., any code other than 200 or 201 would
>    indicate a failure).
>
>    The "software publisher" part of the requirement implies that
>    submitted draft is published or rejected without any human
>    involvement.

Reject/rename. There has to be human-in-the-loop on the submitter side, 
IMHO. Remember that the submission of a draft includes the submitter making 
an IPR disclosure commitment and copyright transfer. Making software do 
this without making it clear to the human it's happening is Evil.

However, putting the "submit" button in the submitter's software rather 
than the publisher's software is Goodness.

> 5.2  Publication automation mode
>
>    Submission interface MUST support draft submission by a human
>    submitter to software publisher.  For example, it should be possible
>    for the draft author to submit and instantly publish the draft
>    whenever the author feels that the new revision of the draft should
>    be published.

s/instantly/quickly/. "Instantly" does not exist.
>
>    Implementing a human-friendly easy-to-find web page where the draft
>    text can be uploaded along with meta attributes would be one way to
>    satisfy this requirement.  A human-oriented status page can be
>    returned to indicate the result of the submission.
>
>    The "software publisher" part of the requirement implies that
>    submission is published or rejected without any human involvement.
>
> 5.3  Human-to-human mode
>
>    Submission interface MUST support draft submission by a human to a
>    human, possibly as a last-resort, discouraged option.  For example,
>    Secretariat may provide a human-monitored e-mail address where drafts
>    can be mailed bypassing automated publishers.
>
>    Using this mode may result in significant publication delays.  The
>    human-assisted submission and publication mechanism MAY use some
>    automation (e.g., automatic spam detection for e-mail submissions).
>    If automation is used by default, the mechanism MUST provide a way
>    for a human submitter to bypass that automation (e.g., a keyword in
>    e-mail subject will turn spam filtering off).
>
>    The intent of this mode is to provide a way for submitters to bypass
>    bugs or limitations of automated mechanisms in order to publish an
>    unusual draft or to publish a draft under unusual circumstances.
>
> 5.4  Dry Run mode
>
>    TBD: Just validation, no publication.

One modality comment.... some information, like name and version number, 
goes into the draft, but can only be reliably produced by the publishing 
system. A "reserve this name/number" function is a Good Thing.
>
> 5.5  Mode automation matrix
>
>    The following table summarizes automation rules for the major modes.
>
>          +------------------------+------------+-------------+
>          | Mode                   | Submission | Publication |
>          +------------------------+------------+-------------+
>          | Full automation        |  software  |   software  |
>          | Publication automation |    human   |   software  |
>          | Human to human         |    human   |    human    |
>          +------------------------+------------+-------------+
>
>
> 6.  Draft Validation
>
>    IETF standards have to follow a set of syntax and semantics
>    requirements (XXX: provide references to the nits document and IP
>    policies).  Most of those requirements are not enforced for Internet
>    Drafts.  However, following them may improve draft quality, reduce
>    IESG load, and increase the chances of the draft being approved as an
>    RFC.  Draft submission mechanism MUST validate the drafts.  In case
>    of a human-to-human interface, such validation may be initiated by
>    the human publisher.
>
>    When validating a given draft, it is important to distinguish between
>    absolute requirements and desirable draft properties.  Both are
>    detailed in the following subsections.
>
> 6.1  Absolute requirements
>
>    A draft validator MUST check the following requirements and a draft
>    publisher MUST NOT publish drafts that failed corresponding validator
>    checks.
>
>    1.  A draft must be submitted by its author, corresponding working
>        group chair, or corresponding area director (XXX: is this the
>        right place to explain why we need AD override option to let IESG
>        publish draft fixes?).

Yes. And don't forget the co-author, changed editor, and drafts being 
published anonymously (secretariat needs to know who submitter is, but name 
doesn't necessarily appear on draft).
>
>    2.  The initial revision of a Working Group draft must be submitted
>        by the corresponding working group chair.

Today: approved, not submitted.
>
>    3.  Current draft state must allow new revisions to be published.
>        (XXX: document IESG review states when new revisions are not
>        allowed).

none such - "should not" and "must be notified" is the watchword. Too many 
fixes needed....
>
>    4.  Correct draft name (including correct revision number) must
>        appear in the draft text.
>
>    5.  An IETF IPR statement must appear in the draft text.  (XXX: is
>        this an absolute requirement for a draft?)

Yes.
>
>    (XXX: Dry Run mode may not need many of the above checks, depending
>    on user needs)

IMHO: Dry Run mode should give every error message in the book... but not 
cause a draft to be published.
>
> 6.2  Desireable features
>
>    A draft validator SHOULD check the following requirements.  A draft
>    publisher MAY publish drafts failed corresponding validator checks.
>
>    TBD: list testable nits here or refer to the nits document.
>
> 6.3  Draft text interpretation
>
>    A validator MAY try to partially interpret the draft text in order to
>    extract embedded data such as draft name or security section.  When
>    corresponding metadata is supplied by the submitter, the validator
>    can compare the extracted information with supplied metadata.  The
>    absence of identifiable embedded information may trigger validation
>    errors or warnings.
>
>    Extraction of embedded information may work very well for some draft
>    formats (e.g., those produced by an xml2rfc tool (XXX:  add
>    reference)), but it is impossible to reliably identify the format of
>    a plain text submission.

make note that we want to allow publishing xml drafts....
>
> 7.  Submission Metadata
>
>    TBD: document what metadata must be supplied: draft name (including
>    revision number), submitter credentials, is this the last revision of
>    the draft (to be submitted for IETF last call and IESG review),
>    format, content-encoding, etc.
>

keep the "last revision" out of it - generally, one does not know; classic 
cycle is submission1, WG last call, submission2, AD review, submission3, 
IETF last call, submission4, IESG review, submission5, IESG approval, 
publication - but ANY of the submissions 2-5 may turn out not to be needed, 
or be multiple cycle.

that's all, folks... .better quick comments now than deep comments never....

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 27 Aug 2004 14:46:52 +0200

Hi Alex,

	Here's some feedback on the draft:

Alex Rousskov wrote:
> 
> Hi,
> 
>     My initial take at the ID submission requirements draft is attached 
> as plain text and HTML files.
> 
>     I do not like the current organization of the draft, but I would 
> like to hear your high-level comments before polishing it. Specifically,
> 

Agree fully except for the last sentence.

>       a better terminology than "ID submission tool"?

I-D submission toolset?

>     - Should I delete the "Status Quo" section? (Section 2)

No, I think it's good to have that there.

> Thanks,
> 
> Alex.
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> TOOLS team                                                   A. Rousskov
>                    draft-ietf-tools-draft-submission
> 
...
>    team recommends 

My impression is that one of the most eager proponents of an automation
is the secretariat itself.  They proposed it before us, so we might as
well say that, too...

>    formalization and automation of the current

s/IETF web site/IETF drafts repository/

>    more accurate number?) of Internet Drafts per year 

My archives show these totals for recent years. These numbers are
somewhat elevated, as the final revision that indicates a draft has
been published as RFC has been included in the count.

Total:
    3416 2000
    4622 2001
    5196 2002
    5362 2003
    6827 2004

draft-ietf-*:
    1588 2000
    2220 2001
    2525 2002
    2754 2003
    1983 2004

others:
    1828 2000
    2402 2001
    2671 2002
    2608 2003
    4844 2004

(XXX: provide
>    and fixed processing capacity, reviews around IETF face-to-face

s/reviews around/reviews during the last weeks before/

>    submitted close to IETF meetings are ignored.

To give time to read the documents before the meetings...

>    Informal interface for submitting and publishing drafts discourages
>    automation.  Lack of automation discourages frequent updates.
>    Infrequent updates lead to stale published information.
> 
>    During periods of high Working Group activity, the delays associated
>    with draft publication times make official interface especially
>    inappropriate.  Working Groups come up with ad hoc solutions.  For
>    example, many draft subversions are "temporary" published on personal
>    web sites or posted (completely or in part) to the group list.
>    Often, alternative means of publication effectively replace official
>    IETF interfaces and only a few major draft revisions end up being
>    published on IETF web site.
> 
> Rousskov               Expires February 23, 2005                [Page 3]
> 
> Internet-Draft    Draft Submission Interface Requirements    August 2004
> 
> 

Mmm, not sure about the latter.  I think, for instance, that it might be
a requirement that we don't have to set up a general submitter (user)
data base, but do ad-hoc verification of e.g. return routability to the
submitter.

Of course, you may draw the line for what's specifics differently than
I do here.

>       submission process and interprets submission results.

Do we have non-human submitters?  Do we really want to consider such?

> Rousskov               Expires February 23, 2005                [Page 4]
> 
> Internet-Draft    Draft Submission Interface Requirements    August 2004
> 
> 

I like having something like the full automation mode, but I'm not
convinced this mode is appropriate for submissions with a frequency
matching checkin of a new cvs/svn/rcs or whatever version.  Some authors
I know do a new checkin for every individual issue corrected, and
generate a diff showing what was done.  If every such version was
published, it would be much more difficult to have a common baseline
when discussing drafts.  (This reservation may have no impact on how
the I-D submission tool is to be specified and implemented, however)

>    submission is published or rejected without any human involvement.

Yes. Good.

> Rousskov               Expires February 23, 2005                [Page 5]
> 
> Internet-Draft    Draft Submission Interface Requirements    August 2004
> 
> 

Yes, clearly.

>    TBD: Just validation, no publication.

I like it.  This should be an option both for Full automation and for
Publication automation.

>    The following table summarizes automation rules for the major modes.

One fairly natural way would be for the human publisher to use an extended
version of the publication automation interface.

> Rousskov               Expires February 23, 2005                [Page 6]
> 
> Internet-Draft    Draft Submission Interface Requirements    August 2004
> 
> 
>        publish draft fixes?).

"its author" should probably be "any of its authors or editors" or some such.
I don't think we need explain the AD override option.

>        by the corresponding working group chair.

Do you intentionally exclude sumbission by author, approval by chair here?

>        this an absolute requirement for a draft?)

I think there is more here; basically the applicable parts of 2026,
3667 and 3668 must be followed - this is mostly a matter of checking
the presence of boilerplate text.

(The idnits tool currently does not have an option to check only the
requirements applicable to all draft submissions, but I'd like to add
that.)

>    (XXX: Dry Run mode may not need many of the above checks, depending

Mmm, on the contrary; I think dry run mode should be identical to submission
mode up to the point where you actually do the submission.  Not sure I see
why not?

>    TBD: list testable nits here or refer to the nits document.

A starting point for a list of checkable nits could be the nits that
are checked by idnits: http://ietf.levkowetz.com/tools/idnits/

>    reference))

http://xml.resource.org/

>    , but it is impossible to reliably identify the format of
>    a plain text submission.

 From experience with the idnits tool, I think it may be possible to reach
95% reliability.

We might use this to extract meta-data, and present it on a feedback page
before the final submission is done, giving the submitter the opportunity
to correct it?

>    format, content-encoding, etc.

I don't think "last revision" should be part of this...  Can't reliably
tell that when submitting a draft.

> 
> 
> 
> 
> 
> 
> Rousskov               Expires February 23, 2005                [Page 7]
> 
> Internet-Draft    Draft Submission Interface Requirements    August 2004
> 
> 
> 8.  Security Considerations
> 
>    Some.  TBD: Talk about why authentication and anti-spam measures
>    become important once things become automated.

Yes

> 9.  IANA Considerations
> 
>    None.
> 
> 10.  Compliance
> 
>    TBD: What does it mean to be compliant with (to satisfy) our
>    requirements?
> 
> Appendix A.  Acknowledgments
> 
>    TBD.
> 
>    Special thanks to Marshall Rose for his xml2rfc tool.
> 
> Appendix B.  Change Log
> 
>    RFC Editor Note: This section is to be removed during the final
>    publication of the document.
> 
>    Internal WG revision control ID: $Id: id.xml,v 1.4 2004/08/25
>    17:21:43 rousskov Exp $
> 
>    2004/08/25
> 
>       *  Initial revision.
> 
> 
> 11  Normative References
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
> 
> 
> Author's Address
> 
>    Alex Rousskov
>    The Measurement Factory
> 
>    EMail: [email-masked]
>    URI:   http://www.measurement-factory.com/

...

---

From: "Barbara B. Fuller" <[email-masked]>
Date: Fri, 27 Aug 2004 11:21:26 -0400

Hi Alex:

Several members of the Secretariat staff have reviewed your I-D, and their 
combined comments are provided "in-line" below.  In addition, the staff 
would like to raise one terminology issue, namely, the use of the word 
"publication" rather than the word "posting" to describe the addition of an 
I-D to the I-D directory.

Use of the word "publication" in regard to an I-D can sometimes be 
confusing.  That is, when people talk about publishing an I-D, they often 
mean publishing it as an RFC.  For example, the first "official" state for 
an I-D in the I-D Tracker is "Publication Requested."  Therefore, we 
suggest that you consider changing the word "publication" to "posting," the 
word "publish" to "post," etc. throughout the document.  The tool would be 
used for submitting and posting Internet-Drafts.

Please let us know if you have any questions about our in-line 
comments.  As I mentioned in a previous message, the Secretariat will 
provide high-level requirements for the I-D submission and posting tool 
sometime next week.

Regards,

Barbara
-----------------------------------------------------------------------------------
2.  Tool Status Quo

COMMENT:  The Secretariat processes I-Ds manually.  Since processing 
involves more than just copying the I-D to the I-D directory (e.g., it also 
involves updating the databases), we suggest that you change the final 
sentence above to read:

"An approved draft is manually processed, and an I-D Action announcement is 
sent to the appropriate IETF mailing list(s)."

    Collectively, IETF participants submit thousands (XXX: is there a
    more accurate number?) of Internet Drafts per year (XXX: provide
    individual and WG submission numbers separately).

COMMENT: The Secretariat does not maintain statistics on the number of I-Ds 
submitted...only on the number of I-Ds posted to the I-D directory.  For 
the period January 1-December 31, 2003, the Secretariat posted 2,108 
I-Ds.  The breakdown is as follows:

New WG I-Ds: 384
New Individual I-Ds: 1091
Updated WG I-Ds: 288
Updated Individual I-Ds: 345

    The vast majority
    available?).

COMMENT: In each category, the number of I-Ds approved for posting is the 
same as the number of I-Ds posted.

    It usually takes the Secretariat 12-24 hours (XXX: are
    stats available?)  to review the draft.

COMMENT: This statement is somewhat misleading.  It takes the Secretariat 
only a few minutes to process an I-D.  However, it may take several hours 
before the I-D appears on the Web site due to the rsync 
schedule.  Furthermore, if I-Ds are submitted after COB on Friday, it can 
take a couple of days for them to appear on the Web site since the staff 
does not work 24/7.

    Due to much higher demand
    and fixed processing capacity, reviews around IETF face-to-face
    meetings take much longer, creating a long queue of unprocessed
    drafts that are then announced nearly simultaneously.

COMMENT:  There are established "pre-meeting" cutoff dates/times for new 
I-Ds and updates to existing I-Ds.  The Secretariat receives a large number 
of I-D submissions immediately before the deadline.  Therefore, it may take 
several days to post them all.  As per standard procedures, the Secretariat 
does not accept I-D submissions between the "pre-meeting" cutoff date for 
updates to I-Ds and the Monday of the meeting week.  The Secretariat 
*never* ignores an I-D.

5.  Modes

5.1  Full automation mode

COMMENT: If a newly submitted I-D is a Working Group submission and version 
-00, then the Secretariat must obtain approval from the WG chair before 
posting the document.  Thus, it is impossible to post the I-D *instantly* 
in such a case.

COMMENT: Again, it is impossible to process version -00 WG submissions 
without any human involvement.  The Secretariat must obtain the approval of 
the WG chair.

COMMENT: There does not appear to be much of a difference between this mode 
and "Full Automation Mode."  In both cases, the submitter still needs to 
fill in all of the essential fields (i.e., the required meta 
attributes).  Also, in both cases, the submitted I-D must be validated 
before it goes to the "Posting Software" or to the WG chair for 
approval.  The only difference between the two modes is that the "Full 
Automation Mode" seems to call for "Copy and Paste" of the I-D, whereas 
this mode calls for "Uploading" the I-D.  It would be helpful if you could 
provide more information on the differences between these two modes.

5.3  Human-to-human mode

COMMENT: The email submission mode would be available for submitters who 
are unable to access the Web tool at the time they want to submit an 
I-D.  However, the Secretariat does not post "unusual" I-Ds.  That is, the 
Secretariat posts all I-Ds that adhere to the requirements and for which it 
has obtained the necessary approvals.  It would be helpful if you could 
provide some examples of unusual drafts or unusual circumstances.

5.4  Dry Run mode

COMMENT: The matrix seems confusing.  Specifically, the use of the term 
"human" is not clear.  Based on Section 5.3, it appears that the "human" 
mode implies the use of email for that part of the process being discussed, 
i.e., for either the "Submission" or "Publication" ("Posting") of the 
I-D.  However, in both the "Full automation" and "Publication automation" 
modes, the submitter uses a Web interface to enter information on the 
I-D.  Therefore, it is not clear why the "Submission" process is labeled as 
"software" for the "Full automation" mode and as "human" for the 
"Publication automation" mode.

Furthermore, in the "Human to human" mode, the submitter may indeed submit 
a request to post an I-D via email.  However, that would not prevent the 
Secretariat from using the software to post the I-D.  Thus, the "Human to 
human" mode is really "human" submission and a combination of "human" (to 
read the email) and "software" for posting.

Finally, if one considers the fact that the WG chairs would be notified by 
email when approval is required for version -00 postings, it seems that all 
three modes involve some level of human processing.

6.  Draft Validation

COMMENT: The IESG guidelines for the Secretariat are that tools should 
implement existing procedures and not create or modify procedures.  AD 
override is not an existing procedure.  Suggestions for creating or 
modifying procedures should be submitted to, and approved by, the IESG 
before these procedures are implemented in a tool.

COMMENT: What do you mean by an "initial revision"?  An initial draft is a 
version -00 document, and if it is a WG submission, then it must be 
approved by the WG chair prior to posting.  A revised draft is a version 
-01 or higher document, and may be submitted by the author and posted by 
the Secretariat without approval of the WG chair.

COMMENT: I-Ds can be updated when they are in the states "I-D Exists" or 
"AD is watching" in the I-D Tracker.  Once publication is requested and the 
document moves to the state "Publication Requested," the document cannot be 
revised unless the shepherding AD requests revisions.

7.  Submission Metadata

COMMENT:  The Secretariat's requirements will include the metadata that the 
Secretariat needs to process I-Ds and update its databases.

COMMENT:  Since this is a Web-based tool, it is not clear how "anti-spam 
measures" apply.  The IESG guidelines for the Secretariat are that tools 
designed for the community should be available to the public and not 
require authentication (since the IETF is not a membership 
organization).  If the TOOLS Team feels that authentication mechanisms are 
appropriate (i.e., based on input from the community), then the Team should 
probably obtain approval from the IESG before implementing such mechanisms.
-----------------------------------------------------------------------------------

>     - Should I delete the "Status Quo" section? (Section 2)
------------------------------------------------
Barbara B. Fuller
Acting Executive Director
Internet Engineering Task Force

Natick, Massachusetts Office:

Phone: +1-508-650-4020
Fax:     +1-508-650-4639

Reston, Virginia Office:

Phone: +1-703-620-9053
Fax:     +1-703-620-9071

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Aug 2004 10:28:18 -0600 (MDT)

On Fri, 27 Aug 2004, Barbara B. Fuller wrote:

> comments.  As I mentioned in a previous message, the Secretariat 
> will provide high-level requirements for the I-D submission and 
> posting tool sometime next week.

Barbara,

 	Thank you for prompt feedback with many useful suggestions and 
corrections! Below, I am going to respond only to those Secretariat 
comments that I cannot address in the draft without further discussion 
with you and TOOLs members.

 	Please note that quite a few questions or objections seem to 
result from your natural desire to document and improve the current 
status quo, which often conflicts with my intent to define the right 
toolset for the job (and then bridge the gap with current IETF). This 
is the only strategy I know that will let us fix some current design 
flaws instead of unknowingly integrating them into every new tool 
produced.

 	The first question should be "What toolset does IETF need?", 
with a "How to make a painless transition to the new toolset?" 
question as a followup.

 	The primary question should not be "How to further automate 
what IETF and Secretariat are doing today?" because many things that 
you and I do in IETF today are not the things we want/should be doing 
in the first place.

> COMMENT: If a newly submitted I-D is a Working Group submission and 
> version -00, then the Secretariat must obtain approval from the WG 
> chair before posting the document.  Thus, it is impossible to post 
> the I-D *instantly* in such a case.

Yes, indeed. However, the proposed interface makes automation possible 
by requiring 00 versions to be submitted (or, essentially, 
signed/authenticated) by the Chair. With the right authentication 
mechanism in place, it is possible to automate ID submission without 
changing IETF draft approval rules. I hope this clarifies the intent 
and am going to skip a few related comments that all assume that 
Secretariat human must interact with the Chair when the 00 version of 
the draft is submitted.

> COMMENT: There does not appear to be much of a difference between 
> this mode and "Full Automation Mode."  In both cases, the submitter 
> still needs to fill in all of the essential fields (i.e., the 
> required meta attributes).

In many cases, software can do that. For example, tools like xml2rfc 
can "fill in" some ID metadata once they are configured. While we 
currently do not have consensus whether full automation is desirable, 
it is technically possible for the vast majority of drafts. We will 
discuss the desirability of full automation separately.

If full automation mode is preserved, I will do my best to document it 
better. I agree with your comments (above and elsewhere) that the 
distinction with publication automation mode is not clear.

> COMMENT: The matrix seems confusing.  Specifically, the use of the 
> term "human" is not clear.  Based on Section 5.3, it appears that 
> the "human" mode implies the use of email for that part of the 
> process being discussed, i.e., for either the "Submission" or 
> "Publication" ("Posting") of the I-D. However, in both the "Full 
> automation" and "Publication automation" modes, the submitter uses a 
> Web interface to enter information on the I-D. Therefore, it is not 
> clear why the "Submission" process is labeled as "software" for the 
> "Full automation" mode and as "human" for the "Publication 
> automation" mode.

I was hoping that submitter definition in Section 4 would clarify the 
difference between "human submitter using tools" and "software 
submitter using implicit/prior human authorization":

I am guessing the above is too obscure to have a desired effect on a 
reader. I will try to emphasize the "explicitly initiates" bit to 
clarify the difference.

As an example, consider a script that publishes current version of the 
draft every Sunday at midnight. A human created and started the 
script, but each submission is not explicitly initiated by a human. It 
is also not closely monitored or controlled by a human...

The differences between human and software interfaces are very 
important. As a simple example, you cannot add an "Are you sure?" 
question to a fully automated interface without changing software 
submitters. You can add many questions to a human-driven interface.

> COMMENT:  ... If the TOOLS Team feels that authentication mechanisms 
> are appropriate (i.e., based on input from the community), then the 
> Team should probably obtain approval from the IESG before 
> implementing such mechanisms.

It is clear to me that current IETF mechanisms already use 
authentication (e.g., an e-mail _from the Chair_ authorizing 00 
draft). It's just that authentication is very weak. Mandatory strong 
authentication for all IETFers is beyond TOOLs scope. Stronger 
authentication for tool users is in scope, IMO. Finally, we are not 
going to implement anything so there will be a chance for IESG and 
IETF to review final recommendations and specifications before any 
implementation or adoption starts.

BTW, since IESG is watching our deliberations, I am sure they will try 
to stop us if we cross the authentication scope line.

Again, thanks a lot for your review. I am looking forward to more 
Secretariat requirements and feedback!

Alex.