Re: [Icar] A modest proposal for moving forward with ICAR

["Spencer Dawkins" <spencer at mcsr-labs.org>]

> While, in theory, every draft can be reviewed, reviewing a document 
> that is not ready/meant for review can be a waste of time or even 
> annoying to the WG. Since IETF process assigns special value to -00 
> versions drafts with respect to F2F meeting deadlines, reviewing 
> those would be especially risky.
>
> If all drafts had a "State of this draft" notices or at least 
> "please review" flags, we could select drafts that are ready/meant 
> for external review. Until then, I would suggest at least asking the 
> WG whether they think a review of a given WG draft version would be 
> useful.

I swear that somewhere between me and Alex there's a reasonable idea 
trying to get out...

> From my perspective, I'm late-reviewing documents on the IESG telechat 
agenda for Harald (with the rest of Gen-ART). Almost every telechat, I 
make a suggestion for a document change that, I honestly believe, 
would help implementers, but I'm making it WAY too late in the 
process.

In my favorite recent example, I reviewed the DNSSEC documents, a 
three-doc package that included an introduction (excellent idea!), a 
protocol spec, and a packet format spec.

I'm almost sure that a protocol spec and the packet format spec should 
have the same security considerations section, but these two documents 
didn't (interestingly, all three DID have the same acknowledgements 
section, by value in the introduction and by reference in the other 
two, so it's not like I'm inventing a concept no one ever thought of).

I suggested "do the same thing for security considerations, which 
matters a whole lot more to the Internet than the acknowledgements", 
but I was making a reasonable request for a change to text that had 
been last-called, AD-evaluated, and was being IESG-reviewed as I was 
typing - no reasonable AD would take the suggestion and reset the 
document back to "AD watching" (or worse). So all DNSSEC implementers 
get to read two security considerations sections and decide which one 
is right, if both are right, or if neither are right - from now on.

And I can't imagine that loose security considerations for secure DNS 
is a feature!

So - I was looking for a place to park suggestions like this, a lot 
earlier in the process. We have just about no definition of "becoming 
a WG draft" in our processes, so I was thinking that if we tied a 
review to "becoming a WG draft", that would make sense.

I hear what Alex is saying about making sure that WG 00 drafts don't 
get stalled because someone is waiting for a review. The mechanics I 
see in WGs today are

- somebody writes a draft, and may cycle it more than once,
- the workgroup adopts it as a WG draft, and this seems to be 
something we do most often at/near an IETF meeting,
- the draft gets resubmitted with a new name 
(draft-ietf-WGname-*-00.txt)

What I was thinking was, requesting a review of the individual draft 
before it's submitted as a WG draft, which gives a reviewer just about 
a full IETF meeting cycle (obviously sooner is better, especially if 
the draft is being actively worked between IETF meetings).

And the kind of review I'm thinking about here, is the kind that says 
"what's the relationship between this draft and other drafts? 
published RFCs? will there be IANA considerations? does the draft 
stand on its own? how much background can the editor assume?"

If I got Allman to do this kind of review for my TCP-ish draft, and he 
pointed out all the places I was confused about TCP, that would be a 
bonus - but I think getting an idiot like me to do this kind of review 
for a TCP-ish draft would still be an improvement.

And, obviously, I'm not thinking this is gating for a WG to have a 00 
draft, and obviously, I'm not thinking the reviewer is any kind of 
gatekeeper requiring specific changes. I'm thinking about a 
high-level, optional review...

Others may be solving other problems using other tools, of course :-)

Spencer 



_______________________________________________
Icar mailing list
Icar at ietf.org
https://www1.ietf.org/mailman/listinfo/icar