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

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 14 Sep 2004 04:51:13 +0200

Forwarding this to the tools-discuss list, too.  /Henrik

-------- Begin forwarded message: --------

Date: Mon, 13 Sep 2004 19:05:50 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: scott bradner <[email-masked]>, [email-masked], [email-masked]
Cc: 
Subject: re: I-D submission tool draft

On Monday, September 13, 2004 08:38:45 -0400 scott bradner 
<[email-masked]> wrote:

> I will say that I'm not fond of the idea of requiring that WG chairs
> pre-approve the submission of -00 WG IDs, as a WG chair I'd rather be
> able to enforce me getting a chance to review the document first - I'm
> fine with letting a WG chair be able to pre approve but I do not think
> it should be the only way that the process should be able to work

I agree.  While both submission of the document and approval by the chair 
are necessary, there's no reason to require a particular order.  If I'm not 
available to approve a new document (say, because I'm on a train returning 
from an IETF meeting), the system should wait until I can deal.  It should 
_not_ force the submitter to wait -- computers are much better at waiting 
than people are.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

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

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 14 Sep 2004 09:14:30 +0200

[re-adding tools-discuss]

--On tirsdag, september 14, 2004 08:56:00 +0300 [email-masked] 
wrote:

> Pekka,
>
>> > I agree.  While both submission of the document and approval by the
>> > chair  are necessary, there's no reason to require a particular order.
>> > If I'm not  available to approve a new document (say, because I'm on a
>> > train returning  from an IETF meeting), the system should wait until I
>> > can deal.  It should  _not_ force the submitter to wait -- computers
>> > are much better at waiting  than people are.
>>
>> I don't see forcing the submitter to wait a problem at all.  It just
>> changes the practical process a little bit, that's all.
>
> My biggest concern about this is co-ordinating this around IETF meetings.
> For example, I usually take vacations from mid-June to mid-July so
> sometimes I am on vacation during the draft cut-off dates.  Trying to get
> everything co-ordinated sufficiently would probably cause something to
> get missed, which sort of defeats the purpose of scheduling IETF meetings
> to discuss active work items.

John, I think you clearly point out that if something (like approval of an 
-00 draft) is likely to be hung up on a single person, there needs to be 
override procedures in place - that the WG chair can sublet the power to 
the WG secretary, that the AD can approve when the WG chair isn't there; 
the details can be worked out - but we should NOT let ourselves be locked 
down to one specific person having to be chained to his keyboard.

                         Harald

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 14 Sep 2004 11:33:12 +0200

I share Magnus concerns about an implicit approval process for
new WG drafts, and I do not think it is a big issue for us
chairs to approve new WG drafts. It is a matter of 
communication between author(s) and chair(s), and if we can
have a pre-approval mechanism this should not at all be an
issue.

/L-E

> I am not agreeing with you on the implicit approval process. 
> At least in my WG (AVT) it is quite common that people are
> somewhat confused on the process and do not sufficiently
> understand the distinction between WG documents and
> individual submission. In addition we are allowed by the 
> AD as WG chairs to make the decision to approve RTP payload 
> formats as WG items. Thus I like to have the necessary
> control that no drafts gets available as WG items before our
> explicit approval.
> 
> If there is also a process where the WG chair can pre-approve
> WG drafts, it can work smoothly even before meetings or when
> the chair is on vacation. It then becomes a matter of the
> author to communicate with the WG chair if it really
> necessary to get it out ASAP. I hope such an interface would
> use a cut-off deadline based the submission, rather then the
> WG chairs approval. Although the chair should also have an
> deadline.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Sep 2004 12:59:51 +0300 (EEST)

A few comments of my own...

On Tue, 14 Sep 2004, Jari Arkko (JO/LMF) wrote:
> 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.

I might want to consider keeping at least some kind of sign-off.  
I've seen about two cases where people I had never even heard of had
submitted draft-ietf-v6ops-xxx documents, and they had gone through
(to WG charter pages etc) even without asking WG chairs (for some odd
reason).  They were just IETF newcomers, and thought that was the way
to name their first individual submission, so they sent that to the
internet-drafts@...

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

Agree.

> - 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?

I don't even see (b) as strictly required.  The users won't care to 
fix their stuff if they can just opt to ignore the form requirements.  

To me, we only need an on/off behaviour: if the ID passes the checks,
it's published.  If it doesn't pass, the system shows why not, and
it's immediately deleted from the staging area.  The user makes
appropriate changes to accommodate the required fixes, and submits
again, [iterate as needed].  Simple and efficient.

Of course, a manual "backup" will be needed, but it could be delayed 
e.g., 3-4 days on purpose to make using automation more lucrative.. 
:-)

For what it's worth, I don't see why we even need a web tool.  Why not
just send the draft over email?  You can do the same kind of
challenge-response with that as well if needed.  I can deal with http,
but email seems reasonably simple approach at least for the more
experienced..

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

I think we could have a check that only two versions of the same ID
can be posted in the same day.  That allows for first submittal, and
immediately fixing some typos or brown paper bag issues.

The concern here is probably when some stupid script goes awry and 
creates an infinite loop of submission .. :-)

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

Agree, as said above.  This could be greatly simplified.
 
> - 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.

That's possible, see more comments below on who could submit drafts.

....

8.2  Extraction
   WG: IETF working group identifier.  WG value is empty for individual
      drafts or non-IETF drafts.  For example, "tools" in
      draft-ietf-tools-draft-submission-13.

.. currently, there is no reliable way to get this information,
because some WGs have adopted to tell the secretariat that a draft of
the name like draft-surname-wg-foo-05.txt is actually a WG document
(that's a variable in the IETF systems) instead of properly renaming
them.  See e.g., OSPF WG for these.   So this information cannot be 
extracted from the drafts without a policy change (I'd encourage such 
a change though!)

==> I'd also like to point out something that's not always done but
could be useful for history keeping.  When a -00 draft is published,
it's sometimes signified to the secretariat that it obsoletes the
previous draft (which is then moved to the expired pile).  That would
also facilitate keeping track of those changes..

I don't think xml2rfc for example can be used to convey this
information, but if we move towards more automation, this could be
useful..

....

8.3.1  Absolute requirements
   2.  A draft must be submitted by an authorized submitter.  [[XXX13:
       move this lower, we do not know the submitter at this stage
       --Alex]][[XXX14: Don't forget the co-author, changed editor, and
       drafts being posted anonymously (secretariat needs to know who
       submitter is, but name doesn't necessarily appear on draft)
       --Harald]]

and:

      Which author is the submitter? [[XXX30: with the exception for
      Secretariat manual submission? No.  Secretariat submits on behalf
      of one of the authors.  --Alex]][[XXX31: are there any situations
      when a draft is submitted by somebody other than author and not on
      explicit authors behalf? What happens to IPR "by submitting this
      draft I ..." statement then? --Alex]];

==> there are many cases where non-author is submitting a new version, 
e.g., when WG chair or someone designated by the WG chair steps up and 
does final editing rounds of the document.  I've certainly done that 
dozens of times myself.

   4.  Current draft state must allow new revisions to be posted.
       [[XXX15: 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 --Alex]].

Both Harald and secretariat are incorrect at least in practice.  New 
ID's can be submitted at any point in time right now.  The above 
categories wouldn't even work if the IESG evaluation changes the state 
of the draft to "revised ID needed" substate (can happen at any 
stage).

But my point here is that it seems wrong to restrict this in any way
prior to the draft getting into "RFC editor's queue" phase.  This is 
because the ADs and the secretariat are in charge of changing the 
state -- they could be days or weeks absent (not being able to change 
the state to such one where new revisions would be OK), disallowing 
one from addressing issues.

This seems like trying to solve a process knowledge problem (the I-D
author should not submit new versions) using a technical means, which 
seems shortsighted.

At most, a warning should be issued.

....

8.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).
   [[XXX18: should we be that strict with last revisions? --Alex]]

and:

      Does the author request this submission to be published? (i.e.,
      forwarded to IESG or RFC Editor for review and publication as an
      RFC or BCP) [[XXX32: clarify that for-publication submissions may
      be subjected to more mandatory checks than other drafts.
      --Alex]].

==> I don't understand this.  How would the tool know that a draft is 
intended for "publication requested" state.  There is no way to know 
that, so this seems out of scope here.

   [[XXX2: should the posting program obtain all authors consent?
   --Alex]]

==> definitely not, there are past authors who are no longer active, 
of whom we'd never get an ack or nack.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked]
Date: Tue, 14 Sep 2004 13:16:43 +0300

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Henrik Levkowetz
> Sent: 14.September.2004 12:52
> To: [email-masked]
> Cc: [email-masked]; Jari Arkko
> Subject: Re: [Tools-discuss] Fw: I-D submission tool draft
> 
> 
> 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.
> 
> !! That's an interesting idea, which we've not discussed in
> the team.  I like it :-)
> 

This is ok until the same draft is resubmitted a few months later with changes, but using the same name (since the first one was not approved, the name is not reserved). This results in 2 drafts with the same version number and different contents that the public has had access to. A draft should be approved before made public.

Regards,
Hisham

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 14 Sep 2004 11:03:58 -0600 (MDT)

scott bradner wrote:

> pre-approve the submission of -00 WG IDs, as a WG chair I'd rather 
> be able to enforce me getting a chance to review the document first

Can you clarify the point of reviewing the document first, keeping in 
mind that the Chair has no special control over the second and all 
other revisions of the draft? If I have a malicious intent, I will 
post a "placeholder" or "good" version first, get it approved, and 
then immediately post a "bad" version. If I have no malicious intent, 
I will correct any problems in the first version during subsequent 
postings.

IMO (not shared by some TOOLS members), holding the 00 version hostage 
to Chair approval complicates the tool considerably. I still do not 
see much value in doing that. What value does the Chair review of the 
00 version of the draft bring compared to simply authorizing draft 
_work_?

I would have no problems understanding the argument for 
post-then-approve model if Chairs had to approve every posting, not 
just the 00 version. With current rules, it really seems to me that 
the Chair (WG, really) approves draft _work_ not any specific draft 
version, until the last call.

I also cannot say whether discussion on this list indicates that there 
is consensus one way or another. And with folks suggesting no 
approvals at all (i.e., optimistic security model), things become 
really blurry...

Thank you,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Sep 2004 07:43:07 +0200

Forwarding this to the tools-discuss list.  /henrik

-------- Begin forwarded message: --------

Date: Tue, 14 Sep 2004 13:50:47 -0700 (PDT)
From: Bill Manning <[email-masked]>
To: [email-masked] (scott bradner)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D submission tool draft

% 
% Bill says:
%         actually, i think that the WG chairs are the -wrong- people
%         to ensure that the right text is part of each -00 IDs. you
%         really want proper legal review of each -00 id to ensure that
%         the copyright text is correct/intact.
% 
% I do not recall saying anything about the WG chairs doing this

	Hum....  this follows from the last para of your email, excerpted
	below, where you intimate that an idea for "making" this work is
	to require WG chairs to pre-approve the submission of -00 WG IDs.

Scott

% 
% the reason the WG chairs are in the loop today (and tomorrow) is to
% ensure that the WG thinks the document should be a WG document, it
% has nothing to do with WG chairs checking boilerplate

	yes, nessasary but not sufficent.  Most WG chairs are not
	licensed legal advisors.

% 
% Scott
% 

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Sep 2004 07:44:52 +0200

Forwarding to tools-discuss...  /Henrik

-------- Begin forwarded message: --------

Date: Tue, 14 Sep 2004 05:21:59 -0400 (EDT)
From: [email-masked] (scott bradner)
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: I-D submission tool draft

Bill says:
        actually, i think that the WG chairs are the -wrong- people
        to ensure that the right text is part of each -00 IDs. you
        really want proper legal review of each -00 id to ensure that
        the copyright text is correct/intact.

I do not recall saying anything about the WG chairs doing this

the reason the WG chairs are in the loop today (and tomorrow) is to
ensure that the WG thinks the document should be a WG document, it
has nothing to do with WG chairs checking boilerplate

Scott

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Sep 2004 07:46:03 +0200

-------- Begin forwarded message: --------

Date: Tue, 14 Sep 2004 09:28:05 +0100
From: Gorry Fairhurst <[email-masked]>
To: "Jari Arkko (JO/LMF)" <[email-masked]>, [email-masked]
Subject: Re: I-D submission tool draft

IMHO, The way people cite ID's (which we know they should not) leads to 
a conclusion that SOMEONE MUST check new WG submissions BEFORE they are 
allocated an draft-ietf-xxx- filename... That way, we prevent people 
archiving none-drafts.

I'd be keen to see WG (Chair) approval of EACH WG draft, afterall
authors in the proposed scheme can immediately publish
a revised individual submission identical to the WG proposal
--- This would also give Chairs time to check the details *AND* Author 
list. This may be a good time to check all Authors are ACTUALLY going to 
engage in developing this as a WG document and in the review, etc.

Gorry

Jari Arkko (JO/LMF) wrote:

<snip>

> if someone has fraudulently/erroneously submitted one.

<snip>

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Sep 2004 07:48:41 +0200

Forwarding to tools-discuss list...  /Henrik

-------- Begin forwarded message: --------

Date: Tue, 14 Sep 2004 07:46:38 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked]
Subject: re: I-D submission tool draft

I stripped off [email-masked]...

> > it should be the only way that the process should be able to work

I'm not sure if I see this problem.  The process in practice could be
that the WG chairs ask the authors to send the document to them, they
will review it [and iterate as needed, and when done], send in the
pre-approval and the the document at the same time.

There's no actual requirement that the authors themselves send in the
-00 documents.  There aren't that many per WG to make it too big a
trouble for WG chairs..

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Sep 2004 07:49:28 +0200

-------- Begin forwarded message: --------

Date: Tue, 14 Sep 2004 08:56:00 +0300
From: [email-masked]
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D submission tool draft

Pekka,

My biggest concern about this is co-ordinating this around IETF meetings.
For example, I usually take vacations from mid-June to mid-July so sometimes I am
on vacation during the draft cut-off dates.  Trying to get everything
co-ordinated sufficiently would probably cause something to get missed,
which sort of defeats the purpose of scheduling IETF meetings to discuss
active work items.  

John

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Sep 2004 07:50:12 +0200

-------- Begin forwarded message: --------

Date: Tue, 14 Sep 2004 09:44:39 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: I-D submission tool draft

> which sort of defeats the purpose of scheduling IETF meetings to discuss

Don't take vacations then.  That's why being a WG chair gives you the
big bucks ;-).

But seriously, unless WG chairs/secretaries coordinate, having long
vacations prior to the meetings is a recipe for disaster.  Maybe this
calls for a slightly different meeting times, or just sacrifices wrt.  
vacations from the chairs and WG participants..

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Sep 2004 07:50:54 +0200

-------- Begin forwarded message: --------

Date: Tue, 14 Sep 2004 10:00:41 +0300
From: [email-masked]
To: <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D submission tool draft

Pekka,

> vacations from the chairs and WG participants..

Well, I generally push back on new processes or procedures unless there
is clearly reasons for the processes.  What is the problem that the new
process is trying to solve & is the burden of the new process significantly
less than the burden which the problem is currently causing - these are
always my first questions.	

The current draft says:

   .... No malicious
   impersonations or fake approvals have been reported to date however.

   Lack of authentication is not perceived as a serious problem,
   possibly because serious falsification are likely to be noticed
   before serious damage can be done.  Due to informal and manual nature
   of the submission mechanism, its massive automated abuse is unlikely
   to cause anything but a short denial of draft posting service and,
   hence, is probably not worth defending against.  However, future
   automation may result in a different trade off.

Which indicates to me that there is not a current problem, so at present
we don't need to burder WG chairs with more processes.  Interupting my
vacation does represent a burden to me.  Addionally, there is the possiblity
of disruption if WG drafts are not approved in time to make meeting
draft cut-offs.  This could impact upon the timely-ness of a WG to meet
its charter, if a draft misses one meeting cycle.

John

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Sep 2004 07:51:46 +0200