On Tue, Oct 31, 2017 at 12:05 PM, Mehmet Ersue <mersue@xxxxxxxxx> wrote:
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.
Of course - and that's why it is necessary for the item to meet the questions posed in the draft - which are the requirements (and we'll rephrase more clearly as Russ suggested).
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.
Sure - and that was one of the motivations for RFC 3967.
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.
An example would be potentially thrift, I think, for protocol encodings. I have to hunt down the detailed reference for it.
I know that protobufs have good documentation also. I am sure that there are others and would be happy to hear folks chime in with more.
It's unclear whether there is a set of requirements acceptable to the IETF Community that would work for WHATWG work.
Is your concern that you don't see useful open source work that would be suitable to reference? Or that none would meet our set of requirements?
Or that it is risky to consider referencing non-SDO external work?
ME: Generally I don’t see an issue with referencing useful open source work. Though only in rare cases an IETF RFC has a dependency on or builds indeed on-top of such a document normatively. I think the main criteria for a normative reference is still based on the quoted text from RFC 3967 above.
I believe use cases and examples will help to define concrete requirements.
Once we have the requirements together such documents need to be looked at in a case by case basis and taken over into a registry.
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