Subject: [Tools-team] Minutes from 25 Aug 2004 Telechat

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 25 Aug 2004 18:54:14 +0200

Here is the proposed agenda for today.

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

1. Agenda bashing
	
	Agenda Ok

2. Comments on minutes from last teleconference.

	No comments

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.

	Not done yet, will be done not later than this weekend.
	Need some input on the schedule - short discussion was
	held:  Focus on secretariat tools for the first 6 months,
	but take input on other tools; put toghether schedule for
	individual tools based on input from list and secretariat.

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

	Not done yet, will be done not later than this weekend.

   * Henrik will contact Alex

	Done

   * Henrik or Alex will start the Tools inventory/prio draft

	Started, first draft to list thu/fri.

   * Henrik will add tools.ietf.org to his DNS,  Stas and Harald will
     run secondaries, so this is ready for when delegation is made from
     ietf.org

	Done

   * Henrik will solicit ID-submission requirements from Secretariat

	Response from Barbara received, sent to the list. Expect
	response next week

   -- The following items were outstanding from the meeting 2 weeks ago,
     but not included in last weeks action items, (although they should
     have been.)

   * Alex   will start the ID-submission tool draft.

	Started, to be sent to the list today or tomorrow.

   * Henrik will mail secretariat re. subdomain delegation
	(done, but not completed by the secretariat yet)

   * Henrik will request creation of "[email-masked]" list
	(done, but not completed by secretariat yet)

   * Henrik will solicit requirements from the secretariat
            for the ID-submission tool
	Done

   * 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.

4. Status of drafts

	Reviewed above.

5. Next steps

	Larry: Summary the packages reviewed.

6. Any other business.

	None

7. Action items

  == From earlier weeks:

   * 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.

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

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

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

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

   * 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.

  == New:

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

   * Henrik Get wiki set up

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

8. Next meeting:

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

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

---

From: stanislav shalunov <[email-masked]>
Date: 25 Aug 2004 14:39:25 -0400

The recording of today's call is at
http://netflow.internet2.edu/tools/20040825-tools.wav

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

"Computer Science is no more about computers than astronomy is about
telescopes."					-- E. W. Dijkstra

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 25 Aug 2004 17:19:32 -0600 (MDT)

>           etc which was started before IETF-60, but temporarily

I suggest that we spend a few cycles discussing an "IETF tools 
framework" that will mention key IETF tools and focus on tools 
relationships and common components rather than individual tool 
requirements. Depending on the initial result, we can decide to 
document the framework somewhere or abandon the idea.

Here are a few major framework areas that I can identify:

 	1. Document Repository: includes meta-information and
 	   actual texts for drafts, RFCs, errata, WG charters,
 	   agendas, minutes, etc. I am not sure whether WG mailing
 	   list archives and issue lists belong here, but I suspect
 	   they do.

 	2. People Repository: information about IETF participants,
 	   initially populated with information about IESG, Chairs,
 	   and Authors to facilitate IETF-wide authentication.
 	   Should this be an Actor or Entity Repository instead
 	   to include information about WGs, teams, IESG, IAB, etc?

 	3. Event Queue: document publication, standard approval, errata
 	   updates and similar events. This area is essential for
 	   implementing "monitor this WG/draft/etc" or "let me know
 	   of any last calls" services. Some events might not be
 	   "stored" anywhere, but may trigger updates of document
 	   and people repositories, among other things.

If the above makes sense, we can then describe major tool interaction 
and major shared components in terms of their effects on the above 
areas.

For example, we can say that ID submission tool uses People Repository 
to authenticate the submitter of the draft, places the new revision 
into the Document Repository, and generates events such as "draft 
updated" or "new WG draft available". These events may reach 
interested parties, including, for example, authors of documents that 
refer to the updated draft.

Furthermore, given the above framework, corresponding shared 
tools/interfaces come into picture:

 	1. Document Repository Manager: accepts new documents and
 	   meta-information, maintains links among documents, deletes
 	   documents, etc.

 	2. People Repository Manager: same as Document Repository
 	   Manager but for information about IETF participants. This
 	   manager can perform authentication among other things.

 	3. Event Dispatcher: queues "let me know when..." requests,
 	   accepts new events, archives them(?), and forwards them
 	   to those who wanted to be informed of them.

While a comprehensive framework (the above is just an incomplete and 
buggy sketch) would both make building tools easier and give IETFers a 
coherent "IETF interface", I do not know whether IETF Secretariat 
would be willing to move from a collection of isolated tools to a 
"system". It is certainly easier to build any given isolated tool than 
to build the framework and the tool. Savings and benefits from a 
coherent framework can only be long-term...

One the other hand, several items on Secretariat TODO list and Harald 
comments during one of the conference calls may indicate desire to 
move away from individual tools to a more organized approach. We 
certainly do not have to wait for a complete framework to start 
implementing key tools; the question is one of the direction and 
willingness to spend "enough" cycles on long-term goals while doing 
individual tool development/adoption.

I would be interested in hearing comments from TOOLs members _and_ 
Secretariat/IESG folks. Do we want to move in the coherent framework 
direction?

Thanks,

Alex.

---

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

using different terminology.... playing....

documents: stuff that is worked on (charters, I-Ds (my abstract concept of 
I-D is without version), RFCs, Web pages, IANA databases....)

actors: people who do things to documents. some actors are roles filled by 
multiple people.

tasks: stuff that actors are supposed to do to documents.
completing a task may generate a new document, a new task, both, or 
neither. so may working on a task without completing it....
a document can be referred to by multiple tasks simultaneously. a task can 
refer to multiple documents.

events: the result of an actor doing a task to a document (not necessarily 
completing it). may leave information behind that should not be considered 
a document in its own right.

we need document repositories (to know what the current document set is), 
actor databases (knowing who can do which tasks, and which people fill 
roles), task databases (figuring out who's supposed to do what next to 
what), and event logs (saying what happened).

I think most of what we currently have fits within such a model - but we do 
things differently in different corners, for historical or practical 
reasons.

ie WG charter change is not tracked in I-D tracker, IANA database updates 
are tracked in an IANA spreadsheet, RFC Editor history log is the archives 
of the ietf-announce list.....

sense?

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 27 Aug 2004 15:05:08 +0200

Harald Tveit Alvestrand wrote:

> documents: stuff that is worked on (charters, I-Ds (my abstract concept 
> of I-D is without version), RFCs, Web pages, IANA databases....)
> 
> actors: people who do things to documents. some actors are roles filled 
> by multiple people.
> 
> a document can be referred to by multiple tasks simultaneously. a task 
> can refer to multiple documents.
> 
> events: the result of an actor doing a task to a document (not 
> necessarily completing it). may leave information behind that should not 
> be considered a document in its own right.
> 
> we need document repositories (to know what the current document set 
> is), actor databases (knowing who can do which tasks, and which people 
> fill roles), task databases (figuring out who's supposed to do what next 
> to what), and event logs (saying what happened).
> 
> I think most of what we currently have fits within such a model - but we 
> do things differently in different corners, for historical or practical 
> reasons.
> 
> ie WG charter change is not tracked in I-D tracker, IANA database 
> updates are tracked in an IANA spreadsheet, RFC Editor history log is 
> the archives of the ietf-announce list.....
> 
> sense?

Yes, I like it, it's a pretty clean model.

One of the complexities may be to provide interfaces to a number of the
established ways of working with these things - like mailing lists,
repositories, archives...

	Henrik

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 27 Aug 2004 15:15:51 +0200

> repositories, archives...

yes - we need to keep pretty firmly in mind what the purpose of each piece 
is, so that we can see when things are the way they are for a reason, and 
when they are "just because they've always been that way"....

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 27 Aug 2004 15:16:18 +0200

Two points come to my mind here:

   1)  	With respect to actors / people, we have those who feel it's
	natural to have a framework identity associated with their
	role(s) - ADs, Chairs, Secretariat folks etc. - and those of
	whom I'd be reluctant to require registration with a framework
	- mailing list participant, draft authors.

   2)	I think it is good if tools, even if part of a framework, can
	be deployed in a very decentralised manner - which may mean
	that they generally have http interfaces - be it using CGI
	or XML based protocols.  I'd be reluctant building a monolith...

If we can find or build a framework on such a basis, I think it might
be a good idea.  Or maybe that means we're talking about a common
library rather than a framework?

	Henrik

Alex Rousskov wrote:

> requirements. Depending on the initial result, we can decide to document 
> the framework somewhere or abandon the idea.
> 
> and major shared components in terms of their effects on the above areas.
> 
> to authenticate the submitter of the draft, places the new revision into 
> the Document Repository, and generates events such as "draft updated" or 
> "new WG draft available". These events may reach interested parties, 
> including, for example, authors of documents that refer to the updated 
> draft.
> 
> coherent "IETF interface", I do not know whether IETF Secretariat would 
> be willing to move from a collection of isolated tools to a "system". It 
> is certainly easier to build any given isolated tool than to build the 
> framework and the tool. Savings and benefits from a coherent framework 
> can only be long-term...
> 
> comments during one of the conference calls may indicate desire to move 
> away from individual tools to a more organized approach. We certainly do 
> not have to wait for a complete framework to start implementing key 
> tools; the question is one of the direction and willingness to spend 
> "enough" cycles on long-term goals while doing individual tool 
> development/adoption.
>

---

From: Larry Masinter <[email-masked]>
Date: Sat, 28 Aug 2004 10:27:40 -0700

> 	- mailing list participant, draft authors.

We may need to require registration for those participants for
which authentication is necessary. I think this may include,
if not "draft authors" at least "draft posters", i.e., the
author who posts an Internet Draft.

Mailing list participants do not require authentication only
because there is a simple check on bogus postings: mailing lists
that only allow members to post have the insurance that the
purported author will get a copy, and can detect forgeries.

(There are some lists that are getting virus-spam that seems
to be from mailing list members, though; if this becomes
a more serious problem, we may start to want authentication,
and thus registration, even for mailing list participants.)

> library rather than a framework?

Most distributed system technology these days is designed
to be deployed in a distributed manner, whether it is EJB
or web services.

Larry
-- 
http://larry.masinter.net

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 28 Aug 2004 14:42:51 +0200

> library rather than a framework?

I'm thinking in terms of a conceptual framework, so that we're able to talk 
about the things using the same terms... I'd think that implementing such a 
framework is a far more ambitious undertaking.

BTW: Mailing list members already have identities in the system (their 
email address). We should make sure the system mostly works without 
requiring that identity to be linked to a person - unless we have to.

I think we have to for someone who submits an internet-draft, given that 
this person makes IPR guarantees that the IETF depends on..... but that's 
something we may need to ask a lawyer about.

             Harald

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 29 Aug 2004 14:23:06 +0200

Harald Tveit Alvestrand wrote:

> this person makes IPR guarantees that the IETF depends on..... but 
> that's something we may need to ask a lawyer about.

Whups, that could be a rather major requirement.

I've been thinking in
terms of return routability (as tested when you sign up for a mailing list)
coupled with the requirement that the submitter address being one of the
appropriate WG chairs or one of the addresses given in the Authors' Address
section of the draft.

I've also personally had a preference for this over a system where you have
to register as user in any kind of framework in order to be permitted to
submit a draft - this smacks too much of the membership register we don't
have.

However, having to have guarantees about the linkage of a submitter ID
(email-address) to a particular person takes us off in a different direction,
where we may have to require that submissions are signed in a way that
with reasonable certainty links the submission to a person.  GPG signatures
might or might not be sufficient - perhaps only signatures based on certs
issued by some (which?) CA's will be acceptable, and/or GPG signatures based
on GPG keys which have a signature chain back to a ?? chair or AD ??

Mmm, this requirement would be a requirement on drafts submitted for
publication, rather than all drafts, I think?

	Henrik

---

From: Larry Masinter <[email-masked]>
Date: Sun, 29 Aug 2004 12:26:43 -0700

Trust, but verify.

For example:

It is possible to accept drafts for which verification of
the submitter's identity has not been obtained, but note
this fact, in the draft or the draft index.

Rather than making authentication by one mechanism or
another a requirement, leave it an option, and make
it visible.

Readers may want to take measures to validate the
origin of drafts for which authorship is uncertain.

Larry

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 29 Aug 2004 21:35:43 +0200

All drafts, period.

I don't think we actually need to be able to PROVE identity.
But we do need to be able to do some kind of "did you submit this?" check 
if the issue ever comes up.

I'll check with the lawyer....

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 29 Aug 2004 21:47:52 +0200

Hi Harald,

> All drafts, period.

That's pretty clear, then :-)

> if the issue ever comes up.

Ok, that makes a verification similar to mailing list subscription verifications
more feasible again.  

> I'll check with the lawyer....

Good :-)

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 29 Aug 2004 21:54:38 +0200

> this fact, in the draft or the draft index.

That is an interesting idea :-)  Should be not too difficult
to handle e.g. S/MIME or PGP signed submission verification
mails, and note the level of verification in an index.

> origin of drafts for which authorship is uncertain.

However, it does not really handle the general issue of what
kind of certainty of identity the IETF can accept (in general)
for the submitter of a draft...

	Henrik

---

From: Bill Fenner <[email-masked]>
Date: Sun, 29 Aug 2004 15:38:57 -0700

>	or XML based protocols.  I'd be reluctant building a monolith...

IMHO, s/good/critical/

I'd be willing to bet that we'll need to interact with someone who
wants to use their own tools (or the same tools on their own
infrastructure).  E.g., the event of "IESG approves RFC" may
need to travel to the RFC-Editor's tracking system.

  Bill

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 30 Aug 2004 01:29:36 +0200

> need to travel to the RFC-Editor's tracking system.

Check.  No contest.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Aug 2004 09:29:50 -0600 (MDT)

I did not hear any strong objections to defining an IETF interfaces 
framework. There were several very useful comments, and I suspect we 
can unify them without major battles. I would like to make sure these 
ideas do not disappear without a record, and I would like to be able 
to refer to them when polishing the ID submission draft.

What is the best way to document the framework? A stand-alone draft? 
As a part of the Tools Inventory draft? A wiki page? Something else?

Thanks,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 30 Aug 2004 18:17:26 +0200

Hi Alex,

> As a part of the Tools Inventory draft? A wiki page? Something else?

What about starting it off as a wiki page?  I've started pulling together
the tools inventory, but I'm going to do it on the wiki first, then do
the draft - there are a number of links associated, and the draft format
 more cumbersome than a wiki page while trying to organize this.

	Henrik

---

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

On Sat, 28 Aug 2004, Larry Masinter wrote:

> which authentication is necessary.

I think this the right approach, except I would sate, more precisely:

 	require authentication for those actions
 	for which authentication is necessary

Note that this would be no different than the current status quo! The 
difference would be in details on how to make authentication strong 
and both human- and software-friendly.

> Mailing list participants do not require authentication only because 
> there is a simple check on bogus postings: mailing lists that only 
> allow members to post have the insurance that the purported author 
> will get a copy, and can detect forgeries.

The above is a very weak check, of course. I usually do not read list 
posts that my mail reader marks as "from self", and if I post few 
messages a day, I would not notice that I made "extra" postings.

> and thus registration, even for mailing list participants.)

It is already a serious problem, IMO. A lot of human hours are spent 
by mail list administrators on detecting non-spam in spam staging 
areas. As a result, administrators resort to automated measures that 
work poorly. I personally was silently dropped from a WG mailing list, 
with my postings not visible to mailing list members and vice versa, 
due to such poor automation. IIRC, it took me more than a week to 
detect that something is not right, and I "missed" a couple of 
important discussions.

Alex.

---

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

On Sun, 29 Aug 2004, Larry Masinter wrote:

> Rather than making authentication by one mechanism or another a 
> requirement, leave it an option, and make it visible.

I do not like that approach because it effectively makes 
authentication useless. If anybody can post my draft, and most readers 
would not care to check the "authenticated" flag on the posted draft, 
then authenticating myself is of little or no value.

As an extreme example, consider a simple script that posts a rogue 
draft text right after an authenticated author posts a new revision. 
Authenticated posting would not be even visible for virtually all 
readers.

> Readers may want to take measures to validate the origin of drafts 
> for which authorship is uncertain.

by asking the draft author using unauthenticated address in the draft?

IMO, the only serious problem with author authentication is anonymity. 
Anonymous drafts are rare and can use the exceptional human-to-human 
mode that, by definition, does not require authentication. Do you see 
any other problems with requiring submitters to authenticate 
themselves?

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Aug 2004 11:05:45 -0600 (MDT)

On Sat, 28 Aug 2004, Harald Tveit Alvestrand wrote:

> We should make sure the system mostly works without requiring that 
> identity to be linked to a person - unless we have to.

Agreed.

Legal issues aside, multiple identities for a single person, a single 
identity for multiple persons, and even software-managed identity 
without specific human association should be allowed in principle.

However, besides legal issues, the difficulty would be in surviving a 
malicious attack polluting IETF repositories with millions of 
authenticated but bogus drafts. If and as soon as we remove 
rate-limiting Secretariat from the loop, we have to be ready for this 
kind of abuse.

Alex.

---

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

On Sun, 29 Aug 2004, Harald Tveit Alvestrand wrote:

> I don't think we actually need to be able to PROVE identity. But we 
> do need to be able to do some kind of "did you submit this?" check 

I am not sure I follow. If we cannot prove submitter identity (to a 
required degree of proof) when the draft is posted, then we cannot 
implement a post-factum "did you submit this?" check. A malicious 
submitter would just say "no, I did not; give me my company IP back!". 
We have to rely on information logged during the submission (which may 
require several iterations and essentially means proving identity).

AFAIK, electronic signatures are starting to gain legal acceptance so 
we may have good luck with using modern authentication methods.

We can also discuss recommending "now respond with this key to 
complete your post" e-mail interface as an alternative (it will verify 
temporary control of submitter's e-mail address).

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 30 Aug 2004 19:44:55 +0200

Thinking out loud, what about something like the following:

Posting of workgroup -00 drafts require chair approval.  Chairs are
already registered somewhere with an email address.  An approval request
could be automatically sent to the registered chair address, with an
enclosed cookie, and approval would be as simple as the chair replying
to the request.

The chair's approval would be registered as an approval for any of the
e-mail addresses given for authors in the -00 draft to submit later
revisions.  Adding a new author/editor/submitter would requre a repeat
of the chair approval step.

Any post-00 submission would require authorisation from the submitter
e-mail address, by sending a mail containing a cookie to the submitter
and having the submitter reply to that email, in analogy with the
chair approval mechanism above.

In order to limit malicious automated submissions, rate limit the
submissions to a rate of e.g. 7 submissions per 1-week sliding window.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Aug 2004 12:03:35 -0600 (MDT)

Do we want to require support for software ID submitters? It is a 
SHOULD-level requirement in the current draft.

I included the requirement because I think the draft repository should 
reflect the current state of the draft. Being non-archival 
work-in-progress and the only IETF repository for current WG work, it 
is not suitable for "stable views" or "review outside of the WG" 
snapshots. Thus, ideally, it must be no more stale than public branch 
of author's CVS tree. It must be come a mirror of authors public work, 
with no ongoing effort on author's part.

IETF may need to invent "WG snapshots" and other semi-stable things, 
but should not abuse the ID interface for that.

What are your thoughts? Should I yank automated submission from the 
draft? Make it a MAY?

Thanks,

Alex.

---

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

> Thinking out loud, what about something like the following:

First of all, I hope we can have a generic authentication mechanism 
for major IETF actions rather than several specific per-action 
authentication mechanisms. If there is consensus about that, we should 
keep the general applicability in mind when deciding on specific 
authentication procedures for a given action, such as draft 
submission.

For example, there could be a generic "can somebody read Actor's 
e-mail and confirm?" authentication procedure (with features like 
"verify only once in a while", "verify always", "use alternate 
address", etc.). We can compare that with other procedures like the 
use of PGL signatures.

> already registered somewhere with an email address.  An approval 
> request could be automatically sent to the registered chair address, 
> with an enclosed cookie, and approval would be as simple as the 
> chair replying to the request.
>
> The chair's approval would be registered as an approval for any of 
> the e-mail addresses given for authors in the -00 draft to submit 
> later revisions.  Adding a new author/editor/submitter would requre 
> a repeat of the chair approval step.

Why not let the Chair submit any WG draft (as currently required for 
the -00 draft in the ID submission draft)? Why introduce a separate 
approval step/stage?

With two steps, we have more things to worry about. For example, do we 
wait for chairs approval or does the system solicit Chair approval 
based on draft WG name? If we wait, do we remind the chairs anyway? 
How long do we wait? What if Chair's approval comes in before the 
draft? Can the Chair dis-approve? What if one Chair dis-approves and 
the other approves; would that depend on the order of chair e-mails? 
Etc. etc.

> Any post-00 submission would require authorisation from the 
> submitter e-mail address, by sending a mail containing a cookie to 
> the submitter and having the submitter reply to that email, in 
> analogy with the chair approval mechanism above.

If we let the Chair post any WG draft, we also solve the problem of a 
WG draft N+1st revision needed to be posted in the absence of original 
author(s).

> submissions to a rate of e.g. 7 submissions per 1-week sliding 

This is a separate question, I guess. If rate-limiting is the 
solution, we should be careful to limit based on the right sample. 
Malicious automated submissions can create malicious automated e-mail 
addresses so limiting using "per address" approach seems insufficient. 
(I would also think that 7 is way too low, but that is an even less 
important question for now).

Thanks,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 30 Aug 2004 21:33:24 +0200

Hi Alex,

Agreed.

> address", etc.). We can compare that with other procedures like the 

Good thinking.

> the -00 draft in the ID submission draft)? Why introduce a separate 

Mmm, the above *is* my view of the current process - the author submits
and the secretariat queries the chair.

Additionally, it saves the chairs from having to do the sumbission work,
and the procedure looks the same in all cases for the submitter.

> based on draft WG name? 

Solicit, clearly (in my mind)

> If we wait, do we remind the chairs anyway? 
> How long do we wait? 

The generic confirm by email procedure would have to have a timeout,
anyway, I think.  Don't think this is special. 

> What if Chair's approval comes in before the 
> draft? 

Won't work, needs the cookie.

> Can the Chair dis-approve? What if one Chair dis-approves and 

Simplest is to just let the action time out if no approval is
received.  It should be an edge case, and the chair should 
communicate with an author who's submitted due to a misunderstanding
anyway.  If one chair has approved the submission, that's it.

> WG draft N+1st revision needed to be posted in the absence of original 

Yes.  But as a Chair I'd definitely push back on having to post every
draft for my workgroup.  And we'd be creating work for the Chairs at
the same time we'd be removing it from the secretariat.  Not a win-win
situation, I think.

> important question for now).

Separate question, yes.  As for creating new addresses, that wouldn't
work for -xx versions if only the addresses in the original approved -00
could submit.  For -00 versions it could still be a problem, but it would
be limited to a spate of "spam" mails to the chairs if we used the 
method I mentioned in my first paragraph of the original posting, +
storage on the server.  Don't know if we need to worry too much about
this - it might never become a problem...

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 30 Aug 2004 21:59:40 +0200

Hi Alex,

> with no ongoing effort on author's part.

I think that this changes the nature of the ID-repository too much
in a direction I'm not sure is beneficial.

> but should not abuse the ID interface for that.

I'd much prefer to invent a different repository for the rapidly 
changing reflection of the editor's work, possibly patterned
closely after cvs / svn. 

This could for instance be part of a workgroup support toolset.
Possibly I'm biased because that's similar to the way I've handled
e.g. the EAP 2284bis draft I worked on not too long ago...
 http://ietf.levkowetz.com/drafts/eap/rfc2284bis/

> What are your thoughts? Should I yank automated submission from the 

I'd comment it out for now - there's the additional issue of always
being able to say that a person did the submission and is responsible
for the IPR assurances given in the document.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Aug 2004 14:12:22 -0600 (MDT)

On Mon, 30 Aug 2004, Henrik Levkowetz wrote:

>>> Posting of workgroup -00 drafts require chair approval.  Chairs 
>>> are already registered somewhere with an email address.  An 
>>> approval request could be automatically sent to the registered 
>>> chair address, with an enclosed cookie, and approval would be as 
>>> simple as the chair replying to the request.
>>>
>>> later revisions.  Adding a new author/editor/submitter would 
>>> requre a repeat of the chair approval step.
>>
>> Why not let the Chair submit any WG draft (as currently required 
>> for the -00 draft in the ID submission draft)? Why introduce a 
>> separate approval step/stage?
>
> Mmm, the above *is* my view of the current process - the author 
> submits and the secretariat queries the chair.

I was referring to the current requirements in 
draft-ietf-tools-draft-submission draft, not current IETF 
requirements. Sorry for being unclear. Recall that we should compare 
our solutions with known ideals, not just with current practice as the 
latter is often broken.

> Additionally, it saves the chairs from having to do the sumbission 

True, but there are two sides of a coin here. If we think it is a lot 
of work to submit 00, then, by implication, there are a lot of 
non-obvious options to specify. Then, it may be a good idea to let the 
Chair do it, as the Chair May Know Better (TM). On the other hand, if 
submitting a 00 draft is trivial, then we are not adding that much 
more work for the Chair (especially since the Chair would still have 
to do something to approve the submission in the other scheme).

This is unlikely to be an important performance optimization given the 
number of 00 versions of WG drafts per year each chair would have to 
submit. Thus, we are talking primarily about a clean functional 
interface here.

> and the procedure looks the same in all cases for the submitter.

Not exactly, with chair-approves-00, the submitter has to wait/expect 
chair approval to check the submission as "done". While the system may 
do all the legwork, the human submitter still has to know about 
approval and verify that everything went smoothly.

The advantage of the chair-approves-00 scheme is that there is no 
special approval step to worry about and any submitter faces the same 
interface, the same sequence of actions.

>> With two steps, we have more things to worry about. For example, do 
>> we wait for chairs approval or does the system solicit Chair 
>> approval based on draft WG name?
>

OK. Then we have to deal with bypassing Chair's spam filters and with 
scripts spamming Chairs by submitting bogus 00 drafts (intentionally 
or as a result of some runaway automation).

>> If we wait, do we remind the chairs anyway? How long do we wait?
>

It is special because you will need to document two timeouts (at 
least): timeout to verify e-mail control and approval timeout. These 
timeouts might have the same value (most likely NOT!), but they are 
different states in the state machine.

>> Can the Chair dis-approve? What if one Chair dis-approves and the 
>> other approves; would that depend on the order of chair e-mails? 
>> Etc. etc.
>

Sure. I am not saying there are no solutions, especially if submitters 
can tolerate long timeouts without knowing what is going on (Did my 
chair forget? Is he on vacation? Was the approval request caught in 
his spam filter? Does he not want me to publish? Is he thinking the 
other Chair will approve? ...).

I am saying that there are many more problems we need to solve if we 
add more state. Some of the problems are trivial, but why complicate 
the interface? Is it really that much more difficult for the Chair to 
submit a pre-packaged 00 draft or even just meta-information?

>> If we let the Chair post any WG draft, we also solve the problem of 
>> a WG draft N+1st revision needed to be posted in the absence of 
>> original author(s).
>
> Yes.  But as a Chair I'd definitely push back on having to post 
> every draft for my workgroup.  And we'd be creating work for the 
> Chairs at the same time we'd be removing it from the secretariat. 
> Not a win-win situation, I think.

Not every draft. Just the 00 version of the draft. How many 00 drafts 
does a typical group have in a year? I do not think comparing with 
Secretariat overheads is accurate because we are removing humans from 
the publication loop (for all drafts). We are not increasing the 
number of human submitters. In fact, we are decreasing the number of 
humans involved with the chairs-submit-00 scheme (only sightly, again, 
we are talking about a dozen or so 00 drafts per year for a typical 
WG; all other drafts are not required to be submitted by a Chair!).

>> Malicious automated submissions can create malicious automated 
>> e-mail addresses so limiting using "per address" approach seems 
>> insufficient. (I would also think that 7 is way too low, but that 
>> is an even less important question for now).
>
> Separate question, yes.  As for creating new addresses, that 
> wouldn't work for -xx versions if only the addresses in the original 
> approved -00 could submit.  For -00 versions it could still be a 
> problem, but it would be limited to a spate of "spam" mails to the 
> chairs if we used the method I mentioned in my first paragraph of 
> the original posting, + storage on the server.  Don't know if we 
> need to worry too much about this - it might never become a 
> problem...

You may be forgetting about non-WG drafts that do not require Chair 
approval to be posted but can consume a lot of IETF resources and 
attention...

At any rate, while I agree that automated abuse is unlikely to become 
a problem, I still think we should at the very least document our 
refusal to solve it (if that's the team consensus).

Thanks,

Alex.

---

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

On Mon, 30 Aug 2004, Henrik Levkowetz wrote:

> changing reflection of the editor's work, possibly patterned closely 
> after cvs / svn.

Interesting! The "WG snapshot" ideas discussed elsewhere in IETF try 
to create "more stable IDs"; your idea would create "less stable IDs". 
Both are out of this WG scope, but I find the symmetry interesting.

> http://ietf.levkowetz.com/drafts/eap/rfc2284bis/

Yes, many WGs have pages like that (usually not that pretty or 
advanced). To me, it was always an indication of inappropriate IETF 
publication mechanisms. What you are saying, essentially, that IETF 
IDs carry some perceived "stability" with them, even though all IETF 
documents deny them any such qualities. Not unlike the situation with 
RFCs, I guess!

Personally, I would prefer to have "unstable drafts" plus "stable 
snapshots" then a 3-way scheme of "unstable drafts", "semi-stable 
drafts", and "stable snapshots", but I see your point. It is just 
difficult for me to define "semi-stable drafts" category (but I can 
define the other two).

> I'd comment it out for now -

Noted. Any other opinions?

> there's the additional issue of always being able to say that a 
> person did the submission and is responsible for the IPR assurances 
> given in the document.

Given the fact that tools like xml2rfc _generate_ IPR assurances 
(sometimes introducing modifications to them), I find claims that 
humans must explicitly submit drafts due to IPR issues rather weak or, 
at least, out of scope. The submitter must assure, but it should be OK 
to assure via automated means if the submitter explicitly consents to 
using such means. See W3C mailing list archival policy as an example.

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 30 Aug 2004 22:33:56 +0200

Hi Alex,

> On Mon, 30 Aug 2004, Henrik Levkowetz wrote:
...
> our solutions with known ideals, not just with current practice as the 

Ah.  But i don't agree it's ideal for the submitter to send the draft
to the chair, who has to enter it :-)

> to do something to approve the submission in the other scheme).

Yes, but that could be as simple as responding to an email - as is 
the case today - and additionally, it works as a notification to the
chair that the draft has been sumbitted.

> submit. Thus, we are talking primarily about a clean functional 

Maybe not an optimization, but it would certainly be an annoyance 
having to do the submission work in addition to the various nudging
and followup work.  I'd not be happy about that.

> approval and verify that everything went smoothly.

True.  But the submitter always submits using the same interface 
- with your alternative, the -00 submission has to be done by email
to the chair, and then the chair has to use the sumbission tool.
If the sumbission fails ( for instance because of boilerplate errors )
the chair has to manually feed that information back to the sumbitter.

I wouldn't be happy about that...

> interface, the same sequence of actions.

No, the -00 author has to know about a different way - by mail to
the Chair.

> or as a result of some runaway automation).

Yes, but that's not different from the case for any mailing list 
subscription, or for any draft the chair may submit as author.

> different states in the state machine.

Yes, but if we have a generic mechanism, we surely don't expect to
deploy it with the same parameters in every instance??

> submit a pre-packaged 00 draft or even just meta-information?

Actually, having the chair do the sumbission may simplify the tool,
but make life harder on both chairs and -00 submitters, which is the
wrong way around.

> Not every draft. 

Sorry, I understood your paragraph above as proposing that.  If you
didn't mean that, disregard my comment.

> Just the 00 version of the draft. How many 00 drafts 
...
> approval to be posted but can consume a lot of IETF resources and 

Ah, yes. Quite right.

> refusal to solve it (if that's the team consensus).

Quite so, I agree (whichever way we go)

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 30 Aug 2004 22:44:42 +0200

Hi Alex,

> Both are out of this WG scope, but I find the symmetry interesting.

Not quite sure the latter is out of our scope :-)

I'd see it like this:  Having to start out with *one* mechanism, we have
the current draft publication as it is used today.  This is a compromise
between a number of different needs.  We are now considering refinements
which will better cater to some needs than what the current mechanism
does - one need has been more stable ID's - another has been insight
into the editor work.  So the "WG snapshot" is aiming at improving one 
aspect, while capturing rapid updates is a very different need.

> documents deny them any such qualities. Not unlike the situation with 

Well, they are stable enough that a workgroup can refer to them during
discussions without confusion about what text is being discussed. Having
a new published draft sometime multiple times per day will nearly
guarantee that two or more people discussing the draft will have read
different versions...

> difficult for me to define "semi-stable drafts" category (but I can 

Umm, don't know if my comments above has improved on this?

> using such means. See W3C mailing list archival policy as an example.

Umm, not sure that's good enough from a lawyer's point of view...

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Aug 2004 14:56:58 -0600 (MDT)

On Mon, 30 Aug 2004, Henrik Levkowetz wrote:

> Ah.  But i don't agree it's ideal for the submitter to send the 
> draft to the chair, who has to enter it :-)

I do not think that's ideal either, but, given unavoidable 
WG-chair-author interaction in this case (due to WG consensus calls), 
it seems to me that uploading a file is a much smaller price than 
having a two-steps 00 publication interface. Note that the future WG 
draft is usually posted on the WG list for WG consensus call (to 
accept the draft). Thus, there is often no separate author-chair 
e-mail required. The chair makes consensus call and submits the draft.

And, again, we would need that chair-can-submit-any-wg-draft interface 
anyway (as an exception when authors leave or not available)!

Let's agree to disagree for now and wait for more opinions. I would 
also propose a [very] alternative solution in a separate e-mail.

Thanks,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 30 Aug 2004 23:05:16 +0200

Alex Rousskov wrote:
> WG-chair-author interaction in this case (due to WG consensus calls), it 
> seems to me that uploading a file is a much smaller price than having a 
> two-steps 00 publication interface. Note that the future WG draft is 
> usually posted on the WG list for WG consensus call (to accept the 
> draft). Thus, there is often no separate author-chair e-mail required. 
> The chair makes consensus call and submits the draft.

No, the WG normally agrees to adopt a certain version of an idividual
draft; the authors then has to re-name and re-process with the new
name, at a minimum, even if no other minor changes have to be made
as a result of comments from the workgroup.

> anyway (as an exception when authors leave or not available)!

Yes. But that is a separate issue.

> Let's agree to disagree for now and wait for more opinions. I would also 
> propose a [very] alternative solution in a separate e-mail.

I do think the "get chair's approval by return mail" is a fairly 
simple thing, if we already have the "get author's approval by return
mail mechanism", so I guess we'll have to continue to disagree ,:-)

I look forward to seeing your alternative proposal.  

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Aug 2004 15:14:09 -0600 (MDT)

Henrik and I spent a few cycles and failed to agree whether 
chair-submits-00 or author-submits-and-chair-approves-00 scheme is 
better. I believe the whole argument can be avoided if we look at the 
problem from draft _work_ authorization rather than draft _submission_ 
authorization point of view:

What if a Chair that makes "WG draft" consensus call, could authorize 
corresponding WG draft work as a stand-alone action, recorded by the 
IETF system (without submitting any drafts)? When an author submits 
the corresponding WG draft (any version) the system would check for 
prior Chair authorization. If the authorization exists, the draft is 
posted. If not, the draft is rejected and the author is instructed to 
seek WG/Chair approval first.

A slight variation: instead of the Chair recording a work approval in 
the "system", the Chair can generate an "approval token" (a text 
string) and give it to the author. The author would attach the 
"approval token" to all WG draft revisions she submits. IETF tools can 
generate tokens for Chairs, of course. There can be a black list of 
stolen approval tokens and tokens would expire, etc.

In both variations, it would be possible to both authorize WG draft 
work and stop such work if the group decides to abandon the draft. It 
would also be possible to stop a given rogue author for submitting 
changes (perhaps the author was banned from group mailing list using 
appropriate IETF procedures).

I like this scheme also because it allows us to capture some 
information about the WG draft work as a whole (e.g., deadlines, 
expected RFC status, dependencies, etc), without piggybacking 
exceptions to the WG draft submission interface. This can also 
_reduce_ work for Chairs as the interface can send appropriate e-mail 
message to the mailing list, declaring consensus to adopt/start a WG 
draft and specifying all the details (that a busy Chair might forget).

What do you think? Would any of the above be better than 
chair-submits-00 or author-submits-and-chair-approves-00 scheme?

Thanks,

Alex.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 30 Aug 2004 19:21:17 -0700

I think, in general, it is a good idea if the tools do
not require unnecessary serialization of multi-party
protocols.

In the case of submission of a -00 draft, there are two
parties, the submitter (one of the listed authors of the
WG draft) and the approving chair (one of the listed
co-chairs of the working group).

There are two actions:

  submitter prepares document and submits it for posting
  approving chair approves this event.

These events should be allowed in either order:

a) The approving chair can pre-approve a submitter
 "Person-with-email-address-XXX@YYY has my permission
 to submit draft draft-WGNAME-DRAFTNAME-00"

b) The submitter can submit a draft
  "Here is draft-WGNAME-DRAFTNAME-00"

If (a) happens before (b), then the draft is noted
as being approved by the chair. If (b) happens and
(a) hasn't happened, then an email message gets sent
to the chairs asking that one of them approve.

Either (a) or (b) can happen by either email or
web site access.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 30 Aug 2004 19:23:34 -0700

One good reason for the chair not to submit the -00 draft
directly is that the document contains an IPR statement,
"by submitting this document, I assert...".

So the author(s) need to submit.

In fact, we might even want some kind of approval
for versions of the document where authors have
to ack their agreement to future versions.

Personally, I've had the situation where some co-author
has submitted a new version with my name on it that
I didn't like the changes at all! To the point where
I asked my name to be taken off.

Larry

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Aug 2004 22:45:35 -0600 (MDT)

On Mon, 30 Aug 2004, Larry Masinter wrote:

> One good reason for the chair not to submit the -00 draft directly 
> is that the document contains an IPR statement, "by submitting this 
> document, I assert...".

The current text seems to be even worse: "By submitting this 
Internet-Draft, each author represents ..."

> So the author(s) need to submit.

Yes, I realized this important reason after the debate with Henrik was 
over. I agree that this makes Chair-submission less attractive.

On the other hand, I have to note that the whole situation is rather 
messy:

 	- IPR statements imply that WG draft authors are responsible
 	  for content but IETF holds the copyright and can change
 	  authors (and/or content?) at any time.

 	- IETF process implies that WGs are responsible for content
 	  but only a few revisions receive formal WG consensus calls

Thus, a WG draft is a document that may have virtually nothing to do 
with WG consensus, listed authors, and their embedded IPR claims. Yet, 
we are being told that we need to enforce legal requirements for 
drafts. It smells like something is fundamentally broken here, but 
that something is outside of TOOLs scope.

> In fact, we might even want some kind of approval for versions of 
> the document where authors have to ack their agreement to future 
> versions.
>
> Personally, I've had the situation where some co-author has 
> submitted a new version with my name on it that I didn't like the 
> changes at all! To the point where I asked my name to be taken off.

Noted. With the current interface, I can make anybody an author 
without that person consent. And, according to the boilerplate emitted 
by xml2rfc-1.25, I can post IPR claims for that person!

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Aug 2004 22:51:32 -0600 (MDT)

Larry,

 	I believe your comments are in line with my recent "draft work 
authorization" suggestion, especially the "(a) happens before (b)" 
case.

 	The WG/Chair approve more than just the -00 submission. The WG 
approves dedicating certain resources to draft-related work, and that 
event should be recorded on its own, with one of the side-effects 
being automated draft submission approvals. See my "WG draft work 
authorization" e-mail for more details.

Thank you,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 31 Aug 2004 22:02:41 +0200

Hi Alex,

I definitely like the scheme below better than the chair-submits scheme,
but it's still a bit more work for the chair than the current state
of things.  However, I also agree with Larry's comment in another mail
about providing a way to handle both aprove-before-00-submission and
approve-after-00-submission.  Either of the methods you propose below
would work well for the approve-before-00-submission.

One thing to keep in mind with the scheme below is that it requires the
approved draft name to match the name actually used by the submitting
author.  (This may sound trivial, but experience has shown it to be
anything but...)  That could be handled either by the token issuing
variation, or simply by generating an informative mail (giving the
approved name) to the author as a result of the chair approval action.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 31 Aug 2004 22:10:55 +0200

Hi Larry,

> not require unnecessary serialization of multi-party

Very good point.  

> Either (a) or (b) can happen by either email or

Mmm, I'd been thinking only of an email mechanism for the b) before a)
case, but you're quite right, I think - Either (a) or (b) should be
possible by either email or web site access.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 31 Aug 2004 22:13:13 +0200

Hi Larry,

> So the author(s) need to submit.

I agree.

> to ack their agreement to future versions.

Don't know if this is needed .. might be .. ?

> I asked my name to be taken off.

At the same time, we don't want to require all authors to
sign off on each submission, I think.  Maybe this case should
be handled by manual intervention?

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 31 Aug 2004 22:21:25 +0200

Hi Alex,

> over. I agree that this makes Chair-submission less attractive.

Ok.

>  	  authors (and/or content?) at any time.

Mm, not quite - the IPR statement is about the authors' knowledge of
relevant IPR, rather than the draft content itself ...

>  	  but only a few revisions receive formal WG consensus calls

Nevertheless, discussions of a draft occur continuously on the lists.

> with WG consensus, listed authors, and their embedded IPR claims. 

I think this is an exaggeration...  If a draft has virtually nothing to
do with WG consensus, we have a pathological situation where many people
including the chairs have been blatantly not doing their job, I believe.

> Yet, 

Not sure I fully agree on the brokenness - by reason given in my comments
above...  But still, I think it's Ok for us to reflect on matters like
these, lest we make things more silly than they need to be :-)

> by xml2rfc-1.25, I can post IPR claims for that person!

Right.  So we maybe need to ask ourselves if we should actually solicit
approval from not only submitter and chair, but from all the authors on
WG -00 submission?

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 31 Aug 2004 14:23:10 -0600 (MDT)

Henrik,

 	I agree that the amount of work is going to be slightly more 
compared to today case of a minimalist Chair responding with a 
single-word "Approved!" e-mail. Perhaps that increase in work is 
natural. Is it possible that to achieve desired level of automation 
and cross-referencing, additional metadata is unavoidable and somebody 
has to type that metadata at least once?

 	We can try to design the interface so that the Chair only 
needs to type in the draft name and hit an "Approve" button, leaving 
other fields unfilled. The system would then let _any_ WG author to 
submit a matching 00 draft. Not as secure/robust as I would want, but 
technically possible. If we can agree that the Chair should also fill 
in authors/editors e-mails, then security/robustness would 
significantly increase. The authors and editors can be responsible for 
filling the rest of the metadata for the work.

 	Can I assume the "WG draft work authorization" scheme and 
adjust the ID submission draft accordingly?

 	If yes, would documenting "WG draft work authorization" 
details be in scope of that draft? I do not think so; it seems like a 
stand-alone interface (much simpler than the ID submission toolset).

Thanks,

Alex.

P.S. I understand the name synchronization issue. Personally, I would
      argue that submissions of yet-unauthorized drafts must be
      rejected, possibly with a pre-filled "please authorize"
      invitation sent to the Chairs. I seems wrong to me to create
      state for (and spend documentation/implementation energy on)
      something that has not been authorized by the WG. I think the
      concept of the WG necessarily authorizing WG work is a natural
      one.

On Tue, 31 Aug 2004, Henrik Levkowetz wrote:

> Hi Alex,
>
> I definitely like the scheme below better than the chair-submits 
> scheme, but it's still a bit more work for the chair than the 
> current state of things.  However, I also agree with Larry's comment 
> in another mail about providing a way to handle both 
> aprove-before-00-submission and approve-after-00-submission. 
> Either of the methods you propose below would work well for the 
> approve-before-00-submission.
>
> One thing to keep in mind with the scheme below is that it requires 
> the approved draft name to match the name actually used by the 
> submitting author.  (This may sound trivial, but experience has 
> shown it to be anything but...)  That could be handled either by the 
> token issuing variation, or simply by generating an informative mail 
> (giving the approved name) to the author as a result of the chair 
> approval action.
>
> 	Henrik
>
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 31 Aug 2004 22:46:52 +0200

Hi Alex,

> has to type that metadata at least once?

Probably true :-)

> filling the rest of the metadata for the work.

Agreed.  But note that this is for the pre-approval case.  I think
Larry's point of supporting both pre-approval and post-approval
is a good one.

> adjust the ID submission draft accordingly?

If I understand you correctly, I'm OK with this as one prong of
the fork - as said above.  It would be good to have some input
from Stas and Bill, too :-)

> stand-alone interface (much simpler than the ID submission toolset).

Don't you think it's part of the I-D submission toolset?  Even if
it could generate other data, the I-D sumbission toolset would be
incomplete without this, I think?

	Henrik

>       concept of the WG necessarily authorizing WG work is a natural

Oh, but in practice I've not come across authors submitting a -00
before the workgroup has OK'd it - but there's a wide variation on
the level of contact authors take with chairs when they've generated
the -00 and are ready to sumbit it.  Some just do it, some email 
the chair first, most cc the chairs on the submission mail to the
secretariat.

I'm sure that somewhere unacceptable, unauthorized -00s have been
sumbitted, but as long as our design doesn't break in this case,
we shouldn't spend too much work on it.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 31 Aug 2004 14:50:24 -0600 (MDT)

On Tue, 31 Aug 2004, Henrik Levkowetz wrote:

> So we maybe need to ask ourselves if we should actually solicit 
> approval from not only submitter and chair, but from all the authors 
> on WG -00 submission?

A consistent lawyer-friendly approach would be slightly worse (more 
complicated).

A person must consent to being an author of a draft. When consenting, 
the person can chose whether their consent is per-draft, 
per-draft-version, per-draft-boilerplate-version, etc. The system 
requests (or not) approvals from then-current authors to post a given 
submitted draft version according to the above preferences.

For WG drafts, a Chair can always delete authors, invite authors, but 
cannot force an author to sign up (because of IPR concerns). When an 
author is deleted or invited, she is notified. An author can always 
delete himself, with a note sent to other authors and the Chair.

For individual drafts, any current author (or, alternatively, the 
first author) has Chair-like powers.

Note that the above is a good illustration why "draft work" object is 
not identical to the "draft version" object. All posted draft versions 
have authors (possibly anonymous) but "draft work" might not have any 
authors sometimes.

I am not sure IETF is ready or needs such a formalism. Personally, I 
would prefer deleting all IPR claims from the drafts to avoid most of 
the above problems. But I am sure legal advice would be to keep claims 
explicit (lawyers, naturally, want to make sure they have work to do). 
If so, author consent would probably be required to enforce those 
claims and the above system seems necessary.

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 31 Aug 2004 15:11:26 -0600 (MDT)

On Tue, 31 Aug 2004, Henrik Levkowetz wrote:

> But note that this is for the pre-approval case.

Yes.

> I think Larry's point of supporting both pre-approval and 
> post-approval is a good one.

I disagree that post-approval needs to be supported, but note that 
supporting it would not be a technical problem and, with some coding, 
would even save Chair authors name typing (those can be collected from 
submissions pending Chair approval). I just do not think this mode is 
worth spending our and Secretariat resources (even though it is in use 
today); and I think it would take a lot more lines of code to support 
compared to the straightforward approve-then-submit mode.

> Don't you think it's part of the I-D submission toolset?  Even if it 
> could generate other data, the I-D sumbission toolset would be 

Yes, ID submission without Chair approval mechanism would not be 
functional for -00 versions of WG drafts, but I am not sure that's 
enough motivation to describe "author" management and "00 draft 
approval" in one ID submission draft. They seem to be sufficiently 
isolated interfaces. This is not a big deal though. Let's hear other 
opinions...

> the -00 and are ready to sumbit it.  Some just do it, some email the 
> chair first, most cc the chairs on the submission mail to the 
> secretariat.

Yes, but I think we may be benting over to support all current modes 
of operation instead of reasonably trimming what is allowed by a more 
formalized interface. The toolset does not have to support everything 
IETFers do today. It needs to support everything they need to do, with 
a few bells and whistles on top.

Imagine an interface that encourages the Chair to hit a button on a 
web site instead of manually writing a "we have consensus to 
start/adopt WG draft work..." e-mail. Once the Chair hits that button, 
an e-mail is sent to the WG mailing list and WG draft work is marked 
as approved. Authors are invited. A searchable public record (event, 
tasks) is created and linked.

If a WG participant acts before the consensus call, he is politely 
reminded to wait for the consensus call/authorization first. I see no 
harm in that.

Can we have submission-before-approval as a MAY-level feature until we 
get more feedback? :-)

Thanks,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 31 Aug 2004 23:28:03 +0200

Hi Alex,

...
> compared to the straightforward approve-then-submit mode.

There seems to be a wide discrepancy between your perception here and
mine - to me, the submit-then-approve case is simply a case of re-using
the code needed to verify the submitter being in control of the
alleged submitter email address.  *Very* straightforward.  And I'm
also slightly surprised ,:-) because it was you who pointed out 
the advantages of re-using our authorization tools...

Anyway...

...

> Can we have submission-before-approval as a MAY-level feature until we 

Sure, as a placeholder.  We clearly don't have consensus yet ;-) 

Bill, Stas, input please?

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 31 Aug 2004 15:40:59 -0600 (MDT)

On Tue, 31 Aug 2004, Henrik Levkowetz wrote:

> There seems to be a wide discrepancy between your perception here 
> and mine - to me, the submit-then-approve case is simply a case of 
> re-using the code needed to verify the submitter being in control of 
> the alleged submitter email address.  *Very* straightforward.

The complexity is not in authenticating the submitter, but in 
maintaining state between authenticated submission and authenticated 
approval. That extra pending-submission state is absent in the 
approve-then-submit case.

Key approve-then-submit objects are: approval, posted submission. Key 
submit-then-approve objects are: pending submission, approval, posted 
submission. A 50% increase of work, just by a simple object count.

But we already argued about a similar trade-off, without success...

> And I'm also slightly surprised ,:-) because it was you who pointed 
> out the advantages of re-using our authorization tools...

The code necessary to manage the extra pending-approval state would be 
specific to the submit-then-approve case. It would not be reused as 
far as I can see. Only actor authentication code can be reused in this 
context.

Alex.

---

From: Allison Mankin <[email-masked]>
Date: Tue, 31 Aug 2004 15:18:23 -0700

Hi, everyone,

I'm reading the mailing list carefully now that I'm back from my 
way-too-disconnected vacation, and liking the discussion.

But I want to point out a few things.  They're mostly related to
the last day of messages.

- Remember IETF has decided things such as the requirement for 
  the IPR statement on the drafts, so the Tools team/tool interface
  isn't in the position to re-think that consensus.

- The IETF also has pretty formally decided that it cannot retain
  old drafts, and so a tool can't change the actual repository policy
  without getting into modifying the standards process.  But I do
  think a cvs-like and diff-supporting tool could be cool and
  important.  

- Some things IETF hasn't formally decided, but a Tool framework
  might formalize by accident:  "membership" registration is an
  example.  Currently even chairs don't have to be consistent in what
  email address they use for the very weak email-address authentication
  we use for them.   To the extent that we introduce authentication
  and identity, they will be a significant change in the IETF,
  where the only membership required is joining any mailing list.  There've
  been earlier parts of the thread that have talked about the several
  authors verifying submission, and things like that.  I think the farthest
  this team could go on identity in the IETF as it exists now is to 
  authenticate chairs and editors (they are* covered by ISOC's liability
  insurance).  That's all you are talking about in the recent notes, but
  just to be aware, because the same tool is for all the i-ds,
  and more than half are non-working-group.

- I don't know if this has come up during phone calls:  
  There's a requirement for a fairly simple i-d submission tool to
  offload mail-based submission as early as possible because of the
  increasing loss patterns due to anti-spam tools interacting with 
  varied types of submissions.  The detection of lost submissions has
  not been perfect or always timely, and several working groups have
  been quite badly affected by these problems.

  So if there are some harder to settle parts of the requirements,
  if it's possible to put them in a second phase, that might be
  desireable.

Allison

P.S. about post-approval:  some working groups have been editor-driven
     or laissez faire so that the 00 is submitted and the working group
     and chair have not been well aware.  It used to be more common; 
     there were problem working group chairs in CCAMP to give you one
     example where you can see a huge number of i-ds due to this
     phenomenon.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 31 Aug 2004 15:23:03 -0700

I think we should rank requirements by their importance
and utility, and not argue too much about implementation
difficulty, as long as we believe implementation is
feasible.

I don't think we can judge implementation difficulty without
more information about what's available in the implementation
environment.  In most workflow software, multi-state approval
cycles are the norm.

Larry

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 31 Aug 2004 16:38:33 -0600 (MDT)

On Tue, 31 Aug 2004, Larry Masinter wrote:

> I think we should rank requirements by their importance and utility,

On a "toolset MUST/SHOULD/MAY support" scale, IMO, the rank of the 
accept-draft-submissions-before-work-approval mode is a MAY. The rank 
of the approve-work-then-accept-submissions mode is a MUST.

What ranks would you assign?

Thanks,

Alex.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 31 Aug 2004 16:22:23 -0700

> What ranks would you assign?

Between 
  accept-draft-submission-before-work-approval
and
  approve-work-then-accept-submission

the tool MUST support one or the other of these,
consistently. It MAY support both. It MAY support
more complex modes of interaction, e.g., a WG
chair asking to review the submission itself
before approving it. 

It SHOULD have enforcable mechanisms for verification
of email address, and the draft syntax validation SHOULD
check to make sure the email address of the submitter
is listed in the draft itself.

Larry