Subject: [Tools-discuss] Idnits version with downref checking

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 27 Jan 2007 00:09:57 +0100

Hi,

I now have a beta version of idnits with downref checking.  It would
be good if you could find the time to give it a spin and let me know
what you think about the approach.

If you care to do so, you can fetch a copy for testing here:
http://tools.ietf.org/tools/idnits/idnits-v2.00.0b

Regards,

	Henrik

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 30 Jan 2007 22:03:30 +0100

Hi,

  I've had no comments on the beta version of idnits I refer to below.
Since I plan to release it tomorrow evening (as a new version is needed
for the 1 February change of required boilerplate anyhow) I'd love to
have feedback soon.

I understand that for some, it would be much easier to provide comments
if this new version was available through a web interface; accordingly
I've set one up:

  http://tools.ietf.org/tools/idnits/webservice-2.00

As said, feedback would be much appreciated.

Regards,

	Henrik

---

From: Lars Eggert <[email-masked]>
Date: Wed, 31 Jan 2007 10:18:44 +0200

Hi,

> As said, feedback would be much appreciated.

this is a great addition! However, I found some nits:

	draft-ietf-ccamp-rsvp-restart-ext-08.txt:
	    Checking references for intended status: Proposed Standard.
	  - Downref: Best Current Practice Normative Reference: RFC 2119 (ref.
	    'RFC2119')
	  - Downref: Best Current Practice Normative Reference: RFC 2434 (ref.	
	    'RFC2434')

It is not a DOWNREF for standards track docs to normatively cite  
BCPs. RFC2026 says:

    A BCP document is subject to the same basic set of procedures as
    standards track documents and thus is a vehicle by which the IETF
    community can define and ratify the community's best current  
thinking
    on a statement of principle or on what is believed to be the best  
way
    to perform some operations or IETF process function.

And RFC 3967 implies that BCPs are similar to standards track documents:

    For Standards Track or BCP documents requiring normative  
reference to
    documents of lower maturity, the normal IETF Last Call procedure  
will
    be issued, with the need for the downward reference explicitly
    documented in the Last Call itself.

Hence, the current practice is that normative references _from_ BCPs  
to Informationals and Experimentals are DOWNREFs, normative  
references _to_ standards track docs are OK, and references _from_  
standards track _to_ BCPs are also OK.

	draft-ietf-pim-mib-v2-09.txt:
	  Experimental warnings:
	  - No Intended status indicated for this document; assuming  
Informational

This is a PS and there is a DOWNREF, but I understand that the tool  
can't know the status, because it's not in the document. Still, I'd  
be good to explicitly call out that DOWNREFs won't be identified,  
maybe with: "No Intended status indicated for this document; DOWNREF  
check disabled".

(It may also be good to yell about the "Intended status" missing  
somewhat louder, but I had mentioned this before.)

	draft-ietf-tsvwg-tcp-mib-extension-14.txt:
	  Experimental warnings:
	  - Obsolete Normative Reference: RFC 2021 (ref. 'RFC2021')

Nice! Bill's web tool didn't catch these.

Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jan 2007 11:38:23 +0100

>   http://tools.ietf.org/tools/idnits/webservice-2.00

Thanks. I ran it on draft-ietf-shim6-proto-07.txt
(after manually inserting Intended Status: Standards Track).

   * Downref: Best Current Practice Normative Reference: RFC 2119 (ref. '1')

BCPs are not downrefs.

   - Downref: Non-RFC Normative Reference: [5]
   - Downref: Non-RFC Normative Reference: [8]
   - Downref: Non-RFC Normative Reference: [9]

The first one is an RFC so this seems to be a failure in the
heuristic. The citation is

    [5]  Conta, A. and S. Deering, "Internet Control Message Protocol
         (ICMPv6) for the Internet Protocol Version 6 (IPv6)
         Specification", RFC 2463, December 1998.

The second two are I-D's - so whether they are actually downrefs
depends on their intended status. I'd say that a normative reference
to an I-D should probably be tagged as "Possible downref".

Great improvement, though.

     Brian

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 31 Jan 2007 12:46:21 +0100

Hi Lars,

Thanks for the feedback!  More inline:

> 	  - Downref: Best Current Practice Normative Reference: RFC 2434 (ref.	

Yes, these are one of the points where I had to make a choice, and I
started out restrictive.  Exactly what is a downref from which document
class is table driven, however; so trivial to adjust.

>     community can define and ratify the community's best current thinking
>     on a statement of principle or on what is believed to be the best way

Ok, I didn't read this when preparing, but can't honestly say that it's
plain that BCPs can be normatively referenced by PS, DS, S.

>     For Standards Track or BCP documents requiring normative reference to
>     documents of lower maturity, the normal IETF Last Call procedure will

This I read, and also here can't really say that I found it plainly clear
whether to permit normative BCP reference from PS, DS, S.

> standards track _to_ BCPs are also OK.

This is good to know; I've updated the tables so that

S  may reference S, BCP
DS may reference S, DS, BCP
PS may reference S, DS, PS, BCP

> maybe with: "No Intended status indicated for this document; DOWNREF  

Well, I can disable downref check, but that is currently not the same
as checking a document as Informational.  I currently call out normative
references to historic for Informationals, as well as any reference to
Obsoleted.  I could also check it as PS, if that would be more useful?

Also helpful in cases such as this could be to add a switch by which you
can indicate the intended status for a document on the command line, in
case none is given in the document or the indication in the document is
incomplete or incorrect.  I've started this work.

(By 'incomplete' I mean the case where the document says 'Standards track'.
I currently process this as PS, but can't really know if it's PS, DS or
S ...)

> somewhat louder, but I had mentioned this before.)

I could make it an error, but what's currently said in ID-Guidelines
doesn't seem to warrant more than a warning.

> Nice! Bill's web tool didn't catch these.

I'm sure he'll fix that soon :-)

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 31 Jan 2007 12:51:14 +0100

Hi Brian,

Thanks for the comments!  More inline:

>    * Downref: Best Current Practice Normative Reference: RFC 2119 (ref. '1')

Right, also clarified by Lars.  I'm changing the tables as indicated in
my reply to Lars:

S  may reference S, BCP

>          Specification", RFC 2463, December 1998.

Oops!  I'll check what's up with this one.  Good catch.

> to an I-D should probably be tagged as "Possible downref".

Ok.  I'll add some tests to identify drafts separately from other non-
RFC references.

> Great improvement, though.

Good :-)

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 31 Jan 2007 16:35:29 +0100

>   http://tools.ietf.org/tools/idnits/webservice-2.00

Thanks, works for me.  Are you sure that you want the new
boilerplates even if "2006" is selected ?

No new observation, some folks prefer a truncated 2119-
boilerplate defining only those keywords actually used
later in their text.  Or that's what they hope, but it
is easy to forget a definition.   If most authors use
the full 2119 boilerplate please ignore this minor nit,
it's not related to changes in the new version.

Another point not related to the new version:  idnits
claims that nntp.uri.arpa is a possible FQDN.  Does it
make sense to ignore anything.uri.arpa ?

If I use a file name not matching the document name
idnits 1.124 notes this as error, but then it doesn't
mention the offending nntp.uri.arpa anymore, is that
as it should be ?  Ditto with idnits 2.00.

Probably okay:  The document intends to obsolete 1738,
and idnits states that RFC 1738 is already obsoleted.

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 31 Jan 2007 18:34:34 +0100

Hi Frank,

Thanks for the feedback!  More in-line:

> boilerplates even if "2006" is selected ?

I think so -- the year option is there to handle the
transition time around new year; I wouldn't like to
couple it with the boilerplate choice, really.

> it's not related to changes in the new version.

Ok

> make sense to ignore anything.uri.arpa ?

Yes, good point.  And also .urn.arpa and .in-addr.arpa,
I think.

> as it should be ?  Ditto with idnits 2.00.

Urgl?!?  That definitely sounds like a bug.  I'll look into
it.

> and idnits states that RFC 1738 is already obsoleted.

4248 and 4266 both indicate in the header that they
obsolete 1738, and the rfc-editor's database also has
this information, but looking at the text of 4248 I
think that the information is probably incorrect - both
4248 and 4266 seems to update parts of 1738, rather than
obsoleting it.  I have no idea what the authors/rfc-editor
were thinking at the time, but the information used by
idnits here is derived from the rfc-editor's data base,
so if a correction is needed (which seems to be the case,
to me...) that's where it should happen.

Regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 31 Jan 2007 18:45:02 +0100

> Hi Frank,
...

> Urgl?!?  That definitely sounds like a bug.  I'll look into

I can't reproduce that here.  Could you send me the file
with the mismatching name?

	Henrik