Subject: Re: Please review updated 1id-guidelines

From: Bruce Lilly <[email-masked]>
Date: Thu, 3 Mar 2005 10:54:28 -0500

>  Date: 2005-03-02 16:37
>  From: Alia Atlas <[email-masked]>

> One thing that I would have found very useful when I first starting writing 
> drafts would be a pointer to tools to actually format documents 
> appropriately.

Me too.  RFC 2223 helped a little, but it is rather vague and
incomplete.

> This could be a pointer to the xml2rfc information (with  
> associated RFC),

I looked at those, but found XML to be less of a tool than a
barricade.

> to tools for nroff, etc.,

Finding RFC 2223 insufficient, I wrote a set of macros and related
tools.  See draft-lilly-using-troff and related discussions on
the RFC-interest mailing list (
http://www.rfc-editor.org/pipermail/rfc-interest/
).

> With the exception of an informative reference to RFC 2629, I'm not sure 
> this is something that can be in the guidelines, but it could certainly be 
> on the web-page.

That would depend on the status of the document.  If it's to become
an RFC, then references to drafts can be only as a "work in progress"
and references to web sites other than IETF/IANA/RFC-EDITOR are
strongly discouraged.  If it's just another random document, anything
goes. 

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

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 3 Mar 2005 11:57:14 -0500

>  Date: 2005-03-03 06:08
>  From: Brian E Carpenter <[email-masked]>

[some rearrangment of text]
> > Rationale for BCP:
> > 1. I suspect we want the procedures to be readily visible to potential
> >    authors
> 
> Yes, and right there behind the "Internet Drafts" link on www.ietf.org
> meets that.
> 
> >  nor
> >> is it necessarily easy to find (*which* web site(s)?). 
> 
> See above.

The problem is that 1id-guidelines appears many places; there is one
version (and, yes, I mean the content of the various documents
differs; these are not merely mirrors) on the ISI.EDU ftp site in the
in-notes directory (where the RFCs live), another on the ftp.ietf.org
site in the ietf directory (as referenced by the RFC-Editor's web
site), and then there's the version at http://www.ietf.org/ietf (which
might actually be the same file as on the ftp site, but the only way
to tell for sure would be to download and compare both).

My first inclination when preparing to write my first draft was to
read RFC 2223 and to go to the RFC-Editor web site (rather than the
IETF site) [I also looked at RFC 2639 and investigated that path, but
found it unproductive].  So "hiding" a document behind some web site
that a potential author might not think to visit lacks the same sort
of visibility that an RFC (BCP or otherwise) has.

RFCs also lack the versioning problem that afflicts 1id-guidelines:
RFCs are widely mirrored w/o differences in versions (other than
what might be attributable to failures such as the disk crash that
wiped out many of the RFCs on the ISI.EDU repository).

> > 3. The suggested IANA Considerations section implies some sort of RFC
> 
> Certainly, there's no doubt that the guidelines need to refer to
> BCP RFCs when approriate.

In this case. I'm not referring to a published BCP, but rather to
IANA action that I believe should be taken w.r.t. drafts when IANA
makes a registry entry based on a draft.  This has happened a number
of times. In addition to the case which prompted my rant archived at
http://www.imc.org/ietf-msgtrk/mail-archive/msg00250.html (among
other places), there is a repeated instance of the problem:
consider the registry of Message Disposition Notification
disposition modifiers registered at
http://www.iana.org/assignments/mdn/disp-mod/index.html
and modified just this week.  The last entry gives a text pointer
reading "RFC-ietf-ediint-as2-20.txt" and a corresponding link URI
of http://www.rfc-editor.org/rfc/rfcxxxx.txt
There is of course no resource that that URI purports to point to:
attempting to follow the link leads to a 404 error.  Nor is there
a document named "RFC-ietf-ediint-as2-20.txt".  Now one might
assume (with all of the consequent dangers associated with making
an assumption) that somewhere there might be a draft with a name
somewhat similar to "RFC-ietf-ediint-as2-20.txt"... and one might
hope that that document might provide some insight regarding what
has been registered.  [in this case, it does not; it leads to
confusion because the "warning" modifier was already standardized
in RFC 2298, with specific defined semantics -- it is unclear
whether the draft draft-ietf-ediint-as2-20.txt -- if in fact that
is what IANA used -- seeks to change the semantics associated with
the RFC 2298 definition.]

Why, oh why can't IANA use the proper document file name and
provide a working link instead of making up a bogus name that
has never existed and which will never exist, along with a link
to a non-existent resource?

> >>Asking for community input, and posting the resulting 
> >>text on the web site, seems to give that flexibility.
> > 
> > 
> > Perhaps, but it is not clear that the document has any standing,
> 
> I suspect that the fact that the IESG minutes its approval of
> an update would serve.

If somebody who stumbles across the document goes searching for
IESG minutes (why would he?), and actually finds something...
 
> > Would IANA
> > take note of direction given in some random (non-RFC) document?
> 
> If we ask them to.

Shall we find out?  Could the IESG please request IANA to provide
some sensible solution to the bogus reference problem illustrated
above.

> > If there's another sort of official document for administrative
> > procedures and guidelines, that might work; are there?  If so, where
> > does one find them?
> 
> Good question. We may need to formalize that... that operational
> procedures, after consensus discussion and IESG approval, are
> effective as soon as posted at www.ietf.org.

I suspect that more would be required, e.g. a formal repository
of such documents, with an official series name and numbering
method.  In which case it shares those characteristics with
RFCs (including those that are also BCP, STD or FYI documents).
So why not simply use the existing RFC process (putting aside
quibbling about Informational, BCP, FYI for the moment)?

> > It's not clear what sort of flexibility would be lacking in a BCP
> > RFC, given that guidelines can be expressed in RFC 2119 terms "MAY",
> > "OPTIONAL", "RECOMMENDED", "SHOULD", and even "MUST" where
> > appropriate, and that BCPs can be (and are) updated when necessary.
> 
> But it takes 6 months to a year to do so.

If it's Standards Track, an RFC can't advance to Draft in less
than 6 months, nor from Draft to full Standard in less than
4 months (RFC 2026).  Outside of the Standards Track, a change
would require publication of a draft and a Last Call; if the
draft is published by/for the IESG rather than by a mere peon,
the Last Call duration is two weeks, after which the IESG makes
a decision and the RFC (Informational, Experimental, or BCP) is
published.  If a BCP, it goes into effect with full force of a
Standard at that time.

> > What sort of flexibility did you have in mind?
> 
> 2 week reaction time when we find a need for operational changes.

That could be said of any registration procedure (typically issued
as BCP) or for that matter of any protocol.  Is that really likely
regarding this document?  As far as I can tell, if an urgent change
in a BCP is needed, it could be accomplished in as little as 2 weeks
(the Last Call period).

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Mar 2005 12:25:17 -0500

Bruce,

This is, IMO, part of the "standing procedural document"
problem, with variations for degrees of authority.  The basic
problems are that 

	* the RFC publication process is too slow to deal with
	procedural changes and not really designed for it (as
	distinct from networking documents of various sorts), and
	
	* using the "BCP" designation for these documents is
	confusing to all concerned.

Because of those issues, there is no obvious place to put and
track the documents, so copies get lost or desynchronized.

There is a placeholder proposal in front of NEWTRK, paralleling
the "ISD" proposal, that would actually create a document series
for these things, separate from BCPs and probably from RFCs.
It isn't obviously a NEWTRK work item, but was prepared to
export a loose end from the ISD draft.   Unless the idea crashes
and burns in informal discussions next week, I expect that the
NEWTRK Chair and the relevant AD will, sometime thereafter, make
a decision about whether and how it should be developed and
carried forward.

I'd encourage you (and others concerned about this) to have a
look at the document and comment as appropriate to the NEWTRK
list.  The current draft is draft-ietf-newtrk-sd-00.txt.

Let's try to figure out a way to move forward, rather than just
identifying a collection of problems and pointing them out.

regards,
   john

--On Thursday, 03 March, 2005 11:57 -0500 Bruce Lilly
<[email-masked]> wrote:

> 
> The problem is that 1id-guidelines appears many places; there
> is one version (and, yes, I mean the content of the various
> documents differs; these are not merely mirrors) on the
> ISI.EDU ftp site in the in-notes directory (where the RFCs
> live), another on the ftp.ietf.org site in the ietf directory
> (as referenced by the RFC-Editor's web site), and then there's
> the version at http://www.ietf.org/ietf (which might actually
> be the same file as on the ftp site, but the only way to tell
> for sure would be to download and compare both).
> 
> My first inclination when preparing to write my first draft
> was to read RFC 2223 and to go to the RFC-Editor web site
> (rather than the IETF site) [I also looked at RFC 2639 and
> investigated that path, but

---

From: Alia Atlas <[email-masked]>
Date: Thu, 03 Mar 2005 13:38:38 -0500

>Me too.  RFC 2223 helped a little, but it is rather vague and

I never even found RFC 2223.  I saw the guidelines on the IETF web-site 
instead.

>I looked at those, but found XML to be less of a tool than a

Which is a clear indication that authors have different approaches & 
opinions.   I'd been using nroff for a while, with some fix-up scripts that 
I'd been given.  I found the XML tools to be very useful (builds tables of 
contents, prevents figures from being broken between pages, etc.).  There 
was a brief learning curve.

>http://www.rfc-editor.org/pipermail/rfc-interest/

Maybe this could be pointed to as well?

>strongly discouraged.  If it's just another random document, anything

There's got to be a reasonable way to say "this tool is (as of pub date) 
easily available on the web by the name of xml2rfc".  Also, doesn't the RFC 
Editor use it as well?

Alia

---

From: Doug Barton <[email-masked]>
Date: Tue, 08 Mar 2005 22:17:56 -0600

Bruce Lilly wrote:

> In this case. I'm not referring to a published BCP, but rather to IANA
> action that I believe should be taken w.r.t. drafts when IANA makes a
> registry entry based on a draft.  This has happened a number of times. In
> addition to the case which prompted my rant archived at 
> http://www.imc.org/ietf-msgtrk/mail-archive/msg00250.html

Bruce,

I read the post you referenced above, as well as the followups from Ned and
Scott, and I have nothing to add to their explanations. I think that they
have accurately described the situation at hand.

> (among other places), there is a repeated instance of the problem: 
> consider the registry of Message Disposition Notification disposition
> modifiers registered at 
> http://www.iana.org/assignments/mdn/disp-mod/index.html and modified just
> this week.  The last entry gives a text pointer reading
> "RFC-ietf-ediint-as2-20.txt" and a corresponding link URI of
> http://www.rfc-editor.org/rfc/rfcxxxx.txt There is of course no resource
> that that URI purports to point to: attempting to follow the link leads
> to a 404 error.  Nor is there a document named
> "RFC-ietf-ediint-as2-20.txt". 

As has been explained to you, those references are simply placeholders that 
will be replaced with the real RFC reference when it's published by the RFC 
Editor. That said, the IANA staff is always interested in improving its 
service to the community, so if you have suggestions as to how those types 
of references can be improved, we are happy to listen to them. Such 
suggestions could be discussed here if the community agrees it's 
appropriate, or sent to [email-masked] at any time.

Regards,

Doug

-- 
Doug Barton
General Manager, The Internet Assigned Numbers Authority