Re: ion-procdocs open for public comment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Again, thanks for doing this work...

Spencer


On 2007-01-29 18:08, Spencer Dawkins wrote:
I should begin by thanking Brian for producing this document, both originally and in ION format.

I'm having a hard time understanding what lookup mechanisms are less 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 ;-)

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

(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?

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

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.

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 :-)

"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

And that's a good thing.

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.

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.

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


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]