Subject: Micro issue in I-D boilerplate required by RFC 3978

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Oct 2006 10:58:37 +0200

An I-D submitter has raised the following issue.

Our required I-D boilerplate starts with:

    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.

Since BCP 79 may potentially be updated from time to time, which
version of BCP 79 does this refer to? Is it necessary to make this
clear in the I-D boilerplate, e.g. by changing the last clause to

    in accordance with the version of BCP 79 in force at the moment
    this draft was published.

Or is this already implied?

     Brian

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

---

From: John C Klensin <[email-masked]>
Date: Sat, 21 Oct 2006 11:52:04 -0400

> Or is this already implied?

Brian,

This issue is exactly why previous versions of that boilerplate
required reference to an RFC number, which is unambiguous with
regard to the text being agreed to.  It was, if I recall,
changed (at least in part) because updating tools and templates,
and remembering to update boilerplate in earlier drafts, was
becoming burdensome when we were changing the referenced text,
and hence the boilerplate requirement, at frequent intervals (a
pattern that has not stopped).

Even an "implied" theory does not work well, since I-Ds are
sometimes prepared over periods of many weeks and there is
ambiguity about whether what is being agreed to is the text in
effect when work starts or when the document is posted.   In
addition, I don't believe that the status of a >> -00 draft is
completely clear: even with your proposed change, it would not
be completely clear whether the applicable text was that at the
time the -00 draft was posted or at the time an update was
posted.  It is also not clear from our procedural model whether,
if the IESG issues an action notice on a document that updates a
BCP, whether that update takes effect when it is published or
immediately (see "observation 1", below).

Of course, a large part of the solution to the practical, rather
than theoretical, problems is to get BCP 79 right, once, and
stop the process of continually fussing with it, whether by
small amendments and clarifications or by fine-tuning rewrites/
reissues.  

   ------------

Observation 1: Of course, that question impacts our entire
procedural model.  If I recall, 2026 doesn't even make it clear
whether the timers on document advancement start at IESG
approval or at RFC publication and, if the latter, how we count
given that RFCs are dated in month units, not day units.   Were
we to try to fix that, we would, IMO, discover yet another
reason why IETF procedural documents need to be removed from the
document series into which we put Internet "best practice"
operational notes and the equivalent.

Observation 2: The fact that you have discovered a need to ask
this question is, IMO, yet another symptom that this WG is
wandering in the weeds and that its document generation and
approval processes are insufficient to the task (if not actually
broken).  The WG now has an impressive track record of agreeing
to, and reaching rough consensus on, documents that contain
provisions that later turn out to be insufficiently precise, to
impose unanticipated side-effects, or to be legally
questionable, if not meaningless.  And, again IMO, the community
has gotten burned out enough on these issues and discussions
that the odds of someone who hasn't been involved in the WG
giving a proposed new document a sufficiently fresh and close
reading to catch the problems prior to document approval are
slight.  Indeed, I think we have already proven that hypothesis.

I think it is time for either a break, some serious thinking
about different ways to do this work, or both.

     john

---

From: "Contreras, Jorge" <[email-masked]>
Date: Sun, 22 Oct 2006 09:14:37 -0400

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Saturday, October 21, 2006 4:59 AM
> To: IPR WG
> Subject: Micro issue in I-D boilerplate required by RFC 3978
> 
> 
The contributor can only make a representation as of the date on which
the ID is submitted (not published).  He/she cannot make a 
representation as to future versions of the BCP.  I think this is
relatively clear from the text and no revision is needed, but
obviously the clarification would not hurt either.

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 22 Oct 2006 11:04:01 -0700 (PDT)

On Sat, 21 Oct 2006, John C Klensin wrote:
> [ ... ] IMO, the community has gotten burned out enough on these
> issues and discussions that the odds of someone who hasn't been
> involved in the WG giving a proposed new document a sufficiently
> fresh and close reading to catch the problems prior to document
> approval are slight.  Indeed, I think we have already proven
> that hypothesis.

I know that in the above John was speaking for himself, but those
words happen to speak for me also.

During the time I served as editor of the drafts that because the
MIB review guidelines (now RFC 4181/BCP 111), I was required to
track what was going on in this WG because it affected the document
I was editing.  The version of that document that was submitted in
August 2003 was nearly ready for last call, but a decision was made
to hold off publication because some of the document submission
requirements were expected to change as a result of the
deliberations of the IPR WG.  In June 2004 we had an update that was
compliant with RFCs 3667 and 3668, but because there had been
substantial changes, we elected to hold off last call pending actual
experience with the update.  In the meantime there was some more
churn in the IPR WG leading to RFCs 3978 and 3979.  We submitted
another version in February 2005 that was compliant with the
then-current AUTH-48 versions of those RFCs.  That version was
finally published in September 2005.  The change log in the
following draft can provide additional historical details.

http://www.watersprings.org/pub/id/draft-ietf-ops-mib-review-guidelines-04.txt

After that excercise I can assure you that I have had quite enough.
Fortunately for me, it will be some else's problem to deal with the
effects of the next set of changes in the MIB review guidelines that
will be required by the seeming endless changes in the IETF IPR
documents.

> about different ways to do this work, or both.

Indeed.

//cmh

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 22 Oct 2006 21:51:20 +0200

"Contreras, Jorge" <[email-masked]> writes:

> representation as to future versions of the BCP.

Agreed.

> I think this is relatively clear from the text and no revision is
> needed, but obviously the clarification would not hurt either.

It can take years to get a RFCs published, so I believe a reference to
"BCP 79" in a particular document isn't as stable as you suggest.

Consider if RFC X is BCP 79 at the time of I-D publication and RFC Y
is BCP 79 at the time of publication.

As far as I know, the date when the ID was submitted is not preserved
anywhere in the final RFC -- the date in the RFC is the publication
date of the RFC.

The problem would be smaller if the I-D tracker history is guaranteed
to be preserved forever.  Possibly the I-D tracker history for all
documents could be published in an RFC from time to time.

/Simon