Subject: Re: ion-procdocs open for public comment

From: Spencer Dawkins <[email-masked]>
Date: Mon, 29 Jan 2007 11:08:07 -0600

I should begin by thanking Brian for producing this document, both 
originally and in ION format.

> An ION (IETF Operational Note, see RFC 4693) is open for public comment
> on the [email-masked] list. Comments should be sent by 2007-02-12.
>
> Please see
> http://www.ietf.org/IESG/content/ions/drafts/ion-procdocs.html

I'll limit my comments to a "huh?" and a "grrr"...

"Huh?" - this document refers to IETF BCPs by RFC number, not by BCP number. 
The text says "Most of the cited RFCs are BCPs. RFC numbers have been used 
rather than BCP numbers, for convenient lookup."

I'm having a hard time understanding what lookup mechanisms are less 
convenient for BCPs than for RFCs (the RFC Editor search engine at 
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl returns BCP numbers and STD 
numbers along with RFC numbers when you search for text, and returns BCP 
numbers when you search by number and click the selector for "BCP"), but the 
more serious concern is that RFC 2026 (for instance) is NOT the complete 
standards process  in any meaningful way, since it has been updated 5 times 
so far (according to the RFC Editor search engine).

The IETF website has just updated pages that said "2026 = standards process" 
to say something like "2026 as updated = standards process" 
(http://www.ietf.org/IETF-Standards-Process.html on the main IETF web page 
used to be a direct link to 2026, but it's not any more.). Going back to 
"RFC 2026" in IONs is a step backward.

I don't know why the updates are not also part of BCP 9, but they should be. 
One Might Think. I'd rather fix that, than start training people to ignore 
the updates AGAIN...

"Grrr" - One Might Think that Newtrk is still active, from reading Section 
2.2, "The newtrk WG was chartered to revise the standards track - multiple 
proposals have been floated, but no conclusions have been reached", but it 
has concluded. From what I can tell, draft ION correctly identifies missing 
documents that might usefully exist, but does not give any clue that parts 
of RFC 2026 are just flat-out ignored (see: RFC 2026, section 6.2, 
describing the periodic review of proposed standards and draft standards 
that we don't do).

I don't know why we would publish this ION ("Informal Guidance") without 
saying this. There are things in 2026 that we have argued about whether we 
do or not, but no one thinks we have ever done these reviews.

Thanks,

Spencer 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jan 2007 09:14:26 +0100

On 2007-01-29 18:08, Spencer Dawkins wrote:
> "Huh?" - this document refers to IETF BCPs by RFC number, not by BCP 
> number. The text says "Most of the cited RFCs are BCPs. RFC numbers have 
> been used rather than BCP numbers, for convenient lookup."
> 
> convenient for BCPs than for RFCs 

My assumption, maybe false, is that a lot of people have RFC mirrors and
relatively few have BCP mirrors. Also, my xml2rfc skills don't extend to
knowing whether I can directly cite BCPs in xml2rfc and get pointers
to the BCP and not the RFC. I'm willing to be educated on that point ;-)

> (the RFC Editor search engine at 
> http://www.rfc-editor.org/cgi-bin/rfcsearch.pl returns BCP numbers and 
> STD numbers along with RFC numbers when you search for text, and returns 
> BCP numbers when you search by number and click the selector for "BCP"), 
> but the more serious concern is that RFC 2026 (for instance) is NOT the 
> complete standards process  in anFrom [email-masked] Tue Jan 30 03:22:40 2007
Date: Tue, 30 Jan 2007 09:14:26 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Spencer Dawkins <[email-masked]>
Cc: [email-masked]
Subject: Re: ion-procdocs open for public comment

On 2007-01-29 18:08, Spencer Dawkins wrote:
> "Huh?" - this document refers to IETF BCPs by RFC number, not by BCP 
> number. The text says "Most of the cited RFCs are BCPs. RFC numbers have 
> been used rather than BCP numbers, for convenient lookup."
> 
> convenient for BCPs than for RFCs 

My assumption, maybe false, is that a lot of people have RFC mirrors and
relatively few have BCP mirrors. Also, my xml2rfc skills don't extend to
knowing whether I can directly cite BCPs in xml2rfc and get pointers
to the BCP and not the RFC. I'm willing to be educated on that point ;-)

> (the RFC Editor search engine at 
> http://www.rfc-editor.org/cgi-bin/rfcsearch.pl returns BCP numbers and 
> STD numbers along with RFC numbers when you search for text, and returns 
> BCP numbers when you search by number and click the selector for "BCP"), 
> but the more serious concern is that RFC 2026 (for instance) is NOT the 
> complete standards process  in any meaningful way, since it has been 
> updated 5 times so far (according to the RFC Editor search engine).
> 
> The IETF website has just updated pages that said "2026 = standards 
> process" to say something like "2026 as updated = standards process" 
> (http://www.ietf.org/IETF-Standards-Process.html on the main IETF web 
> page used to be a direct link to 2026, but it's not any more.). Going 
> back to "RFC 2026" in IONs is a step backward.

Be specific. Which RFCs that update 2026 are not cited?
> 
> I don't know why the updates are not also part of BCP 9, but they should 
> be. One Might Think. I'd rather fix that, than start training people to 
> ignore the updates AGAIN...

If they were approved as formal updates, that is logged in the RFC Index.
If they weren't approved as formal updates, then they have to be regarded
as stand-alones.
> 
> "Grrr" - One Might Think that Newtrk is still active, from reading 
> Section 2.2, "The newtrk WG was chartered to revise the standards track 
> - multiple proposals have been floated, but no conclusions have been 
> reached", but it has concluded.

Yes, I need to fix that text.

> From what I can tell, draft ION 
> correctly identifies missing documents that might usefully exist, but 
> does not give any clue that parts of RFC 2026 are just flat-out ignored 
> (see: RFC 2026, section 6.2, describing the periodic review of proposed 
> standards and draft standards that we don't do).

My own expostulations on that topic are at
http://tools.ietf.org/id/draft-carpenter-rfc2026-critique

> saying this. There are things in 2026 that we have argued about whether 
> we do or not, but no one thinks we have ever done these reviews.

But an ION isn't supposed to change any rules, so I don't think it
should even say that certain rules are not followed.

    Brian

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 30 Jan 2007 06:59:29 -0600

Again, thanks for doing this work...

Spencer

> to the BCP and not the RFC. I'm willing to be educated on that point ;-)

Brian, you may be right on both of these points, but they are both problems, 
and they are bigger problems if they are also problems when citing STDs, 
whuch aren't one-to-one with RFCs, either. If we really can't use these 
document series in an effective way, that's a problem, if it's more 
convenient to mis-cite standards and BCPs than to cite them in a way that 
survives updates...

> Be specific. Which RFCs that update 2026 are not cited?

(See next item - I think you may be asking what is not cited in the ION - 
that's not what I'm talking about)

> If they weren't approved as formal updates, then they have to be regarded

What I'm talking about is that if you type in BCP 9 in the RFC Editor search 
engine, the only RFC that pops up as part of BCP 9 is 2026, but the RFC 
Index says "Updated by RFC3667, RFC3668, RFC3932, RFC3979, RFC3978".

It seems to me that it would be reasonable if typing in BCP 9 popped up all 
six RFCs that now contain part of the BCP 9 text. Perhaps this is excessive, 
except that it invites people to continue to cite BCP 9 as RFC 2026, without 
the annoying subtlties of updated IPR policies, etc. This is not a problem 
for process hacks, but we might also accommodate people who are trying to do 
real work in the IETF :-)

>> Section 2.2, "The newtrk WG was chartered to revise the standards track - 
>> multiple proposals have been floated, but no conclusions have been 
>> From what I can tell, draft ION correctly identifies missing documents 
>> that might usefully exist, but does not give any clue that parts of RFC 
>> 2026 are just flat-out ignored (see: RFC 2026, section 6.2, describing 
>> the periodic review of proposed standards and draft standards that we 
>> don't do).
>

And that's a good thing.

> should even say that certain rules are not followed.

OK, IONs are experiments (RFC 4693 is experimental). The current description 
says

   Procedurally, an ION has the formal authority of a statement from its
   approving body.  This means that an ION cannot change those
   procedures of the IETF that are documented via the BCP series, since
   the BCP series represents a determination of IETF consensus.

So I can see why you would say what you're saying.

On the other hand, this ION is an "Informal Guide". If you think it's better 
to say "we wouldn't dream of changing BCP procedures in an ION, but we do 
note that as of <date> this procedure hasn' been followed since it was 
oriiginally described in RFC 1310, there are no known plans to follow it, 
there has never been an appeal because we don't follow it, and there has 
never been an AD recall petition because we don't follow it", that seems 
like something I'd hope a guide would tell me.

Could you ping the rest of the IESG and see whether this reasoning seems 
flawed? If it does, I'd be willing to provide an update to RFC 4639 that 
allows us to recognize procedures that  are still documented in BCP text but 
are not being followed.

Thanks,

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jan 2007 15:21:08 +0100

On 2007-01-30 13:59, Spencer Dawkins wrote:

<snip>

> 
> What I'm talking about is that if you type in BCP 9 in the RFC Editor 
> search engine, the only RFC that pops up as part of BCP 9 is 2026, but 
> the RFC Index says "Updated by RFC3667, RFC3668, RFC3932, RFC3979, 
> RFC3978".

This is a special case, because those documents are BCP 78, 79 and
92 respectively (i.e. someone decided to give them distinct BCP
numbers). If you look for, e.g., BCP 101 you will get both RFC 4071
and RFC 4371. So, it all depends.

<snip>

> On the other hand, this ION is an "Informal Guide". If you think it's 
> better to say "we wouldn't dream of changing BCP procedures in an ION, 
> but we do note that as of <date> this procedure hasn' been followed 
> since it was oriiginally described in RFC 1310, there are no known plans 
> to follow it, there has never been an appeal because we don't follow it, 
> and there has never been an AD recall petition because we don't follow 
> it", that seems like something I'd hope a guide would tell me.
> 
> flawed? 

Sure, when the comment period expires and I roll up all the comments.

    Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 30 Jan 2007 08:37:22 -0800

> and RFC 4371. So, it all depends.

"someone decided" rather than "the IESG decided" is of course a problem in 
itself.
Is there a procedure for reassigning which BCP an RFC belongs to?
Should we create one?

(BCP 78 and 79 could easily be part of one BCP, btw - but by now, they're 
long enough established by the boilerplate that we probably need to keep 
them where they are)

           Harald

---

From: Ned Freed <[email-masked]>
Date: Tue, 30 Jan 2007 15:35:27 -0800 (PST)

> relatively few have BCP mirrors.

Presumably anybody who mirrors the RFCs will also mirror rfc-index.txt, which
includes the BCP numbers. It's one additional file to look at, but there's no
need to have a BCP mirror to look up documents by BCP number.

> Also, my xml2rfc skills don't extend to

The "bibxml" collection of RFC reference information includes BCP and STD
seriesinfo but AFAIK there is no way to make that appear as the reference
anchor. Short of creating your own references, I think the best you could do is
something like <xref target="RFC2119">BCP 14</xref>, which will get you  "BCP
14 [RFC2119]".

I think this is pretty much a dealbreaker for using BCP numbers as the primary
indicator of a citation.

More generally, I have a problem with normative cituations to BCP and STD
numbers since the underlying document can change. That's arguably OK for an
informational citation, but IMO normative references may have version
dependencies that need to be taken into account.

				Ned

---

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

On 2007-01-31 00:35, Ned Freed wrote:
...
> dependencies that need to be taken into account.

I think that is absolutely correct for technical specs. In the specific case
of the IPR process documents, which Spencer raised, it may well be that
the correct citation should be the latest version. (But not in all cases;
when discussing the copyright status of RFC mumble, the copyright rules
in force at the time of publication may be the correct citation.)

     Brian

---

From: Ned Freed <[email-masked]>
Date: Wed, 31 Jan 2007 07:18:37 -0800 (PST)

> in force at the time of publication may be the correct citation.)

I think we're in complete agreement here: There's no single right answer and
there are several considerations in play, making this something authors have to
think about when they cite some other document.

				Ned

---

From: Brian Carpenter <[email-masked]>
Date: Mon, 29 Jan 2007 11:05:32 -0500

Please see

---

From: Ned Freed <[email-masked]>
Date: Wed, 31 Jan 2007 07:18:37 -0800 (PST)

Ned

---

From: Dave Crocker <[email-masked]>
Date: Wed, 31 Jan 2007 08:12:14 -0800

Ned Freed wrote:
>> the correct citation should be the latest version. 

Indeed, using the BCP or STD number is really a way of providing an automated 
mechanism for resolving the citation "The latest version of ...".

That is even useful for technical specs, but only sometimes.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Wed, 31 Jan 2007 10:17:07 -0600

Dave,

	Interestingly enough, your observation provides the 
strongest argument I've yet seen for assigning a standard
number to any RFC that has becomes a Proposed Standard.

--
Eric

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]] 
> Sent: Wednesday, January 31, 2007 11:12 AM
> To: [email-masked]
> Subject: Re: Referencing BCPs [Re: ion-procdocs open for 
> public comment]
> 
> Ned Freed wrote:

---

From: Dave Crocker <[email-masked]>
Date: Wed, 31 Jan 2007 08:44:45 -0800

> number to any RFC that has becomes a Proposed Standard.

Well, it's a double-edged capability.  All of the concerns about citing "the 
latest version" rather than a specific version are entirely warranted...

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Wed, 31 Jan 2007 11:50:09 -0500

--On Wednesday, 31 January, 2007 10:17 -0600 "Eric Gray

> number to any RFC that has becomes a Proposed Standard.

Anyone who wants to do so -- and is still a hopeless optimist
about being able to get such changes through the system -- is
welcome to pick up and revise draft-ietf-newtrk-docid-00.txt or
to convince me to reissue it as a personal draft.  If someone
else wants to pursue it, I'd be happy to supply the XML source.

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 31 Jan 2007 11:54:26 -0500

--On Wednesday, 31 January, 2007 11:50 +0100 Brian E Carpenter
<[email-masked]> wrote:

>> More generally, I have a problem with normative cituations to
>> BCP and STD numbers since the underlying document can change.
>> That's arguably OK for an informational citation, but IMO
>> normative references may have version dependencies that need
>> to be taken into account.
> 

Brian,

Except for the fact that the material being cited contains the
specifics of license and IPR releases, and promises to abide by
certain rules, by the authors.  Authors can't reasonably be
asked to agree to something that might be published under the
BCP number in the indefinite future, so you are either stuck
with a document (RFC) number or a BCP as of a specific date,
which amounts to the same thing and is harder to track down.

    john

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 31 Jan 2007 17:02:16 +0000

On Wed, 31 Jan 2007 11:54:26 -0500

> which amounts to the same thing and is harder to track down.

I'll let Jorge correct me if I'm wrong, but referencing by
<number,date> is the norm in the legal world, since statutes do get
amended without necessarily being renumbered.

I do agree we want to make it easy for non-lawyers.  I've suggested a
date-stamped archive of each version of each such document, for
precisely that reason. 

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 31 Jan 2007 18:18:14 +0100

Dave Crocker writes:
>>       Interestingly enough, your observation provides the strongest 
>>       argument I've yet seen for assigning a standard number to any 
>>       RFC that has becomes a Proposed Standard.
>
> Well, it's a double-edged capability.  All of the concerns about 
> citing "the latest version" rather than a specific version are 
> entirely warranted...

We have STD numbers already. There's only one catch: The internet runs 
on proposed standards, not STDs.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Wed, 31 Jan 2007 12:47:34 -0500

--On Wednesday, 31 January, 2007 17:02 +0000 "Steven M.
Bellovin" <[email-masked]> wrote:

>> specifics of license and IPR releases, and promises to abide
>> by certain rules, by the authors.  Authors can't reasonably be
> <number,date> is the norm in the legal world, since statutes
> do get amended without necessarily being renumbered.

I believe that is correct.  The problem here is that, as a
consequence of that referencing system, they have taken measures
to be sure that the version corresponding to the reference is
readily available.  We don't do that: finding out what was
actually BCP NNN on some particular date requires both skill and
out of band knowledge.

> I do agree we want to make it easy for non-lawyers.  I've
> suggested a date-stamped archive of each version of each such
> document, for precisely that reason. 

That, of course, would do that job and eliminate all of my
objections.  But it does mean that, for many purposes, we can't
use a reference to "BCP nnnn", it must be a reference to "BCP
nnnn as of yyyymmdd" or its equivalent.

      john