RE: letting IETF build on top of Open Source technology

["Mehmet Ersue" <mersue@xxxxxxxxx>]

Hi Alia, All,

 

during the discussion it kind of gets lost what kind of reference is sufficient and whether a normative reference is explicitly required.

If possible we should avoid such external dependency.

 

IMO only in very rare cases an IETF RFC would use an external document normatively (i.e. use the external document as its basis or build on-top of it) and a normative reference would be required.

 

To be able to understand in which cases a normative reference is imperative I think the requirements should be discussed and specified clearly giving real-life use cases.

 

Mehmet

 

From: Behcet Sarikaya [mailto:sarikaya2012@xxxxxxxxx]
Sent: Wednesday, November 1, 2017 5:33 PM
To: Alia Atlas <akatlas@xxxxxxxxx>
Cc: Mehmet Ersue <mersue@xxxxxxxxx>; IETF Discussion Mailing List <ietf@xxxxxxxx>
Subject: Re: letting IETF build on top of Open Source technology

 

Hi Alia,

One member mentioned that the open source code does serve as the protocol description and hence it could be referenced as dependency in RFCs.

I think we should question that.

I worked many years on formal description techniques for protocols. I think that such specs could serve as a reference.

Source code in some specific programming language is very long and difficult to follow for someone interested in a high level view of the protocol.

Also many people do not know the specific programming language it was written.

My 2 cents.

Regards,

Behcet

 

On Tue, Oct 31, 2017 at 1:29 PM, Alia Atlas <akatlas@xxxxxxxxx> wrote:

Hi Mehemet:

 

below in-line 

 

On Tue, Oct 31, 2017 at 1:14 PM, Mehmet Ersue <mersue@xxxxxxxxx> wrote:

See ME:

 

Thanks,

Mehmet

 

From: Alia Atlas [mailto:akatlas@xxxxxxxxx]
Sent: Tuesday, October 31, 2017 5:13 PM
To: Mehmet Ersue <mersue@xxxxxxxxx>
Cc: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>; Martin Thomson <martin.thomson@xxxxxxxxx>; IETF Discussion Mailing List <ietf@xxxxxxxx>
Subject: Re: letting IETF build on top of Open Source technology

 

Hi Mehmet,

 

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. 

 

[Alia] Agreed - and I pulled the requirements around stability, maturity, confidentiality, and IPR considerations largely from 2026.

My question is whether it is rare than an IETF RFC builds on top of open source work because the path to do so is seen as too challenging/long/expensive or simply not relevant. This draft is proposing a policy assuming the former applies at least some of the time.

 

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.

 

The requirements, I think, stem from our (the IETF community's) understanding of what is necessary for a dependency of a standards-track RFC and I am not proposing that those should change.  I'm trying to capture what they are and how to evaluate a piece of work.

 

Rather than looking at the set of documents and creating a registry, the draft suggests that when a WG wants to use such an item as a dependency, then after that use has IESG Approval, then the item can be added to a registry - so other WGs and other documents in that WG can benefit from the evaluation that was done and feel more confident about using it.

 

Regards,

Alia

 

Regards,

Alia

 

 

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