Subject: Idnits is strangely picky about BCP 78 language

From: John Scudder <[email-masked]>
Date: Wed, 15 Apr 2020 20:57:27 +0000

Hi Henrik (and all),

I’ve noticed from time to time that idnits is awfully prissy about BGP 78 language in drafts that claim to update an older RFC. To add to the fun, it’s inconsistent in how it does so. In today’s example, I uploaded draft-ietf-idr-rfc8203bis-06. The idnits that gets run automatically by the submission tool runs 100% clean (maybe misc. warnings are suppressed?). But when I run it later (https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-idr-rfc8203bis-06.txt) I get this complaint in the “miscellaneous warnings” section:

     (Using the creation date from RFC4486, updated by this document, for
     RFC5378 checks: 2006-01-25)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

It’s not at all clear to me why it’s appropriate for idnits to assume that just because I update a pre-2008 RFC, it means I have to get the acquiescence of the authors of the updated RFC. In the case of the current draft, and other drafts I’ve written or shepherded that update some previous RFC, there is little if any text copied from the older RFC, so to my understanding, no need for contacting the older authors. For that matter, the more likely place, in my experience, to find large swaths of copied text is in -bis documents, which generally do NOT update their predecessors, but rather obsolete them.

So, my contention is that “updates” is neither a necessary, nor a sufficient, condition for assuming that BCP 78 assignment is needed. I do admit that it’s possible, but in real life I’ve never had this particular warning be anything other than noise. I propose you remove it. $0.02.

Thanks,

—John

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Apr 2020 14:25:19 +0200

Hi John,

Since idnits cannot judge whether there's actually anything from the updated
document that has been included in the text of the updating document and
therefore necessitates the warning, it can neither make it stronger
nor omit it.  For some documents it can be a real issue.

What I could do is change it from a warning to a comment.

I would like, however, to have the IESG make the determination.

Additional notes, inline:

On 2020-04-15 22:57, John Scudder wrote:
> Hi Henrik (and all),
> 
> I’ve noticed from time to time that idnits is awfully prissy about
> BGP 78 language in drafts that claim to update an older RFC. To add
> to the fun, it’s inconsistent in how it does so. In today’s example,
> I uploaded draft-ietf-idr-rfc8203bis-06. The idnits that gets run
> automatically by the submission tool runs 100% clean (maybe misc.
> warnings are suppressed?).

Yes, for submission purposes, idnits runs only the appropriate checks
from 1id-guidelines, and not at all the RFC publication checks in
https://www.ietf.org/id-info/checklist.  (It uses the --submitcheck
switch).

> But when I run it later
> (https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-idr-rfc8203bis-06.txt)
> I get this complaint in the “miscellaneous warnings” section:
> 
> It’s not at all clear to me why it’s appropriate for idnits to assume
> that just because I update a pre-2008 RFC, it means I have to get the
> acquiescence of the authors of the updated RFC.

The warning isn't intended to tell you to do anything, only to consider
the issue.  If a wording change would make you happier, and suits the
IESG, I'd be happy to tweak it.

> In the case of the
> current draft, and other drafts I’ve written or shepherded that
> update some previous RFC, there is little if any text copied from the
> older RFC, so to my understanding, no need for contacting the older
> authors. For that matter, the more likely place, in my experience, to
> find large swaths of copied text is in -bis documents, which
> generally do NOT update their predecessors, but rather obsolete
> them.

So should this warning also be issued for this case?  Should it trigger
on 'Obsoletes' or on a -rfcXXXXbis- name?

Best regards,

	Henrik

> So, my contention is that “updates” is neither a necessary, nor a
> sufficient, condition for assuming that BCP 78 assignment is needed.
> I do admit that it’s possible, but in real life I’ve never had this
> particular warning be anything other than noise. I propose you remove
> it. $0.02.
> 
> Thanks,
> 
> —John 
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Apr 2020 08:51:49 -0400

Henrik:

Thank you for your explanation.  I will talk to Alvaro about adding this question to an IESG chat. 

Sue 

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Henrik Levkowetz
Sent: Thursday, April 16, 2020 8:25 AM
To: John Scudder
Cc: WG Chairs
Subject: Re: Idnits is strangely picky about BCP 78 language

Hi John,

Since idnits cannot judge whether there's actually anything from the updated document that has been included in the text of the updating document and therefore necessitates the warning, it can neither make it stronger nor omit it.  For some documents it can be a real issue.

On 2020-04-15 22:57, John Scudder wrote:
> Hi Henrik (and all),
> 
> I’ve noticed from time to time that idnits is awfully prissy about BGP 
> 78 language in drafts that claim to update an older RFC. To add to the 
> fun, it’s inconsistent in how it does so. In today’s example, I 
> uploaded draft-ietf-idr-rfc8203bis-06. The idnits that gets run 

Yes, for submission purposes, idnits runs only the appropriate checks from 1id-guidelines, and not at all the RFC publication checks in https://www.ietf.org/id-info/checklist.  (It uses the --submitcheck switch).

> But when I run it later
> (https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-iet
> f-idr-rfc8203bis-06.txt) I get this complaint in the “miscellaneous 
> warnings” section:
> 

The warning isn't intended to tell you to do anything, only to consider the issue.  If a wording change would make you happier, and suits the IESG, I'd be happy to tweak it.

> In the case of the
> current draft, and other drafts I’ve written or shepherded that update 
> some previous RFC, there is little if any text copied from the older 
> RFC, so to my understanding, no need for contacting the older authors. 
> For that matter, the more likely place, in my experience, to find 
> large swaths of copied text is in -bis documents, which generally do 
> NOT update their predecessors, but rather obsolete them.

So should this warning also be issued for this case?  Should it trigger on 'Obsoletes' or on a -rfcXXXXbis- name?

Best regards,

	Henrik

---

From: David Noveck <[email-masked]>
Date: Sat, 18 Apr 2020 10:48:41 -0400

Although I agree with the proposed shift from warning to comment and hope
the IESG approves it, I think
that there is a significant issue with the text of the message which would
be helpful to address, whatever
the IESG decides on warning-vs.-comment.

While the first sentence is clear that this is only a potential problem
(i.e. that such matetial *might* be present),
the rest of the message is wriiten as if it is certain that such material
does exist.  Suggest replacing the first
sentence by the following two:

The document seems not to have a disclaimer for pre-RFC5378 work, but might.
have content which was first submitted before 10 November 2008.  In the
event
that such content actually exists, there are two approaches that might be
followed:

On Thu, Apr 16, 2020 at 8:54 AM Susan Hares <[email-masked]> wrote:

> Since idnits cannot judge whether there's actually anything from the
> updated document that has been included in the text of the updating
> document and therefore necessitates the warning, it can neither make it
> stronger nor omit it.  For some documents it can be a real issue.
>
> Yes, for submission purposes, idnits runs only the appropriate checks from
> 1id-guidelines, and not at all the RFC publication checks in
> the issue.  If a wording change would make you happier, and suits the IESG,
> I'd be happy to tweak it.
>
> > In the case of the

---

From: John Scudder <[email-masked]>
Date: Sat, 18 Apr 2020 15:17:38 +0000

I think your proposed text is a whole lot clearer, thanks.

—John

On Apr 18, 2020, at 10:48 AM, David Noveck <[email-masked]> wrote:

Although I agree with the proposed shift from warning to comment and hope the IESG approves it, I think
that there is a significant issue with the text of the message which would be helpful to address, whatever
the IESG decides on warning-vs.-comment.

While the first sentence is clear that this is only a potential problem (i.e. that such matetial might be present),
the rest of the message is wriiten as if it is certain that such material does exist.  Suggest replacing the first
sentence by the following two:

The document seems not to have a disclaimer for pre-RFC5378 work, but might.
have content which was first submitted before 10 November 2008.  In the event
that such content actually exists, there are two approaches that might be followed:

On Thu, Apr 16, 2020 at 8:54 AM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Henrik:

Sue

-----Original Message-----
From: WGChairs [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Henrik Levkowetz
Sent: Thursday, April 16, 2020 8:25 AM
To: John Scudder
Cc: WG Chairs
Subject: Re: Idnits is strangely picky about BCP 78 language

Hi John,

> warnings are suppressed?).

Yes, for submission purposes, idnits runs only the appropriate checks from 1id-guidelines, and not at all the RFC publication checks in https://www.ietf.org/id-info/checklist<https://urldefense.com/v3/__https://www.ietf.org/id-info/checklist__;!!NEt6yMaO-gk!T5219WUKRJ_WYHE5rOaWimLUPjcJBDyVZE5iNzodajTcIoTOTOXCeIa-qncUmQ$>.  (It uses the --submitcheck switch).

> But when I run it later
> (https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-iet<https://urldefense.com/v3/__https://tools.ietf.org/idnits?url=https:**Atools.ietf.org*id*draft-iet__;Ly8vLw!!NEt6yMaO-gk!T5219WUKRJ_WYHE5rOaWimLUPjcJBDyVZE5iNzodajTcIoTOTOXCeIauer8WkQ$>
>      https://trustee.ietf.org/license-info<https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!T5219WUKRJ_WYHE5rOaWimLUPjcJBDyVZE5iNzodajTcIoTOTOXCeIa3uAa0ZA$> for more information.)
>

Best regards,

        Henrik