Subject: Re: Issue 3 (Re: [INDEP] Forward with independent

From: Allison Mankin <[email-masked]>
Date: Tue, 01 Aug 2006 09:28:44 -0700

Gee, nobody wants to publish documents that are harmful to
the Internet, but there can be disagreements about the
amount of review needed and the sense of how a specification 
might cause harm.

The IESG is the IETF's designated final review arm and it 
treats specifications as being available for any environment
and as needing multiple cross-area reviews for potential
harm to the Internet (as well as other cross-area issues).  
I believe currently independent protocols do not
get multiple cross-area reviews of this sort, though I 
might be wrong.  There is not a statement and the reviews
are not public.

The IESG no longer reviews RFC Editor independent submissions
for content, which is correct for the independents.   However, 
they do have to read them for conflicts.  In the not too
distant past, it was a not surprising example when
an independent protocol went by with a plaintext password
because it was "for the LAN" and documented the existing
protocol.  

I don't know if there is now security review on every
independent document (versus a security reviewer only for
security-specific documents).  But anyway security issues
(and others) that could harm the Internet in independent
protocols can go by inadvertantly if the reviews are not
cross-area, at least in my experience...

Allison

_______________________________________________
INDEPENDENT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/independent

---

From: Keith Moore <[email-masked]>
Date: Tue, 1 Aug 2006 15:30:54 -0400

> amount of review needed and the sense of how a specification 

There can also be confusion if a reader believes that a document in the
RFC series has been through one review process when it has actually
been through a substantially different review process.  Right now we
appear to have have different review processes for Informational and
Experimental RFCs depending on whether they've been produced by IETF
(either via a WG or as individual submissions) or as independent
submissions to the RFC Editor. 

I won't assume a priori that say IETF's review process (consisting of
AD writeup, IESG review, last call, etc.) is inherently superior to the
RFC Editor's review process (consisting of I don't know what).  However
I do think that differences in these processes will tend to result in
differences in document quality that at the very least should be
communicated to readers.  And I sincerly doubt that the RFC Editor can
provide adequate review of documents affecting multiple areas without
a public feedback mechanism similar to IETF last calls.

I certainly encourage the RFC Editor to employ cross-area review for
any document that describes a protocol that has the potential to impact
multiple interest areas - (and not just "areas" in the IETF sense).

When documenting existing protocols, there has always been a tension
between accurately documenting the protocol as it appears in the wild
and documenting the protocol as it "should" work.  Both IETF and the
RFC Editor should encourage authors documenting existing protocols to
document them first as they are actually implemented and to clearly
separate any opinions about how they "should" work from the actual
descriptions of how they _do_ work.  At the same time it is important
to make readers aware of the hazards of implementing and using a
poorly-designed protocol. One way to do this would be to include a
detailed discussion of the protocol's hazards (security or otherwise)
and any fixes for those hazards in an appendix, while including
pointers to that appendix in appropriate locations in the main protocol
description.