Micro issue in I-D boilerplate required by RFC 3978

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
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

--On Saturday, 21 October, 2006 10:58 +0200 Brian E
Carpenter
<brczurich.ibm.com> wrote:

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

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


_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

> -----Original Message-----
> From: Brian E Carpenter [mailto:brczurich.ibm.com]
> Sent: Saturday, October 21, 2006 4:59 AM
> To: IPR WG
> Subject: Micro issue in I-D boilerplate required by RFC
3978
> 
> 
> 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
> 
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.

_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

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.

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

Indeed.

//cmh


_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

"Contreras, Jorge" <Jorge.Contreraswilmerhale.com> writes:

>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brczurich.ibm.com]
>> Sent: Saturday, October 21, 2006 4:59 AM
>> To: IPR WG
>> Subject: Micro issue in I-D boilerplate required by
RFC 3978
>> 
>> 
>> 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
>> 
> 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.

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

_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg