Re: [Icar] Thoughts on ICAR direction

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

> Hi All,
>
> (Writing just as an interested participant...)
>
> I've been watching the evolution of ICAR, and it seems like we 
> aren't succeeding in building a centralized structure for early 
> review.  I think that there are a number of reasons for this, the 
> most pertinent of which (IMO) is that a WG is not the right vehicle 
> to develop and manage a program.

I could not, of course, agree more with this statement. I think I know 
the reasons, but they are off-topic for ICAR.

> So, I have some ideas for directions that ICAR could take that don't 
> involve building a centralized review infrastructure, so they might 
> be more suitable to
>
> (1) Document cross-area review criteria.  This would help to educate 
> authors and ad hoc early reviewers in what to look for.

Somewhere between ICAR, NEWTRK/ISD, and Gen-ART there's an idea trying 
to get out - please be patient while I try to explain this...

As a Gen-ART reviewer, I'm finding protocols and enhancements that are 
split across multiple documents that really don't hang together in a 
way that makes sense. Most recently, I was asked to review a protocol 
specification and an associated packet format specification - 
together, these documents define ONE protocol, but both documents had 
independent security sections, and these sections were different. 
Imagine the excitement of an implementor trying to figure out if one, 
or the other, or both, or neither are right in ten years.

It's really not fair to point stuff like this out on the Tuesday 
before a document is on an IESG telechat agenda, but when/where SHOULD 
we point it out?

> (2) Develop a process for WG chairs to use existing area review 
> resources (MIB Doctors, GEN-ART, Security directorate, Ops 
> directorate, etc.) to get early review for their documents?  Maybe 
> this could be a proposed "July 14" experiment?

In all fairness, ICAR was chartered pre-July14, so the only "legal" 
way forward was to develop a full BCP before implementing the BCP 
procedures to find out if they actually work! July14 - now approved as 
BCP 93, RFC 3933 <draft-klensin-process-july14-02.txt>, and coming 
soon to an RFC mirror near you - has as its goal gathering 
experimental experience with process changes before publishing the 
usual BCP document - and specifically calls out opportunities for 
trials in one or two corners of the IETF, rather than mandating 
deployment to the entire IETF community at once, as a normal BCP 
document would do. So, I agree completely.

> Thoughts? 



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