Subject: [Tools-team] Minutes for 1 Sep 2004 Telechat

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 1 Sep 2004 18:56:55 +0200

Here are the minutes from today's meeting.

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

1. Agenda bashing

	No changes.

2. Comments on minutes from last teleconference.

	Maybe put the minutes online?  Lets put a link from the wiki to the
	mail archive's copy of the minutes. (Larry?)

3. Action item review.

   * Larry  will write a first draft of a note to send out to the ietf
	   and wgchairs lists about the tools-discuss list.  To be refined
	   on the tools-team list.

	Done.
	Henrik has done some edits on the wiki page,
	Alex had some suggestions which he will add to the wiki page today.	

   * Larry  will write a summary on how to find out what people want
     	   and how to evaluate what is actually needed.

	Postponed for now.  Let's start with doing the announcement and se
	what kind of reaction we get.

   * Henrik will send first copy of Tools inventory/prio draft to the
     	   list Thu. or Fri.

	Not done - doing web page summary first.  Have started doing 
	this on the tools team web page instead.  Please give feedback
	on the web page - http://tools.levkowetz.com/ ( will be
	http://tools.ietf.org/ as soon as the delegation is up ).

   * Alex   will send the first copy of ID-Submission req. draft to the
     	   list Wed. or Thu.

	Done, second revision due sunday this week. Good stuff.

	We need to specify whether we want a tools-level interface,
	and what kind of interface might be needed.  XML output
	from a single submission?  XML list of documents submitted?
	Nothing?

	We also need to hurry up a little bit, which means we need to
	prioritize the requirements so it is possible to implement
	a simple version soon, and a more full-blown later.

	Should we specify details of a cgi-interface or xml-interface?
	- So far tool interaction has been done behind the scene by
	  Mike
	- We should say what the tool must and might be, and later
	  say how this might be implemented, but not force this.
	- Don't specify exact interfaces for now.  We know too little
	  of what is needed in term of future interfaces.
	- It's not a must level requrement to be able to do automated
	  submissions.  And we need more experience and input to 
	  decide the priority of this.  
	- Put in a requirement that future automation should be possible.

	Mention RSS feed as one future output from the submission tool.
	- could be done as part of this tool, or as part of the
	  repository handling mechanism
	- could mention this, and get people's input on the desirability.

   * Henrik will follow up on creation of "[email-masked]" list,
     	   and on the subdomain delegation

	Nudged.  Got a positive ack on the subdomain delegation, should
	come up today.   No word on discuss list.  
	* Nudge again.

   * Alex   will re-initiate the discussion on the
            [email-masked] list, as a continuation of the
            discussion about needed tools, components, requirements
            etc which was started before IETF-60, but temporarily
            put on hold.

	Done.  

	* Alex will check up that there's a wiki page set up for the
	  framework thoughts/summary.

   * Henrik fix up web page with link to charter etc, and send msg.

	Page set up, message will be sent.

   * Henrik Get wiki set up

	Done.  

   * Stas   Summary of tools reviewed/mentioned on the mailing list
     	   on a wiki page.

	- Add RSS feed to the summary of tools on the wiki
	- Henrik nudge Stas on this.

4. Status of drafts

	Nothing in addition to what's mentioned above

5. Next steps

	* Henrik to send announcement once prerequisites are fulfilled.

	* Larry to ask the w3 what software they are using to get peoples
	  consent to publish mailing list submissions

6. Any other business.

	Nope

7. New action items, summary

	* All - give feedback on http://tools.levkowetz.com/

	* All - give feedback on next revision of I-D submission tool
	  requirements

	* Henrik to send announcement once prerequisites are fulfilled.

	* Larry to ask the w3 what software they are using to get peoples
	  consent to publish mailing list submissions

	* Henrik to nudge Stas on tools review/discussion wiki page

	* Alex will check up that there's a wiki page set up for the
	  framework thoughts/summary.

	* Alex to send out next revision of draft by Sunday

	* Henrik to continue the inventory on the web site

	* Alex - add comments on the announcement draft to the wiki page
	  ( http://tools.levkowetz.com/wiki/ToolsTeamAnnouncement )

	* Larry, Henrik, Stas - check the announcement draft wiki page

	* Larry to add a link from the wiki to the mailing lists's copies
	  of the meeting minutes.

8. Next meeting:

     Teleconference Wednesday 8 Sep, same time as today, same codes.

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

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 1 Sep 2004 14:10:40 -0600 (MDT)

> 	* All - give feedback on http://tools.levkowetz.com/

Thanks for starting working on these pages. IMO, good site would be 
important for attracting more/better feedback from IETFers, and that 
is one of the biggest challenges we face.

Just some random comments:

 	- Team drafts were difficult to find for me, and I
 	  suspect so would be the Charter for some visitors.
 	  Since the whole site is the TOOLs team site, the
 	  "Team" menu item seems like an extra level of
 	  indirection. I expected to see just the member
 	  list there. How about moving Team menu subitems up
 	  one level?

 	- Rename "Drafts" menu item to "Documents"?

 	- "Feedback" also confused me. I expected to find
 	  a page that explains how to suggest a tool, etc.
 	  but found a list of subitems. Which one should I
 	  click to provide feedback? I would recommend a
 	  short page clearly explaining how and where to suggest
 	  new tools. We can have three Feedback pages:
 	  "Suggest new tool", "Review existing tool", and
 	  "Other". The last one pointing to the public mailing list
  	  and membership page.

 	- I would store "future tools" information in corresponding
 	  "Tools" pages instead of having the user to guess whether
 	  the tool they are looking for is "current" or "future".
 	  Also, an "all tools" page may be useful for those who
 	  are not sure about the categories we force on them; can
 	  that be auto-generated from other tools pages (or vice
 	  versa)?

 	- The bulleted list items are too long and fuzzy for the
 	  front page, IMHO. I would replace them with 2-4 bullets
 	  explaining what TOOLS is for. "Feedback and guidance during
  	  the development of software tools" is rather vague. A
 	  visitor needs to know immediately whether they are in
 	  the right place. Their attention span is short.
 	  What do we produce? What do we want from IETFers?
 	  Do we develop tools or fix bugs in tools?

 	- Clicking on W3C XHTML icon results in a
 	  "This page is not Valid" page. Is it important
 	  to declare compliance with one of many standards
 	  these pages are using?

 	- When I click on a menu subitem, I get the right page,
 	  but the subitem disappears (I get top-level menu again).
 	  Can the menu expansion be preserved so that I know
 	  where I am on the site?

HTH,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 1 Sep 2004 15:51:12 -0600 (MDT)

>   framework thoughts/summary.

I did not find an existing page and created a new one:
http://tools.levkowetz.com/wiki/IetfInfrastructure?action=show

The page summarizes the discussion we had on this list. I merged 
Harald and my own postings about major infrastructure items and added 
a few comments from various e-mails on that thread. Feel free to 
change/add further, of course.

For this information to make sense long-term and be usable from our 
drafts, we would probably need to describe details of each 
infrastructure item interface.

BTW, I tried to link to it from the front wiki page, but wiki uses a 
http://tools.levkowetz.com/wiki/IetfInfrastructure
link. That link, for unknown to me reason, does not work (pretends the 
page does not exist). I am sure I screwed something up given my lack 
of wiki knowledge. Please fix if you can.

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 2 Sep 2004 16:36:31 -0600 (MDT)

> 	* Alex to send out next revision of draft by Sunday

The plain text rendering of the next revision is attached to this 
e-mail. This is a major rewrite, following initial feedback from the 
team and Secretariat. The draft now documents a specific set of pages 
and supporting actions.

Many details are still missing, but I hope that overall organization 
of the draft will not change much.

I would like to find a way to explicitly mark features so that we can 
propose implementation stages/priorities. That's probably the most 
important missing piece right now.

> 	* All - give feedback on next revision of I-D submission tool

High-level feedback is especially helpful at this stage. In 
particular, I am worried that the toolset design currently conflicts 
with my interpretation of Secretariat preferences:

My understanding is that Secretariat SRS uses a "give us metadata and 
draft; we will validate metadata and then publish" approach. This 
approach maximizes submitter work and minimizes tool utilization.

This means that the submitter needs to fill out a large number of 
metadata fields with information that, from the submitter point of 
view, is already in the draft. This may cause the perception that the 
automation actually requires more effort from the submitter than 
good-old submissions via Secretariat, where only draft text was 
required. Also, if the tool trusts the submitter, the published 
metadata is less likely to match the draft.

Proposed toolset currently uses the opposite "give us the draft; we 
will validate and extract as much metadata as we can, you validate 
what we extracted and fill in the gaps, we publish" approach. This 
approach minimizes submitter work and maximizes tool utilization.

This means that the submitter needs to submit just the draft text to 
get almost every validation possible. A little extra information (not 
available from the draft; e.g. submitter e-mail) is needed to actually 
publish the draft.

Furthermore, the toolset would not let ordinary submitter to 
auto-publish drafts that required adjustments to extracted metadata. 
Such drafts must be submitted to Secretariat. Secretariat would verify 
that manual adjustments did not cause conflicts and use the toolset to 
force posting of the draft. This restriction is meant to (a) minimize 
the number of metadata-draft conflicts caused by sloppy submitters and 
(b) provide an incentive to Secretariat and IETFers to improve draft 
validation tools (so that they can extract metadata reliably to avoid 
submission via Secretariat).

Both Secretariat and toolset design end up with the same set of 
metadata fields. The difference is in who fills those fields 
(submitter or software) and, hence, in consistency of filled 
information.

Please see draft for details. Which approach is better?

Thank you,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 3 Sep 2004 10:36:51 +0200

Hi Alex,

	Thanks for feedback.  I've started doing changes based on
most of your comments, but after the 10th iteration I decided to
leave the current page up till I have something reasonably stable,
and do the work offline.

>  	  list there. How about moving Team menu subitems up

Can be done, although I expect people to visit the site mainly
for the tools, not for our drafts.  But I'm going to try to
flatten the whole menu, so as not to need the 2 levels you see
now.

>  	- Rename "Drafts" menu item to "Documents"?

Mmm.  Not sure that is better.  More generic yes, but less specific.

>  	  "Other". The last one pointing to the public mailing list

Ok, I'll do something about this

>  	  the tool they are looking for is "current" or "future".

Yes, that was the other way of doing it that I considered.  I'll
give it a try.  

>  	  that be auto-generated from other tools pages (or vice

Good idea.

>  	  Do we develop tools or fix bugs in tools?

Ok, I'll try to improve this.

>  	  to declare compliance with one of many standards

No. Removed.  ( I do check the pages, but you may have caught
a page while I was working on it )

>  	  Can the menu expansion be preserved so that I know

I'd like this too, but it requires state in the menues, which
they don't currently have.  Anyway, I'm probably going to flatten
it so the menues doesn't expand and contract.

	Thanks,

		Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 3 Sep 2004 10:52:41 +0200

Hi Alex,

	I'm splitting my response and adding subject lines.

On Thursday,  2 Sep 2004, Alex Rousskov wrote:
...
> approach maximizes submitter work and minimizes tool utilization.

[snip details]

> approach minimizes submitter work and maximizes tool utilization.

[snip details]

> Please see draft for details. Which approach is better?

When I've been thinking abou this tool, I've visualized something which
is closer to the latter approach - extract metadata from the draft -
but I thought of presenting a second page to the submitter after doing
the extraction, with all meta-data filled in, and requesting confirmation
of the metadata, with an option to change/correct some of the fields.

(Validation of the submission (requred boilerplate etc.) would be done
before presenting this page, so that for a draft not found valid, a
different feedback page would be presented - the sumbitter wouldn't
get first the metadata page and then find that the submission didn't
validate.)

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 3 Sep 2004 07:15:00 -0600 (MDT)

On Fri, 3 Sep 2004, Henrik Levkowetz wrote:

> When I've been thinking abou this tool, I've visualized something 
> which is closer to the latter approach - extract metadata from the 
> draft - but I thought of presenting a second page to the submitter 
> after doing the extraction, with all meta-data filled in, and 
> requesting confirmation of the metadata, with an option to 
> change/correct some of the fields.

That's exactly what happens in the current draft. The second page is 
the Check page. If adjustments are needed, the submitter clicks a 
button and goes to the Adjust page (which also means she is off the 
auto-post route, but that is a different design decision to discuss).

> get first the metadata page and then find that the submission didn't

That's exactly what happens in the current draft.

Alex.

P.S. Sorry about posting without a subject line.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 3 Sep 2004 09:11:07 -0600 (MDT)

> Mmm.  Not sure that is better.  More generic yes, but less specific.

I was thinking that the "Documents" page would be a good place to link 
to selected wiki pages (e.g., the Infrastructure page) and other 
things that may not be drafts. If being a draft is important, we can 
have a "Drafts" section on the "Documents" page.

"Documents" is more "persistent" too. If we are around for three 
years, I hope that some of our drafts become RFCs or BCPs :-).

Not a big deal, of course.

Thanks,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 3 Sep 2004 17:29:15 +0200

Hi Alex,

> have a "Drafts" section on the "Documents" page.

Ok, I see.  My intention was to link "drafts" to an autogenerated
drafts page.  

> years, I hope that some of our drafts become RFCs or BCPs :-).

Yes.  Maybe there's room for "Drafts" and "RFCs"/"Other Documents".

> Not a big deal, of course.

We can adapt as content changes :-)

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 9 Sep 2004 17:58:47 +0200

Hi Alex,

Here are a few last-minute notes.  If there are things you won't have
time to fix before 15:00 Eastern, then leave them to the next revision.

	Henrik

On Thursday,  2 Sep 2004, Alex Rousskov wrote:
> TOOLS team                                                   A. Rousskov
> Internet-Draft                                   The Measurement Factory
> Expires: March 3, 2005                                 September 2, 2004
> 
> 
>              Requirements for IETF Draft Submission Toolset
>                    draft-ietf-tools-draft-submission

...

>    Many Working Groups have come up with ad hoc solutions to cope with
>    posting delays.  For example, many draft subversions are "temporary"
>    published on personal web sites or sent (completely or in part) to
>    the group list.  Alternative means of publication may effectively
>    replace official IETF interfaces, with only a few major draft
>    revisions end up being posted on IETF web site.
> 
>    Informal interfaces for submitting and posting drafts discourage
>    automation.  Lack of automation discourages frequent updates.
> 
>    Infrequent updates lead to stale public information and/or
>    duplication of posting mechanisms by individual authors or WGs.

Let me note that I'm not convinced that an update frequency of archive drafts
higher than on average once per two week, approximately, is beneficial.  I
believe updates oftener than this should be done in some other manner.  There
needs to be a common baseline for mailing list discussions to be fruitful, and
as some editors publish a new version after every issue has been addressed,
sometimes as often as 5 times over one day, the picture that emerges from the
above 3 paragraphs seems a bit skewed to me, as it implicitly says that more
often is better, without reservation

...

> 5.  Overall toolset operation
> 
>    To post a draft, the submitter goes through the following sequence of
>    steps and web pages:

Better clarify the above sentence, so it is obvious this is the proposed
new mechanism.  

...
>    The following diagram illustrates a typical submission process.
>    (XXX: we should probably merge the above list and the diagram)

Yes, definitely.  (And probably call this something else than diagram
- it's not really.  Maybe s/diagram/sequence/ ?)

...

>    3.  A Working Group draft must be approved by the corresponding
>        working group.
> 
>    4.  Current draft state must allow new revisions to be posted.  (XXX:
>        document IESG review states when new revisions are allowed.
>        Secretariat and Harald opinions seem to differ here.
>        Secretariat:  No revisions are allowed in any state except for
>        "I-D exists", "AD watching", or an explicit IESG request for a
>        new revision.  Harald:  no revisions once submitted for
>        publication.  Need further clarification).
> 
>    5.  Correct draft ID (including correct revision number with respect
>        to already published revisions, if any) must appear in the draft
>        text.
> 
>    6.  An IETF IPR statement must appear in the draft text.  [[anchor3:
>        add the applicable parts of RFC 2026, 3667 and 3668 - this is
>        mostly a matter of checking the presence of boilerplate text.
>        --Henrik]]
> 
>    (XXX: Today, -00 WG drafts are approved by the Chair after
>    submission, not prior to submission)

I think we need to very clearly point out that we propose to require
that working group chairs post an approval *before* a -00 is sumbitted
- there is no option to submit a -00 draft and have it sit and wait for
the chair's approval.  This is a change from current procedure, and 
may need approval from outside the tools team.

> 
> 7.3.2  Desireable features
> 
>    Violating any of the following requirements would NOT prevent a draft
>    to be automatically posted except for draft revision designated for
>    "publication requested" state (i.e., IETF Last Call and IESG review).
>    (XXX: should we be that strict with last revisions?)
> 
>    TBD: list testable nits here or refer to the nits document.  Henrik's
>    idnits tool is a starting point:
>    http://ietf.levkowetz.com/tools/idnits/

Here is the excerpt from the ID-checklist, with checkable nits marked 
with "yes":

1.1 Formatting
 
 yes  * Not beyond the 72nd column of a line
        This is especially important for diagrams and code, which the RFC Editor
        may not be able to trivially reformat to fall within the margins.
 yes  * Must be ragged right
 yes  * No hyphenation for line-breaks
      * No footnotes
 yes  * ASCII-only, no control characters (other than CR, NL & FF)
 yes  * Do not number the "Status of Memo" or Abstract sections
 yes@ * Do not add a numbered reference in the ID boilerplate to RFC 3667 or 3668
        (makes it harder for the RFC editor to process the document when they
        strip off the ID boilerplate)
      * Reasonably well formatted for readibility and clarity.
      * Use network byte order in diagrams
        (see draft-rfc-editor-rfc2223bis-07.txt section 3.4)
 
 1.2 Required sections - all IDs
 
 yes@ * Internet Draft boilerplate
        Must contain boilerplate that permits publication as an RFC
        (see RFC3667, Section 5.2.)
      * List of authors/editors
        There should not be > 5 authors/editors
        (see http://www.rfc-editor.org/policy.html)
 yes  * Abstract
 yes  * Table of Contents, required if document is more than 15 pages
 yes  * Introduction
 yes  * Security Considerations
      * IANA Considerations
 yes  * References
        Must be split into normative and informative sections
        (see http://www.rfc-editor.org/policy.html)
 yes  * Author's Address
 yes  * IPR notices, IPR Notice, verbatim from RFC3668, Section 5.
 yes  * Copyright Notice and Disclaimer,
        verbatim from RFC3667, Sections 5.4 and 5.5.

> 
> 8.  Check Page
> 
>    The Check page, created by the Check action displays extracted draft
>    meta-data and validation results.  The purpose of the page is to
>    allow the submitter to verify whether stored draft and automatically
>    extracted meta-data match submitter's intent and to be informed of
>    validation problems.
> 
>    Extracted meta-data items that were not successfully extracted or
>    that failed validation checks must be marked specially (rather than
>    silently omitted).  Validation results include errors and warnings,
> 
> 
> 
> Rousskov                 Expires March 3, 2005                 [Page 10]
> 
> Internet-Draft    Draft Submission Toolset: Requirements  September 2004
> 
> 
>    with references to normative documents containing corresponding
>    validation rules.
> 
>    The submitter can also enter external meta-data (Section 8.1), which
>    is required for automated posting of the draft.  If validation was
>    successful, an "automatically post the draft now" button is provided.
>    Regardless of validation results, "adjust and post manually" and
>    "cancel" buttons are provided.
> 
>    Finally, a preview of the draft is provided.  (XXX: should the entire
>    draft be rendered, especially when submission does not include plain
>    text format?)
> 
> 8.1  External meta-data
> 
>    TBD: Input fields for meta-data that must be supplied by submitter
>    and cannot be extracted from the draft: Which author is the
>    submitter? (with an exception for Secretariat manual submission); Is
>    this the last revision of the draft? (XXX: clarify:  last from the
>    WG/author point of view (to be submitted to the AD for IETF last call
>    and IESG review), may not be last revision since IESG may require
>    more revisions).

This will probably not be known at the time of submission, so probably
should not be included.  And is there any need for this information here,
especially since it may turn out to be wrong as often as right?

> 9.  Post Now Action
> 
>    The Post Now action checks that the draft has been successfully
>    validated, validates external meta-data (including submitter e-mail),
>    and posts the draft.  Submitter is notified of the action progress
>    and final result.
> 
>    External data contains submitter e-mail address.  As a part of the
>    validation procedure, the Post Now action checks that the submitter
>    has access to e-mail sent to that address.  The check is performed by
>    e-mailing a hard-to-guess cookie or token.  The submitter is
>    requested to cut-and-paste the token or go to the token-holding URL
>    to continue with the submission.  If the submitter does not continue,
>    the submission will eventually timeout.  This intermediate dialog
>    requires storing additional state and generating a token-accepting
>    web page.
> 
>    If draft posting is successful, toolset state information may be
>    deleted from the toolset storage area (XXX: on-demand garbage
>    collection may be better from debugging point of view; what may seem
>    like a successful post may not be that successful).
> 
> 10.  Adjust Action
> 
>    The Adjust action generates the Adjust page, populating it with
>    available extracted meta-data and external meta-data as well as
>    validation results and preview.  Some or all of the information may
>    be missing, depending on draft interpretation and rendering success.
> 
> 11.  Adjust Page
> 
>    The Adjust page allows the submitter to adjust all extracted draft
>    meta-data (and, naturally, external meta-data) at will.  Such
>    adjustment is necessary when automated extraction failed to extract
>    [correct] information.  To avoid mismatch between draft and its
>    meta-data, adjusted drafts cannot be automatically posted and require
>    manual validation by Secretariat.  Secretariat staff can post drafts
>    with adjusted meta-data as described in Section 13.
> 
>    In addition to editable meta-data, the page provides read-only
>    validation results and preview, if available.
> 
>    The "post manually" and "cancel" buttons are provided.  The former is
>    backed by the "Post Manually" action (Section 12).
> 
> 12.  Post Manually Action
> 
>    The Post Manually action sends adjusted meta-data and draft pointer
>    to the Secretariat for manual validation and posting.  A receipt page
>    is generated instruction the submitter to wait.  Secretariat will
>    notify the submitter once the draft is posted or rejected.

Having come to this point in the description, I would wish for a diagram
- decision tree type - to see clearly where the different pages/actions
mentioned above belong, and how they are related to each other.

-- no further comments a this time --

	Henrik

---

From: stanislav shalunov <[email-masked]>
Date: 09 Sep 2004 13:14:27 -0400

Henrik Levkowetz <[email-masked]> writes:

> Let me note that I'm not convinced that an update frequency of
> archive drafts higher than on average once per two week,
> approximately, is beneficial.

The latency of I-D posting and the throughput of updates to an
individual I-D are, of course, orthogonal.  I think all would agree
that minimizing latency is advantageous.  Current latency (especially
before physical meetings) encourages duplication of posting mechanisms
(e.g., the authors send the I-D submission to [email-masked]
and copy the WG mailing list).  This is worse than instant processing
of submitted draft and generation of the automatic notice to the WG.

How often the draft should be updated is open to debate, but such
policy is best set by individual working groups and authors.  The I-D
submission tool, at most, might include a warning to the submitter if
the previous version of a draft is less than a week (or maybe two
days) old, but not prevent the author technically from submitting even
multiple drafts per day: this can be the right thing if clear errors
are found in a recently posted draft, especially if it's close to a
physical meeting submission deadline.

Another aspect of the current system that encourages duplication of
mechanisms is inability to include a note to the working group in the
submission (separate from a more static abstract); such note could
enumerate the issues addressed in the current version, sketch plans,
remind about open issues, or describe the status of the draft (e.g.,
``I believe this draft is now ready for WGLC'' or ``waiting for input
from foo'').

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed upside down.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 9 Sep 2004 13:08:35 -0600 (MDT)

Stas,

 	I agree with everything you said. We can later decide what 
submission gap should generate warnings (added as an XXX item to the 
draft)

Observations regarding duplication of posting mechanisms are already 
in the draft.

It is probably a good idea for the interface to report the time of the 
previous update. I've added that idea as an XXX to the draft.

The last comment about "inability to include a note" may eventually be 
addressed by WG snapshots and related mechanisms, but those are 
probably outside of TOOLs scope for now.

Thank you,

Alex.

---

From: stanislav shalunov <[email-masked]>
Date: 09 Sep 2004 15:21:08 -0400

> probably outside of TOOLs scope for now.

I think that the possible inclusion of a submitter's note with draft
submission (to be relayed to the working group in the I-D posting
announcement) is in scope for the purposes of discussion of an I-D
submission tool.  Further, what would be the downside?  The note could
be left empty.

This message is designed to be viewed at an angle of 45 degrees.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 9 Sep 2004 14:19:46 -0600 (MDT)

On Thu, 9 Sep 2004, stanislav shalunov wrote:

> submission tool.  Further, what would be the downside?  The note 
> could be left empty.

I agree that posting a note on WG mailing list would be in TOOLs team 
scope, but I think that an in-draft note would be an overall better 
solution for comments related to the draft state (rather than posting 
itself). Placing draft state notes (if any) in the draft itself lets 
folks outside of the WG (e.g., reviewers or related WGs) and folks new 
to the WG know what is going on without fishing for that info.

In other words, comments that have draft-long lifespan should be in 
the draft. Comments that are specific to the posting event, can be 
included in the announcement.

I cannot think of any useful comments that would be specific to the 
posting itself. Specifically, here are the examples of comments you 
proposed and my reaction to them:

> enumerate the issues addressed in the current version,

should be in the draft change log or draft state section

> sketch plans,

can be in the draft TODO section, but is probably not appropriate for 
either the draft or the announcement. TODO lists are better maintained 
separately as they can be quite dynamic.

> remind about open issues,

draft-specific issues should be documented in the draft, IMO, for 
reviewers and other interested parties to see

> or describe the status of the draft (e.g., ``I believe this draft is 
> now ready for WGLC'' or ``waiting for input from foo'').

That's exactly what draft state sections proposed in NEWTRK WG are 
supposed to document. IMO, these must be present in the draft itself 
to let reviewers and other interested parties know what is going on.

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 9 Sep 2004 15:29:31 -0600 (MDT)

> time to fix before 15:00 Eastern, then leave them to the next revision.

I think I incorporated all comments except for

> Here is the excerpt from the ID-checklist, with checkable nits 
> marked with "yes":
> 1.1 Formatting
>...

which I will add later as I am running out of time to format it.

I wonder if your approval would be needed to post -00 version. Are 
team submissions treated as WG submissions?

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 10 Sep 2004 00:20:45 +0200

Alex Rousskov wrote:

> I wonder if your approval would be needed to post -00 version. Are team 
> submissions treated as WG submissions?

I would expect so. I'll send a note to the secretariat.

	Henrik

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 10 Sep 2004 12:24:39 +0200

> ``I believe this draft is now ready for WGLC'' or ``waiting for input

I have argued elsewhere (newtrk) that we should encourage the inclusion of 
this information within the I-D; that way, it stays attached to the 
document, and serves to reinforce the idea that "this is a work in 
progress".

I also think that we should (somewhere) have a log of what happened to a 
draft, which is wider than the log currently kept in the IESG I-D tracker - 
but that's also a place to put such notes.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 10 Sep 2004 09:15:58 -0600 (MDT)

On Fri, 10 Sep 2004, Harald Tveit Alvestrand wrote:

> I also think that we should (somewhere) have a log of what happened 
> to a draft, which is wider than the log currently kept in the IESG 
> I-D tracker - but that's also a place to put such notes.

If the proposed submission interface flies, we will have more data and 
meta-data associated with each submission than we currently have. For 
example, we may have multiple formats for a given draft version and 
pre-extracted meta-information on authors and such.

I was going to propose that each draft gets its own "object", "space", 
"directory", or whatever you want to call it. That "object" will 
accumulate all draft-specific and draft-version-specific information, 
including the history of updates. Tools like ID tracker would refer to 
or update that info.

Documents and humans will be able to refer to the draft using its name 
(without the version number) and get access to all information 
currently available, including the latest version, diffs, etc. 
Referencing a specific version would still be supported, of course.

Alex.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 12 Sep 2004 23:07:30 +0200

> pre-extracted meta-information on authors and such.

We have that today. It is just not exposed on a public interface.
The secretariat manually extracts author information, title and abstract 
from the drafts and puts it into their internal database. That's where the 
I-D announcements come from.

(sometimes this gets messed up - there have been I-D announcements where 
the secretariat did not notice that the title had changed from version N to 
version N+1, so the announce went out with the old title. Automatic 
extraction SHOULD help here.)

> including the history of updates. Tools like ID tracker would refer to or
> update that info.
>
> (without the version number) and get access to all information currently
> available, including the latest version, diffs, etc. Referencing a
> specific version would still be supported, of course.

That is more than an I-D submission mechanism.
I'd like to have it too, but it's a bigger kettle of fish than the first 
tool.

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 12 Sep 2004 21:28:04 -0600 (MDT)

On Sun, 12 Sep 2004, Harald Tveit Alvestrand wrote:

> The secretariat manually extracts author information, title and abstract from 
> the drafts and puts it into their internal database. That's where the I-D 
> announcements come from.

Yes, except for multiple draft formats. I also suspect that the 
information automated interface will extract or ask for and collect 
will [eventually] be different from what Secretariat stores manually 
today; simply because automation changes the cost/benefit factor a 
lot.

> That is more than an I-D submission mechanism. I'd like to have it 
> too, but it's a bigger kettle of fish than the first tool.

I agree. Note, however, that the current list of _Secretariat_ 
requirements for the ID submission tool already includes draft 
manipulation/visualization requirements. While out of ID submission 
scope, these things are closely related, and we should start 
documenting them soon to avoid asking Secretariat to re-do a lot of 
fresh work. We might not get into specifics within the next few weeks, 
but we at least should try to show/document the direction we think 
draft storage, maintenance, and visualization should be going.

I am not sure whether a wiki or another draft is the right place to 
accumulate those thoughts. A wiki sounds a little more appropriate at 
this time, but I am also worried that our current team wiki is already 
quite messy.

Thanks,

Alex.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 13 Sep 2004 08:04:20 +0200

--On 12. september 2004 21:28 -0600 Alex Rousskov 
<[email-masked]> wrote:

>> from  the drafts and puts it into their internal database. That's where
>> the I-D  announcements come from.
>
> Yes, except for multiple draft formats.

We have that too - look at the .pdf and .ps files in the I-D directory.

> I also suspect that the
> information automated interface will extract or ask for and collect will
> [eventually] be different from what Secretariat stores manually today;
> simply because automation changes the cost/benefit factor a lot.

Agreed.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 13 Sep 2004 08:55:30 -0600 (MDT)

> We have that too - look at the .pdf and .ps files in the I-D 

I stand corrected. There are indeed several .pdf and .ps files 
accompanying plain text drafts.

Alex.