Subject: [Rtg-open-source] normatively referencing open source work from standards-track RFCs

From: Alia Atlas <[email-masked]>
Date: Sun, 29 Oct 2017 22:57:04 -0400

Although this list has been regrettably silent, I have still been thinking
about what could be done
to better improve interactions between the IETF and the variety of Open
Source organizations and projects.   I would love your opinions and
perspective.

One obvious issue that jumped out at me is that it currently is quite
discouraged for a standards-track RFC to normatively reference non-SDO work
and part of this is the lack of clear policy around it.   Since normative
references basically restrict what technology can be built on top of which
and how, fixing this can give a means for the IETF to publish standards
that use mature Open Source technology.

Please take a look and discuss here what you think.   What things did I
miss (other than the typo for the  dedicated reviewers ;-) ?  Would this
give clear enough guidance?

Regards & Thanks,
Alia

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sun, Oct 29, 2017 at 10:36 PM
Subject: I-D Action: draft-atlas-external-normref-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Normative References in RFCs from Open Source
        Authors         : Alia Atlas
                          Eliot Lear
                          Joel Halpern
                          Heather Flanagan
                          Jeff Tantsura
        Filename        : draft-atlas-external-normref-00.txt
        Pages           : 6
        Date            : 2017-10-29

Abstract:
   IETF procedures generally require that a standards track RFC may not
   have a normative reference to a non standards track specification
   except those from other
   standards bodies.  This document creates an External Specification
   registry, similar to the DownRef registry that has been created based
   on [RFC3967] and permits normative references to community accepted
   external specifications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-atlas-external-normref/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-atlas-external-normref-00
https://datatracker.ietf.org/doc/html/draft-atlas-external-normref-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Peter Hessler <[email-masked]>
Date: Mon, 30 Oct 2017 09:05:38 +0100

I'm afraid I don't understand the reasoning.  Can you give some
examples that this would solve?

On 2017 Oct 29 (Sun) at 22:57:04 -0400 (-0400), Alia Atlas wrote:
:Although this list has been regrettably silent, I have still been thinking
:about what could be done
:to better improve interactions between the IETF and the variety of Open
:Source organizations and projects.   I would love your opinions and
:perspective.
:
:One obvious issue that jumped out at me is that it currently is quite
:discouraged for a standards-track RFC to normatively reference non-SDO work
:and part of this is the lack of clear policy around it.   Since normative
:references basically restrict what technology can be built on top of which
:and how, fixing this can give a means for the IETF to publish standards
:that use mature Open Source technology.
:
:Please take a look and discuss here what you think.   What things did I
:miss (other than the typo for the  dedicated reviewers ;-) ?  Would this
:give clear enough guidance?
:
:Regards & Thanks,
:Alia
:
:
:---------- Forwarded message ----------
:https://tools.ietf.org/html/draft-atlas-external-normref-00
:https://datatracker.ietf.org/doc/html/draft-atlas-external-normref-00

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Oct 2017 12:28:49 -0400

Hi Peter,

As a trivial example that I'm aware of :-), draft-przygienda-rift/ encodes
its messages using thrift.

Does that help?

Regards,
Alia

On Mon, Oct 30, 2017 at 4:05 AM, Peter Hessler <[email-masked]> wrote:

> Rtg-open-source mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-open-source
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 30 Oct 2017 19:04:48 +0100

Thanks for this work, Alia

Some quick comments:

Editorial:
 Its always helpfull to add a "change" section and write in that section
 where this drafts content is being discussed ([email-masked]).
 If somebody stumbles across the draft thats the important pointer.

Payload:
  My first thought was "why the heck do i care about open source", i care
  about well specified behavior/API, e.g.: something that can be referred to
  for users wanting to adopt an IETF work referring to that external source.

  So, the "why do we care" should be written better. One answer from you
  was the existance of protocols not resulting from IETF work that
  IETF participants want to leverage. thrift, google RPC, etc. pp.
  This should be better written in the draft.

  But IMHO there is something more fundamental that we may want to highlight:

  1. The IETF should be able to incooperate any external work as long
  as it meets well defined criteria. I am not on top of all the existing
  IETF docs defining this, but it seems somewhat convoluted and restricted
  to some form of "SDO". 

  2. What IMHO fundamentlly has happened is that because of the Internet
  (grin), we now got a lot of collaborative SW development that manages
  to establish itself as "de-facto-standards" in their area. And if
  that work meets those well defined criteria, then IETF should be able
  to use it.

I don't have exact text to propose right now, but what i would like to
understand is what the worst most lightweight way would be to adopt an external
created protocol/API/etc (lowest common denominator):

  So lets say theree is this protocol where the OSS developers do not
  care about IETF at all and don't get engaged. Some IETF folks though
  would like to use the work as part of their standard.

  So, whats the minimum set of steps for these IETF folks to be able
  to use this external work as normative reference ? 

Maybe have a bar discussion in singapore ?
Would happy to contribute/co-author if you're interested.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Oct 2017 18:49:57 -0400

Hi Toerless,

> Thanks for this work, Alia

Thanks :-)

>  If somebody stumbles across the draft thats the important pointer.

Yes - the primary discussion is happening on [email-masked].  I raised it
here
because I thought it was likely to be of interest.

>   This should be better written in the draft.

Right - the motivation that I see is that open source projects are
increasingly
creating artifacts that could be good to build on. I didn't write the
policy to be
dependent on the source.

>   IETF docs defining this, but it seems somewhat convoluted and restricted

Right - I crawled down that rabbit hole in RFC2026 and RFC3697.
Technically,
it is possible to reference proprietary specifications - but the ID-nits
checklist
strongly discourages it.

The details in the draft don't restrict the source.

>   that work meets those well defined criteria, then IETF should be able

Exactly!

>   to use this external work as normative reference ?

Well, that's what we've specified in this version - or at least our best
initial thoughts.
First is whether the external work meets requirements as far as stable,
immutable,
mature, clear IPR info, generally accessible and not confidential, and
intended as a
public interface.

Second is to have the WG agree to use it at WG adoption, confirm at WGLC,
mention
it at IETF Last Call & in shepherd's report, and then recorded into a
registry after IESG
approval - so reuse is easy and all those steps aren't necessary.

> Would happy to contribute/co-author if you're interested.

I'd be delighted to talk in Singapore.   Thanks for your interest.

Regards,
Alia

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 31 Oct 2017 00:01:30 +0100

On Mon, Oct 30, 2017 at 06:49:57PM -0400, Alia Atlas wrote:
> here because I thought it was likely to be of interest.

Not sure how detailled we can have a discussion there. [email-masked]
discussions are never sustained. At most it's the hot topic of the
day/week. Better to move interested folks over.

> I'd be delighted to talk in Singapore.   Thanks for your interest.

Send an email around when you want folks to have a chat about it.

Cheers
    Toerless