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

[Alia Atlas <[e-mail]>]

Hi Toerless,

On Mon, Oct 30, 2017 at 2:04 PM, Toerless Eckert <[e-mail]> wrote:

> Thanks for this work, Alia
>

Thanks :-)


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

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


> 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.
>

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.



>   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".
>

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.


>   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.
>

Exactly!


> 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 ?
>

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.


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

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

Regards,
Alia



> Cheers
>     Toerless
>
> On Sun, Oct 29, 2017 at 10:57:04PM -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 ----------
> > From: <[e-mail]>
> > Date: Sun, Oct 29, 2017 at 10:36 PM
> > Subject: I-D Action: draft-atlas-external-normref-00.txt
> > To: [e-mail]
> >
> >
> >
> > 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
> > [e-mail]
> > 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
>
>
> --
> ---
> [e-mail]
>