Subject: Re: [Tools-discuss] Fw: I-D submission tool draft

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 14 Sep 2004 11:52:09 +0200

Hi Jari,

	Thanks for the feedback!  Some notes inline...

Jari Arkko wrote:

> 
> I like automation. I think it would be great if the
> tools handled nits checking, file posting, IPR/copyright
> confirmation and all that, probably getting the draft
> to the web site in minutes. Compare this to the delay
> we have now, which is days -- not bad compared to past
> times but it would still speed up the process, let the
> secretariat do other, more useful things. And it would
> probably increase quality too, less accidents and more
> formal checking during submission.
> 
> I think the tools should read things like author information
> from the draft. People would hate typing all that in again.
> But it may be fine for the tool to ask if the information
> it has read is correct, as a confirmation. Or get a
> confirmation that the user has read "Note well".

Agreed, on both counts.

> As for the chair approval part: when we automate processes,
> we do not have to follow the current manual process, we
> can do things in a different way if it makes sense. Just because
> we can require a chair to sign off in the tool does not
> mean that we should. In fact, in order to make things go
> smoothly, I would propose that an optimistic security
> mechanism be adopted as opposed to a prior or real-time
> approval: give the chairs a function to remove a WG draft
> if someone has fraudulently/erroneously submitted one.

!! That's an interesting idea, which we've not discussed in
the team.  I like it :-)

> A couple of detailed comments to the draft below:
> 
> - I don't think we want the cut & paste option. Upload
>   is sufficient.

Noted

> - I'm not sure the correct metadata & go to manual process
>   option is useful. Is there some reason why we can't require
>   either that (a) the draft be corrected so that the metadata
>   can actually be read, or that (b) the user fills in the
>   metadata and then we do the automatic publish operation
>   anyway?

After Scott's comments, I think that I favour (a) - that seems
to not lead into ratholes, and it's simple

>   I'd like to keep the e-mail based submission process
>   as a backup, but I see no reason to add a new manual
>   mode to the tool.

Noted

> - "two versions are submitted with a suspiciously small gap?"
>   I think this is a non-problem. Fortunately, some people
>   may read your draft immediately, and notice a problem that
>   you want to correct. Or, unfortunately, you yourself notice
>   something that went wrong. I think we need to allow new versions
>   even with a short time gap.

Ok

> - I'd rather see the tool as one "submit page" rather than
>   a separate "upload" and "check pages". You submit and then
>   you get back the information that you want to verify, and
>   then you either press OK or resubmit/correct.

Ok.  Would you suggest that the IPR/copyright confirmation be
on a 3rd page, or combined with the verify page?

> - Security considerations and submitter authentication.
>   Perhaps we should think about e-mail address verification,
>   just to confirm that the web user is actually able to
>   receive e-mail at the address he claims to have.

Yes, I think that is right.  

>   The other question is if we should allow anyone to
>   submit. For new drafts, the answer is yes, I think.
>   For old drafts, I would propose that any of the
>   authors of the old revision can post a new one.

This has been the intention, yes.

>   Then we have many cases of the-old-authors-are-no-longer-
>   interested-and-someone-else-took-over; those can be
>   handled by the manual e-mail based approach just fine.

Right.

	Henrik

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Sep 2004 13:01:56 +0300

> on a 3rd page, or combined with the verify page?

Either way is fine with me, but perhaps one verified issue
per page would be more readable. First page: verify that the
metadata is right. Second page: ack that you have comply with
the copyright etc rules.

--Jari

---

From: [email-masked] (scott bradner)
Date: Tue, 14 Sep 2004 12:56:40 -0400 (EDT)

> > give the chairs a function to remove a WG draft

this process has caused significant issues in teh past

people can get quite burnt if they get a very public rebuke by having
their ID removed - I do not think this is a good idea (plus the fact
is that IDs never get removed from teh net - that ID will be there about
forever with the wrong name)

I think this is quite a bad idea

Scott

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 14 Sep 2004 21:14:55 +0200

> forever with the wrong name)

The 'rebuked' feeling is one clear downside.

The fact that a lot of places are rsyncing against the archive
at all times is something I didn't think of in my first reaction.
That means that it is essentially impossible to completely remove
a draft once it has hit the archive.

To me, this makes the idea very much less attractive.

	Henrik

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Sep 2004 14:27:48 +0300

> forever with the wrong name)

Ok -- given that the IDs can get distributed very widely it is
perhaps best to ensure that the I-Ds have authorization first
before assigning them a WG-based name. And I was surprised by
the amount of people who have had experiences with non-approved
WG document submissions! However, I'm still hoping that
the authorization process can be made as smooth as possible.
Perhaps you can allow both prior authorizations as well as
enabling a chair to allow a pending I-D submission. (Or maybe
the manual secretariat process can handle the latter case?
This could handle also the AD-approvals when both chairs are
unavailable.)

--Jari