Hi Alia, > > 1. Is it stable, mature, and immutable (except for errata)? > > Those are not well known characteristics of open source projects. > Even if we tie a reference down to a very specific version, I'm unclear how > that can truly act as a stable reference. It may be stable in a mathematical > sense, but it may also be seven years behind deployed reality. I agree with Brian. There are different type of non-SDO organizations having documents with diverse maturity levels and stability. Many of them don't qualify as normative references. Obvious examples for normative references are usually from well-known SDOs like IEEE or W3C where the new standard-track RFC uses it as its basis or builds on-top of it (e.g. [W3C.REC-xml-20001006]) I also don't see an issue with MD5 and HMAC as these are Informational RFCs at IETF with a well-known stability. Looking at section 1.1. of RFC 3967 and the statement: "a normative reference specifies a document that must be read to fully understand or implement the subject matter in the new RFC, or whose contents are effectively part of the new RFC, as its omission would leave the new RFC incompletely specified", can you please give examples of external documents from non-DOSs, which clearly qualify as normative references for a standard-track RFC at IETF? I think primarily on non-SDO documents where the new RFC would build on-top of it. Thanks, Mehmet > -----Original Message----- > From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Brian E Carpenter > Sent: Monday, October 30, 2017 4:49 AM > To: Martin Thomson <martin.thomson@xxxxxxxxx>; Alia Atlas > <akatlas@xxxxxxxxx> > Cc: IETF Discussion Mailing List <ietf@xxxxxxxx> > Subject: Re: letting IETF build on top of Open Source technology > > On 30/10/2017 16:27, Martin Thomson wrote: > > On Mon, Oct 30, 2017 at 2:18 PM, Alia Atlas <akatlas@xxxxxxxxx> wrote: > >> The existing downref process (RFC 3967) doesn't apply. That is to > >> handle references to an RFC that is at a lower maturity - such as a > >> normative reference to an Informational or Experimental RFC - or from > >> an Internet Standard to a Proposed Standard. > > > > I couldn't find anything in 3967 to support that view (other than the > > parenthetical in the abstract). Maybe it's implicit. > > The quote from RFC2026 in section 1 of RFC3967 is pretty unambiguous when > read in context - throughout RFC2026, "standards track" refers to the IETF > standards track, and "standards track specifications" > refers to IETF documents. And in any case the Abstract of RFC3967 sets the > scope thus: "Exceptions to this rule are sometimes needed as the IETF uses > informational RFCs to describe non-IETF standards or IETF-specific modes of > use of such standards." > > My main concern with the new proposal is other: > > > 1. Is it stable, mature, and immutable (except for errata)? > > Those are not well known characteristics of open source projects. > Even if we tie a reference down to a very specific version, I'm unclear how > that can truly act as a stable reference. It may be stable in a mathematical > sense, but it may also be seven years behind deployed reality. > > Brian