Subject: [Tools-discuss] Re: I-D ACTION:draft-ietf-tools-draft-submission-08.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Apr 2005 16:46:56 +0200

Hi,

I'm sorry to come late in the process with a bunch of comments.
I apologise if some of them have been debated and rejected already;
just let me know. And let me know in general what you think of my
points, so that I can decide whether to put the -08 version in
front of the IESG, or ask for -09.

First, a couple of general points that I scribbled on the front page:

XML submission is in stage "b". I'm concerned about that because I really
think that we have a large majority of authors who are using XML already.
A related point is that I would always give metadata extraction from XML
priority, because it is unambiguous and non-heuristic.

I don't think I saw any mention of 1id-guidelines. The intent is to
be consistent with that, I think.

Now some specifics:

> 8.4  Extraction
...
>    version: A non-negative integer number representing draft version
>       number (also known as draft revision number).  For example, the
>       number seven in draft-ietf-sieve-vacation-07.

To be picky, you need to specify that it's two digits including a
possible leading zero, and you need to specify whether values >99
are allowed. (On DOS grounds, I'd say not.)

> 8.5.1  Absolute requirements
...
>    5.  The creation of the draft version could have happened 48 hours or
>        less before submission time.

I don't understand that sentence. Do you mean that creation MUST NOT
be older than 48 hours before submission, and if so why do you care?
I can well imagine preparing a draft several days before submission.
Technically, as an IBM employee, I am obliged to get external publication
clearance for the text, which could take a week or two.

>    6.  The draft version expiration date obeys IETF draft expiration
>        rules.

1id-guidelines isn't precise about date formats. Posting with only
the month names for both publication date and expiration date has long
been tolerated. (The draft is physically expired 185 days after the
date of posting, but we have never required precision in the
text.)

> 8.5.2  Desirable features
> 
>    Violating any of the following requirements does not prevent the
>    submitter from auto-posting the draft (R24/a).

Does that mean the user gets a warning via the Check page prior
to deciding to auto-post?

>    3.  If both XML and plain text formats are submitted, the submitted
>        plain text matches what can be generated based on submitted XML
>        (R146/b).

I couldn't find it stated anywhere whether submitting *only*
XML is allowed. (Opinion: I think it should be.)

> 8.5.3  DoS thresholds
...

> 
>    +----------------------------------------+--------------+-----------+
>    | category                               | versions/day |    MB/day |
>    +----------------------------------------+--------------+-----------+
>    | drafts with the same draft name        |            3 |         5 |
...............................................seems high
>    | drafts with the same submitter         |            5 |        10 |
>    | WGN drafts with the same WG ID         |           10 |        15 |
...............................................these seem low
>    | all drafts                             |          300 |       150 |
>    +----------------------------------------+--------------+-----------+

As noted above, you might consider version # >99 as a DOS threshold too.

> 8.5.4  WG approval
...
>    If (a) no approval exists, (b) the Toolset supports the "waiting for
>    WG approval" feature, and (c) the draft can be posted if WG approval
>    is received, then the Toolset explains the situation to the submitter
>    and asks whether the submitter wishes to solicit an explicit approval
>    from the WG (R126/b).  If the submitter decides to go ahead with
>    solicitation, the Toolset puts the submission into a "waiting for WG
>    approval" state until the approval is available (R127/b).  Otherwise,
>    the Toolset records a "no WG approval is expected" error (R138/b).

Doesn't the tool automatically generate email to the WG chairs asking for
approval? That would be much more error-proof than waiting for the
user to compose email. And surely the final error message should be
"user declined to request WG approval"?

> 9.1  External meta-data
...
>       For any draft, an IESG member (R122/c).

This raised a red flag. In 1id-guidelines there is a third class of
draft names:

 >> Other
 >>     A string identifying an IETF-related body, such as "iab", "iesg", "rfc-editor".

(and one "other" case that is missed here is draft-irtf-).

Firstly, it isn't just any IESG member that needs the privilege -
at least the IAB Exec Director and the RFC Editor will need it, for
those special strings.

Secondly, the current practice of IRTF drafts being treated as individual
submissions is quite likely to change. In the extreme case, *everything*
that applies to draft-ietf-WGN would apply by analogy to draft-irtf-RGN.
I'm not saying that *will* happen, but it *might* happen. So flexibility
in the tool design is needed there.

> 16.  Email interface
> 
>    The Toolset should have an email interface for automated posting of
>    valid drafts (R55/b).  

Personal opinion: this should be R55/c. It's *way* behind XML submission,
in any case.

    Brian

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

---

From: "Alex Rousskov" <[email-masked]>
Date: Tue, 26 Apr 2005 10:52:31 -0600

> think that we have a large majority of authors who are using XML already.

And yet, XML has no official status in IETF. It seems prudent to start with
plain text, a format that is (and will be) officially required and then
expand into modern formats. Note that XML users can still submit their
generated plain text formats; we are not excluding them in the first stage.

The intent was to produce the simplest version that automates at least 80%
of submissions before moving into improvements. I suspect first stage  
feedback
will demand new features that may be more important than XML support.

As an alternative, we could support only XML-based submissions in stage A,
but I doubt it is a good idea because it will upset more people and will
delay first stage implementation.

> priority, because it is unambiguous and non-heuristic.

There is no "priority" concept because if the metadata from varios formats
does not match, the draft cannot be autoposted. In that case, the
implementors may choose to use XML-extracted metadata for manual posting.
Should we add that as a hint or requirement?

> be consistent with that, I think.

I agree. Specific requirements match some of the suggestions in
1id-guidelines. Did we miss any important ones? Adding an informative
reference to http://www.ietf.org/ietf/1id-guidelines.txt is a good
idea.

> possible leading zero,

Leading zeros is a rendering aspect, not a part of the version number
definition (one does not do math with leading zeros). We have a vague
rule R22 that requires draft IDs to be "correct". We can add an explicit
version rendering requirement there.

> and you need to specify whether values >99

We can add that rule if draft file name format (two digits for version)
is more important than supporting large number of draft revisions. There
are already so many things dependent on draft filenames that enforcing
a broken design may be better than slightly improving it :-(.

> clearance for the text, which could take a week or two.

This requirement needs to be reworded and it probably needs a formal Rnnn
marker. You guessed the intent correctly. The Toolset should care because
the Toolset cannot alter draft text, extracts draft creation date from the
text, and all extracted dates must match reality and IETF rules.

If you use XML source and do not specify the exact date there, then in
many cases, a two week clearance delay will not matter. In other cases,
you will need to edit the XML source or regenerate the plain text format
before submitting a draft that was created two weeks ago.

We can relax this requirement by stating that draft creation date can
be anything in the past. This is likely to upset Secretariat (because
their tools do not work that way) and will require an additional rule
saying that already-expired drafts cannot be autoposted. Also, it would
make claims "My draft has been posted for 2 months already!" impossible
to verify by reading the posted draft text. The latter makes me think
that it would be wrong to allow such flexibility.

> date of posting, but we have never required precision in the

I do not see a contradiction or problem here. The Toolset can/should
accept dates "with only the month names" if those are valid from IETF
point of view.

> to deciding to auto-post?

Yes. We should add a sentence to clarify this.

> XML is allowed. (Opinion: I think it should be.)

It is allowed by R69/b:

    It is an error to submit a draft which has neither plain text nor XML
    sources format (R68/a).  XML source is acceptable without
    accompanying plain text only if the Toolset successfully generates a
    draft in plain text format from the XML source, as a part of the
    processing step documented below (R69/b).

> ...............................................seems high

Two would be an absolute minimum to allow for quick bug fixes. Since we are
talking about detecting DoS attacks, 3 versions/day does not sound like
a DoS to me.

> ...............................................these seem low

I would be happy to raise these. 10 and 30?

> As noted above, you might consider version # >99 as a DOS threshold too.

Submitting a single version (#100) is not a DoS (by definition), IMO.
Please see above for >99 rule comments.

> user to compose email.

We decided to leave that feature outside of this draft. I do agree that
automating this process would be desirable, but there are many
requirements related to approval handling, and we agreed (after a long
debate) that documenting all those requirements in this draft would be
a mistake.

I still think that was the right decision. There should be a separate
comprehensive draft documenting how approvals can be automated instead
of including one or two isolated requirements in the submission draft.

> And surely the final error message should be

Unless the user has actually requested WG approval and it was denied.
The curret wording is more precise (less assuming), I think, but I am
happy to change that to whatever. The exact error message content is
not meant to be normative anyway (I just did not want to introduce
"error identifiers" of some sort and used quoted text for that).

> in the tool design is needed there.

I think there are two separate issues here. The first issue is increasing
the list of special people that Toolset recognizes. Because of the "for
those special strings" complexity, I would suggest that we leave the
current list "as is" for now.

The second issue is treating "draft-X", where X is "iab", "iesg",
"rfc-editor" (with a dash, yuck!), or "irtf" in a special way. It seems to
me that, for now, those drafts should not be allowed for autoposting.
Would that be acceptable?

> Personal opinion: this should be R55/c. It's *way* behind XML submission,

Personally, I agreee. Unfortunately for us, too many folks wanted to email
drafts so much that we included this in stage b. Personally, I would be
happy to change that to /c if that is what IESG wants us to do.

I will wait for yours and other Tools members feedback before changing
anything.

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 27 Apr 2005 08:39:07 +0200

> On Tue, 2005/04/26 (MDT), <[email-masked]> wrote:

[snip a lot of stuff which seems to be sorted out]

> of including one or two isolated requirements in the submission draft.

Here I think we need a wording change (which I thought we'd already 
made :-( ).  As the text now reads, it is most easily understood as if
the submitter is required to manually and personally solicit an approval
from the WG Chair.  Even if we don't cover the requirements on automation,
of this, we should not state or assume that this should be a manual
process left up to the individual; but rather make it clear that there
will be an automatic solicitation if requested, but the requirements of
that is outside the scope of this draft.

[...]

> Would that be acceptable?

That is also a special treatment.  If we want to have no special treatment
for those, it implies that they are handled like personal submissions.

If we want to have special treatment for them, why not handle them as WG
drafts?  Seems like a more fruitful special treatment than to specifically
disallow them.  Then you'd have a list of people who could approve posting
of -00 versions of such drafts (the 'WG Chairs', from the tools viewpoint).

> happy to change that to /c if that is what IESG wants us to do.

I'd support moving this to /c, or alternatively (maybe a better alternative)
creating a new stage between the current /a  and /b, in which we'd place
the XML submission requirements.

> I will wait for yours and other Tools members feedback before changing

	Henrik

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 27 Apr 2005 09:47:20 -0600

On Wed, 2005/04/27 (MDT), <[email-masked]> wrote:

> As the text now reads, it is most easily understood as if

I would be happy to specify that we expect this process to be
automated. Sorry if I was supposed to do that change earlier.

>> "rfc-editor" (with a dash, yuck!), or "irtf" in a special way. It seems  
>> to me that, for now, those drafts should not be allowed for autoposting.
> That is also a special treatment.  If we want to have no special  
> treatment for those, it implies that they are handled like personal
> submissions.

Yes, it is special treatment which seems to be required to prevent
random folks from posting IAB, IESG, etc. drafts.

> drafts?  Seems like a more fruitful special treatment than to  
> specifically disallow them.  Then you'd have a list of people who could  
> approve posting of -00 versions of such drafts (the 'WG Chairs', from  
> the tools viewpoint).

I was simply not sure IETF has enough backend metadata to identify
all IAB people, all IESG people, all IRTF people, etc., that can
approve 00 drafts. However, since we are not documenting how to
automate this step, I do agree with you. The Toolset should just
treat all those 4 special strings as WG names. I will adjust the
draft text accordingly (most likely by extending the WGN definition).

If the list is not

	"iab", "iesg", "rfc-editor", "irtf"

then please let me know the correct values.

> the XML submission requirements.

I think having four stages would be doing too much micromanagement
when some of us are sure that (b) and (c) requirements are going to
change with (a) experience. The current stage semantics is:

	a) A minimum set of features for the first public version of
          the Toolset that can handle most "common" drafts submitted
          today.

	b) A comprehensive set of features that we think needs to be
	   implemented soon.

	c) A vague long-term Toolset roadmap.

If IESG thinks that the email interface is not needed any time soon,
let's place it in (c). If IESG thinks that email interface is
needed soon, let's instruct the implementors that XML has priority
over email interface but leave both in stage b. (A good implementation
team will make multiple releases per stage. A team of more than one
person should work on more than one feature at the same time.)

Can we ask IESG to make this choice?

Thank you,

Alex.
P.S. I do not think that IESG should make all design choices because
the Tools team is supposed to represent IETF needs, not just IESG
needs. However, when the Toolset team is not sure what the right
thing to do is, and when the Toolset team preferences meet significant
and broad resistance, IESG should step in.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 27 Apr 2005 18:32:49 +0200

> automated. Sorry if I was supposed to do that change earlier.

I thought we touched on this, but it could have been just something
that passed my mind.  Anyway, what about:

   'If (a) no approval exists, (b) the Toolset supports the "waiting for
   WG approval" feature, and (c) the draft can be posted if WG approval
   is received, then the Toolset explains the situation to the submitter
   and asks whether an explicit approval from the WG (R126/b) should be
   solicited.  If the submitter requests solicitation for approval, the
   Toolset puts the submission into a "waiting for WG approval" state
   until the approval is received (R127/b).  Otherwise,
   the Toolset records a "no WG approval is expected" error (R138/b).
   The details and mechanics of solicitation for WG approval is outside
   the scope of this document.'

 ?

> draft text accordingly (most likely by extending the WGN definition).

Sounds good to me.  Brian?

> then please let me know the correct values.

Looks good to me.  Brian?

> person should work on more than one feature at the same time.)

Ok.  Then I suggest we add a hint about multiple releases and preferred
order of implementation of XML support relative to mail support.

> Can we ask IESG to make this choice?

I guess we should have a proposal on the table - could be as simple as
my suggestion above.

	Henrik

> and broad resistance, IESG should step in.

Yes, I guess - but if we can reach a consensus based on the new input
that is also good.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Apr 2005 07:37:47 +0200

I am in the IESG Retreat meeting and then the IETF/ITU Workshop
for the next few days... will respond next week.

    Brian