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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 May 2005 10:23:09 +0200

Trying to catch up after several days lost in meetings.

I will also go back to a couple of earlier messages
to see if I have anything to add. But I think it's probably time
for you to make a -09 with the latest set of comments included
and then I will put it into IESG evaluation.

Some comments below.

Henrik Levkowetz wrote:
> on 2005-04-27 5:47 pm Alex Rousskov said the following:
> 
>>On Wed, 2005/04/27 (MDT), <[email-masked]> wrote:
>>
>>
>>>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.
>>
>>I would be happy to specify that we expect this process to be
>>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.'

The ID-tracker already sends a lot of automatic emails when certain
events occur, so I actually don't see why you think this is hard to
specify or implement- the WG chairs are well known and the message
will always be the same. I really don't think users will understand
why they have to send it manually. I would prefer the last sentence
to be more explicit. If what you mean is the following why not say it:

   Initially the submitter will be responsible for soliciting WG Chair
   approval. Automation of this solicitation is for future study.

> 
>>>>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?
>>>
>>>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.
>>
>>
>>>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).
>>
>>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).
> 
> 
> Sounds good to me.  Brian?

Sure. If it can be handled by extending the general mechanism,
that's good.
> 
> 
>>If the list is not
>>
>>	"iab", "iesg", "rfc-editor", "irtf"
>>
>>then please let me know the correct values.
> 
> 
> Looks good to me.  Brian?

I believe so. In any case I assume this will be data-driven anyway,
not hard-coded.
> 
> 
>>>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 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.)
> 
> 
> 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.

It's best to make a definite proposal. If the IESG dislikes it, they
will tell you. If you leave options, the IESG is guaranteed
to ask for a new draft.

    Brian
> 
> 	Henrik
> 
> 
>>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.
> 
> 
> Yes, I guess - but if we can reach a consensus based on the new input
> that is also good.
> 
> 
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tools-discuss
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 May 2005 10:41:02 +0200

small responses below...

Alex Rousskov wrote:
> On Tue, 2005/04/26 (MDT), <[email-masked]> wrote:
> 
>> 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.
> 
> 
> And yet, XML has no official status in IETF.

Correct. But the submission format is an operational matter - what is
clear as a matter of principle is that the posting and archive format
is plain text.

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

Indeed not. Maybe what we need is a general remark that it isn't
*forbidden* to include /b features in the /a release, if that turns
to be practical from a coding point of view.
> 
>> A related point is that I would always give metadata extraction from XML
>> 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?

A hint I think. It would be a bit strange in reality if the txt is generated
from xml yet has inconsistent metadata, so the problem is rather theoretical.
> 
>> I don't think I saw any mention of 1id-guidelines. The intent is to
>> 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.

OK

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

OK

>> and you need to specify whether values >99
>> are allowed. (On DOS grounds, I'd say not.)
> 
> 
> 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 :-(.

My concern is that the programmer of the tool needs to know whether the version
number is a bounded value, if only because of writing the rendering code.
If s/he assumes there are only two digits, there is a well known bug by which
draft-foobar-101.txt would be rendered as -10 or -01 or -**. So we need a rule.
I don't really care what it is (>99 allowed and rendered or >99 illegal).
> 
>>> 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.
> 
> 
> 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.

Hmm. I guess it's logical  but I still find 48 hours too short. Generate
a draft Friday afternoon, post it on Monday morning, and you get an error.
I think this will annoy people.
> 
>>>    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.)
> 
> 
> 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.

Sure, it just needs to be stated.
> 
>>> 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?
> 
> 
> Yes. We should add a sentence to clarify this.

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

OK, that was not so easy to find.

> 
>>
>>> 8.5.3  DoS thresholds
>>
>> ...
>>
>>>      
>>> +----------------------------------------+--------------+-----------+
>>>    | category                               | versions/day |    MB/day |
>>>    +----------------------------------------+--------------+-----------+
>>>    | drafts with the same draft name        |            3 |         5 |
>>
>> ...............................................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.

I guess.
> 
>>>    | drafts with the same submitter         |            5 |        10 |
>>>    | WGN drafts with the same WG ID         |           10 |        15 |
>>
>> ...............................................these seem low
> 
> 
> I would be happy to raise these. 10 and 30?

I think that is safer, in the days just before the cutoff.

> 
>>>    | all drafts                             |          300 |       150 |
>>>    +----------------------------------------+--------------+-----------+
>>
>>
>> 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.

OK

(end of comments in this mail)

     Brian

> 
>>> 8.5.4  WG approval
>>
>> ...
>>
>>>    If (a) no approval exists, (b) the Toolset supports the "waiting for
>>>    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,
>> 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.
> 
> 
> 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
>> "user declined to request WG approval"?
> 
> 
> 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).
> 
>>> 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.
> 
> 
> I think there are two separate issues here. The first issue is increasing
> "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.
>>> 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.
> 
> 
> 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, 04 May 2005 12:06:27 +0200

on 2005-05-04 10:23 Brian E Carpenter said the following:
[...]
>    approval. Automation of this solicitation is for future study.

What I intended to say was basically "The tool will solicit WG Chair
approval.  The details and mechanics of solicitation for WG approval is outside the scope of this document."

So what about:

   and asks whether the tools should solicit an approval from the WG
   (R126/b).  If the submitter requests solicitation for approval, the

[...]
> I believe so. In any case I assume this will be data-driven anyway,

Right.

[...]
> will tell you. If you leave options, the IESG is guaranteed

Ok.  Alex, could you propose a hint about multiple releases and preferred
order of implementation for stage b) and c) ?

	Henrik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 May 2005 13:29:54 +0200

wfm
    Brian