Re: ion-procdocs open for public comment

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf