RE: Coex draft as BCP?

Mike reacts on DBH posting:
> > Without interoperability testing of multiple independent
> > implementations, we cannot request standards-track advancement to Draft
> > Status, and so far we have not been able to arrange a thorough test of
> > the features and operations detailed in this document. If anybody is
> > willing to work on staging the interoperability testing of some known
> > implementations, that would be helpful.
> > 
> > **It does not need to be the implementers that perform the testing.**
> > 
> > We could recycle at Proposed and walk away, but I personally don't like
> > that option, and the ADs may not like that option, but we can try that
> > route if WG consensus is to do so.
> 
> Now that SNMPv1 has been reclassified as HISTORIC, it seems clear to
> me that having the coexistence document remain on the standards track
> (at any maturity level) would conflict with the following provision of
> RFC 2026 Section 4.2.4:
> 
>    Note: Standards track specifications normally must not depend on
>    other standards track specifications which are at a lower maturity
>    level or on non standards track specifications other than referenced
>    specifications from other standards bodies.
> 
> The specific problem is that the coexistence document depends on
> RFC 1157 as a normative reference, but RFC 1157 is now Historic.
> 
I thought I had answered this one in the past.
Note that it has "normally must" in there.
RFC2026 also allows for exceptions, so we could ask IESG to make
that exception.
I have also discussed this with other IESG members in the past, and 
there was then a thinking that the references to the historic 
technology could be made an informational reference, because the 
document is meant to help to ultimately move away from the old 
(historic) technology.

> There is also a practical issue.  Keeping the document on the standards
> track creates an implied committment to do the work needed to advance
> it -- if not now, then later on.  Frankly, I don't think that the effort
> involved in that would be a good use of IETF resources.
> 
I agree with that one.

> > On a quick reading, RFC2026 seems to indicate that BCP is for the use of
> > IAB and IESG, although "BCPs are meant to express community consensus"
> > may qualify this document.
> 
> There are, however, some precedents for publishing protocol-related
> BCP documents.  See, for example, RFCs 2644 and 2827.
> 
Indeed, I do not believe that only IAB and IESG can publish BCP documents.
And describing the process how different version of a technology can
coexist seems quite appropriate to me as BCP.

> > I personally would like to advance the draft or publish as Proposed or
> > BCP, since those require IESG review, and I believe such review from
> > outside the WG is a good thing.
> > 
> > If it turns out the ADs or the IESG find these unacceptable, they will
> > determine the appropriate publication level, or return the document to
> > the WG for disposition.
> 
> Another option would be to submit the document for consideration as
> an Informational RFC.  According to RFC 2026 Section 4.2.3, "Procedures
> for Experimental and Informational RFCs", IESG review would still be
> required:
> 
>    Documents proposed for Experimental and Informational RFCs by IETF
>    Working Groups go through IESG review.  The review is initiated using
>    the process described in section 6.1.1.
> 
> I don't think it makes too much difference whether the document is
> submitted for consideration as a BCP or as an Informational RFC, but
> I don't think it would be appropriate for it to remain on the
> standards track.
> 
The IESG will indeed review Informational documents that come from
WGs. However, the review is often not as detailed as is done for
STDs track and BCP documents.
A BCP document also requires an IETF wide Last Call, where as an
Informational normally does not get an IETF Wide Last Call.
So a BCP will get a better community review than Informational.

I can live with both BCP or Informational though.

Bert
> //cmh
>