Subject: Re: [Tools-discuss] RE: I-D woes [Re: advice on role of a WG Chair]

From: Bill Fenner <[email-masked]>
Date: Sat, 1 Jul 2006 08:13:42 -0400

>But I can't find the last page requirement
>that Donald reported of from the guidelines.
>Perhaps this is a bug.

1id-guidelines says that the boilerplate in question needs to appear
"near the end".  I think it is probably a bug introduced when translating
from prose to program.

>Anyway, I do not believe we have a satisfactory solution
>until there's real-time feedback that you can or can not
>submit this draft because of <X>.

Yes, the draft submission toolset will improve the feedback
cycle.

  Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Jul 2006 11:54:41 +0200

> "near the end".  I think it is probably a bug introduced when translating

Indeed, and wouldn't a protocol spec that said
"the foobar field needs to appear near the end of the packet"
attract a fairly strong DISCUSS from one AD or another?

    Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 30 Jun 2006 09:45:19 -0700

[email-masked] wrote:
> Jari,
> 
> I have no problem about checking for nits (as some of the 
> nits do have significant impact upon those people reading the
> drafts) & the boilerplate is there for good reason.
> 
> I think the biggest take-away from this thread is that there
> have been changes to the submission procedure which have
> been unannounced & undocumented (perhaps known only by the
> Tools team, IESG & Secretariat).

Amen. But you also forgot "unreviewed". They sometimes add required
elements without discussion too.

Joe

---

From: Bill Fenner <[email-masked]>
Date: Mon, 3 Jul 2006 09:30:12 -0400

>attract a fairly strong DISCUSS from one AD or another?

Our rules have been becoming more and more arbitrary.
Is there a particular reason that this text needs to occur
exactly on the last page?  In fact, is there a reason that
it needs to occur in any place other than "in the document
somewhere" (i.e., why can't the existing guideline be lifted,
instead of made more strict)?

  Bill

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 03 Jul 2006 15:41:38 +0200

> instead of made more strict)?

I agree: I'd also prefer to see our rules become fewer and less
strict rather than the opposite; and especially when the rules seem
arbitrary.

I can imagine that if one has to have certain boilerplate text
in the document for legal reasons, it is preferable to have it at
the end rather than filling several of the first pages, but that
still seems like something we can leave to common sense, rather
than define rules for.

	Henrik

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Jul 2006 06:51:07 -0700

> instead of made more strict)?

Indeed.

I'd like to point out (for the umpteenth time) that as far
as I can tell the purpose of much of the boilerplate is
for the submitter to affirm the license grant/acceptance
of the BCP 79 terms, etc. This material does not need
to be in the document proper, it just needs to be 
agreed to somewhere. It would be quite feasible to
have a web submission form where people agreed to these
terms and they never appeared in the document (modulo
complaints about web-only submission).

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Jul 2006 16:56:02 +0200

Eric,

Moving the boilerplate out is indeed under discussion in the
IPR WG - this has several advantages, but it does require
a formal update to RFC 3978 unfortunately.

Bill,

I think it's reasonable to have "near the end" as a cosmetic
guideline, but making it a formal requirement does seem over the
top. You'll understand that with this being a holiday week in the
US and next week being the IETF, this isn't going to get
followed up right away.

    Brian

---

From: Andy Bierman <[email-masked]>
Date: Mon, 03 Jul 2006 08:16:25 -0700

> strict rather than the opposite; and especially when the rules seem

Thank you!

I suspect there is no way to answer Juergen's question about
how all these (not well understood) rules, just to
submit a work-in-progress for publication, actually improve
Internet standards quality.

We need the IETF to protect the world from bad protocol design,
not improper pagination.  Please don't forget that.

> still seems like something we can leave to common sense, rather

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 03 Jul 2006 08:49:58 -0700

Hi,

I think the submission tool and submission process needs
to be changed:

  1) All of the document checks done by the submission tool
     must be documented in detail, and prioritized as either
     a fatal error or some warning level.  (IMO, there should
     be very few fatal errors defined other than IPR boilerplate.)

  2) For I-Ds that are considered 'work-in-progress', only fatal
     errors will cause an I-D submission to be rejected.  Warnings
     should be returned to the user in an email, along with the
     ACK that the I-D was received.

The ID submission tool could even get the work-in-progress status
(i.e., before draft is submitted to the IESG) from the ID-Tracker
so a special submit option may not even be needed.

I would prefer that a WG not miss a I-D submission cycle
because a document had some lines over 72 chars, or any of dozens
of other ID-nits.  (I would prefer no CLRs at all, but that's
not gonna happen here ;-)

Andy

---

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Jul 2006 19:03:31 +0300

Andy,

> Internet standards quality.

I hate bureacratic rules too. And I agree with all that
has been said about reducing the rules, announcing
new rules if we really need them, and getting real-time
feedback at submission time.

But let me nevertheless attempt to justify why some
rules are needed. There are some legal reasons why
a boilerplate (or a web-submission confirmation page)
is needed, I think we all have to accept that. There are
also some rules that come from the tracker; a draft needs
to have a filename, for instance, and that name has to
satisfy some requirements that the currently used system
has.

So, the set of mandatory requirements is not very big,
but there are some. As far as I know, we are not bouncing
draft because of long lines, for instance. Also, its a great thing
that we have at least partial automation of the process. Remember
the old times when it took a long time to publish a draft,
particularly at busy times? From what I can see, its most
of the time same day service now.

In any case, I have a concrete suggestion for next steps:
Let Bill (e.g.) update his guidelines and talk to the
secretariat about the last page bug. Then those of
us who feel that we need a better boilerplate scheme (e.g.
just confirmation), lets go to the IPR WG and make ourselves
heard and/or understand if this is possible. Finally, I think
we should avoid investing too much in the improvement
of the current system. The I-D submission tool is already
a high priority work item at the secretariat. Lets focus
on getting that done.

--Jari

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Jul 2006 09:15:38 -0700

> not gonna happen here ;-)

Two thoughts:

1. Can someone who knows explain which of the tests the secretariat
applies are automated and which are not? Just thinking that
most of the complaints I'm hearing here are about people worried
about missing the deadline. If you got an immediate automated
"your draft is broken" response, then this would be less of a
concern.

2. I've been involved in a lot of conferences with fairly strict
submission deadlines and it's usually understood that if you 
submit before the deadline but it's broken in some unobvious
way (e.g., figures don't display on some printers), then the
organizers contact you for a new version rather than just
rejecting it, as long as it appears you made a good-faith attempt
to follow the submission guidelines.

I'm not entirely sure what the secretariat policy is here, but
it appears that we could follow a similar rule: if your draft
passes some set of things in the latest version of id-nits, then
you have a safe harbor and can correct it rather than having it
rejected.

-Ekr

---

From: Andy Bierman <[email-masked]>
Date: Mon, 03 Jul 2006 09:38:42 -0700

>> not gonna happen here ;-)

Final thought (and then I'll leave it alone):

Almost all of you are completely missing my point that all
this energy spent on defining, automating, and adhering
to a never-ending list of documentation rules is not helping
the IETF achieve its primary mission.  In fact, it is
having the opposite effect.

Andy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Jul 2006 09:45:30 -0700

> having the opposite effect.

Well, I for one am not missing it. I just figure that that's
a big argument and a simple fix might make most of the pain
go away.

-Ekr

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 03 Jul 2006 18:56:22 +0200

Hi Andy,

>      ACK that the I-D was received.

This pretty much matches the approach described in RFC 4228, which
is the requirements document for the automated draft submission tool
which is intended to replace the current manual/semi-automated
process.

For more details regarding this, please check RFC 4228 and comment
to the tools-discuss list if there is anything you think we've missed
there.

> so a special submit option may not even be needed.

Yes.  More details in 4228.

> not gonna happen here ;-)

I think there are good reasons for some rules, and I think the rules
we have are fairly well adapted to the different stages in a document's
life cycle.  The crucial issue is to not have surprises just before
the submission deadline.

Both the any-id submission rules
  (http://www.ietf.org/ietf/1id-guidelines.txt)
and the publication submission rules
  (http://www.ietf.org/ID-Checklist.html)
are reasonably good in explaining the reason for the various rules, I
think.

Where I have hope for improvements in the rules are in the amount of
boilerplate in each document, which, as Brian mentioned, ipr-wg is
looking at.

Where I have hope for improvements in the application of the rules is
through the implementation of 4228, which the IAD is engaged in making
happen - I don't know exactly what the schedule looks like for that work,
but expect that we'll get an update on this during the coming meeting.

The only thing I'd mention as desirable in the meantime is that any
changes in the manual application of the existing rules be announced
by the secretariat, and if such changes are necessary they should be
made early in the inter-meeting period rather than close to the
submission deadline.

Regards,

	Henrik

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 3 Jul 2006 21:37:36 -0400

> a formal update to RFC 3978 unfortunately.
That is, in fact, on the IPR agenda for next week.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Jul 2006 09:38:26 +0200

>> submission deadlines and it's usually understood that if you submit 
>> before the deadline but it's broken in some unobvious

This is what happens, and this is why you still see a few drafts
coming out this week.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Jul 2006 09:36:24 +0200

Once again, there is going to be a new tool based on
RFC 4228. There isn't going to be any work done on the
existing tools that support the old manual submission process.

People will have to see whether the new tool, when it comes,
fixes all these concerns - and if it doesn't, then there will
be a need for tuning.

     Brian

---

From: Martin Duerst <[email-masked]>
Date: Tue, 04 Jul 2006 12:10:06 +0900

>complaints about web-only submission).

It would. And it would be okay with me. But then when
somebody really needs to show that there was such an
agreement, it will be much more work (contacting the
secretariat, finding out which boilerplate was agreed
to (there is more than one), and so on).

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Martin Duerst <[email-masked]>
Date: Tue, 04 Jul 2006 12:07:55 +0900

>so a special submit option may not even be needed.

That wouldn't work for the draft that is actually going to be
submitted to the IESG, or would it?

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 04 Jul 2006 12:04:24 +0900

>to the tools-discuss list if there is anything you think we've missed

Just a few more ideas (probably somebody already has had these):

1. One thing that crossed my mind is that it would be a bad idea to have
an idnits tool as well as a submission tool. Make it one tool, with a
selection of "actual submission" or "check only". That way, tool
differences are eliminated by design.

2. Another issue is the announcement of new rules. To implement a grace
period, use two (or more) versions of the actual checking routines.
Let's say there is one procedure that checks for what was the rule
at IETF65, and another for IETF66. Assuming that the rules for IETF66
were announced at IETF65, submissions between IETF65 and IETF66
would be first checked against IETF66 rules, and any problems
would be reported. Then, in the same turnaround, the submission
would be checked against IETF65 rules, and if it passes these, it
would be accepted with a very clear notice that this is due to
a grace period (and maybe even giving the submitter an option
to not submit but to try to catch up to the new rules).

Given all the recent complaints, 1. seems to be a no-brainer.
2. in my opinion would also be great, and not too difficult
to implement in terms of software, but it requires more effort
for the announcements,...

Regards,    Martin.

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 04 Jul 2006 12:48:48 +0200

Hi Martin,

> differences are eliminated by design.

If you read 4228 you'll find this covered already.  There is also a
requirement which says that the component which does the checking should
be a publicly available tool, such as idnits.  It is not required that
idnits specifically be used, but if some other checking tool is used as
part of the submission tool, it must also be made publicly available
separately from the submission tool.  The secretariat have already
indicated a wish to use idnits for the checking part, and I will add
the necessary functionality and switches to do only guidelines checking,
nits checking or both.

> to not submit but to try to catch up to the new rules).

Sounds like a possibility.  When we transitioned to 3978, I implemented
something very similar in idnits, providing warnings for a time, and
then errors for 3978 non-compliance.  This was governed by the policy
set for the secretariat's application of 3978.  When the RFC was published,
I implemented the warnings (version 1.63); when the deadline published
for the strict application went into effect, I changed these to errors
(version 1.71).

> Given all the recent complaints, 1. seems to be a no-brainer.

And already covered in 4228 :-)

> for the announcements,...

Yes.

Regards,

	Henrik

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Jul 2006 14:14:31 +0200

> submitted to the IESG, or would it?

RFC 4228 distinguishes warnings from mandatory fixes; basically
an IESG submission should have zero warnings, just like it should
pass id-nits today.

    Brian

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Jul 2006 07:01:49 -0700

> fixes all these concerns - and if it doesn't, then there will

Bottom Line Question:

Will the Boilerplate ever be done, and if so, when?

(Anybody who thinks our documentation rules don't impact quality
has not been asked to make clarifications to an old RFC.  You
either refuse to touch the RFC at all, or you spend 10X more
work on Boilerplate changes than clarifications.)

Andy

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 05 Jul 2006 13:50:11 +0200

Hi Eric and Andy,

> complaints about web-only submission).

I would like to point out that there are certain exceptions to granting 
the IETF rights that the draft author can choose. In those cases it 
would still be important to indicate that fact.

> work on Boilerplate changes than clarifications.) 

I don't agree at all here. The boilerplate is a piece of cake compared 
to getting some protocols into shape. There are a lot of RFCs that are 
badly specified that it is substantive amounts of work of updating and 
clarifying them. Adding the correct boilerplate is not an issue. 
Especially as when updating the draft, you can just as well move it into 
XML2RFC and have the basic boilerplate done. There is common that you 
will need to substantially improve things like security consideration 
and IANA consideration sections. However that is simple because they 
been lacking in the previous version.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 5 Jul 2006 10:57:38 -0400

> work on Boilerplate changes than clarifications.)
One item on the IPR agenda is a revision that moves the boilerplate to a
web site -- that should make cut-and-paste much easier.

---

From: Bill Fenner <[email-masked]>
Date: Wed, 5 Jul 2006 11:08:44 -0400

>web site -- that should make cut-and-paste much easier.

Please forgive the ignorant question, but how is cut-and-paste from
boilerplate on a web site easier than cut-and-paste from, oh, say,
http://www.ietf.org/ietf/1id-guidelines.html#iprnotices ?

  Bill

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Jul 2006 10:31:39 -0700

>http://www.ietf.org/ietf/1id-guidelines.html#iprnotices ?

Hmm, I thought the point was to say:  "In compliance with the statement
at $WELLKNOWNPLACE".    Then you don't have to cut and paste the statement
at all, just point to it.   Is that not correct?
				Ted

---

From: Bill Fenner <[email-masked]>
Date: Wed, 5 Jul 2006 14:25:42 -0400

>at all, just point to it.   Is that not correct?

draft-ietf-ipr-rules-update-06 changes 3978 section 5.1 from:

    5.1.  IPR Disclosure Acknowledgement (required in all Internet-Drafts
          only)

      "By submitting this Internet-Draft, each author represents that
      any applicable patent or other IPR claims of which he or she is
      aware have been or will be disclosed, and any of which he or she
      becomes aware will be disclosed, in accordance with Section 6 of
      BCP 79."

to:

   "5.1.  IPR Disclosure Acknowledgement (required in all Internet-
      Drafts but not in RFCs)

      All I-Ds MUST include the exact text for an IPR Disclosure
      Acknowledgement from http://www.ietf.org/ipr-boilerplate-
      derivworks

which I don't think changes anything for I-D writers - it provides
a single place to copy-n-paste from, but we already have that in
1id-guidelines.  It does make it easier for the IETF to update the
boilerplate, since it doesn't mean publishing a new version of BCP 78.
I've already had my rant on the ipr list about making it seem low cost
to update the boilerplate so I won't bother repeating it here.

  Bill

---

From: Martin Duerst <[email-masked]>
Date: Thu, 06 Jul 2006 10:12:47 +0900

>at all, just point to it.   Is that not correct?

I don't think this will work. There are two variants here:

1) $WELLNOWNPLACE itself is constant, but because the requirements
   change, the sentence in the draft has to be changed from
   $WELLNOWNPLACE1 to $WELLNOWNPLACE2 to $WELLNOWNPLACE3,...
   -> Editors still have to make sure they get the number right :-(

2) $WELLNOWNPLACE changes. What you then get is that it looks like
   people who authored a draft two years ago agree to the current
   (and any future) IETF statement, and that you can't really
   trace what they actually agreed to :-(

If you want to make things easier with tools, what might be done
is the following: When a draft is submitted, e.g. the copyright
year is checked, and if it is found to be too old, the tool
asks the submitter whether s/he is okay that the year is changed.
The draft is then changed automatically. Similar things can be
done for newer boilerplates, but of course some submitters will
have to click cancel and check back with their legal departments.
The main problems with this kind of approach would be:
1) The published draft is correct, but the editor forgets to
   update the local copy, and the next version has to be fixed
   again.
2) People might ask for more and more semi-automatic fixes.

Regards,    Martin.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jul 2006 16:51:10 +0200

I suggest taking this discussion to the ipr WG, which gets to decide.

    Brian

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Jul 2006 16:41:50 -0400

I just wanted to make a small follow-up on the I-D
submission problem discussion.

As you may recall, it was mentioned that with
automated submission tool you could get real-time
feedback and be able to avoid a problem if there's
one. I talked to Ray and he tells me that the current
target is to have a tool available by the end of the
year (subject to ongoing negotiation and other
usual disclaimers). I'm looking forward to the new
tool, I'm sure it will make most of these problems go
away!

Also, the IPR WG is discussing various clarifications,
relaxations, and new ideas relating to the templates.

I have not learned of any unannounced policy changes,
though there has been some unclarity in RFC 3978 which
led to one of the problems people had. The secretariat
is following 3978 until we decide to update that RFC.

Finally, we never figured out at whose end the
communication problem involving submissions
from one of my WGs was.

--Jari