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