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

Alia Atlas <akatlas@gmail.com> Mon, 30 October 2017 22:50 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: rtg-open-source@ietfa.amsl.com
Delivered-To: rtg-open-source@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6113F630 for <rtg-open-source@ietfa.amsl.com>; Mon, 30 Oct 2017 15:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvd6MBBygL9u for <rtg-open-source@ietfa.amsl.com>; Mon, 30 Oct 2017 15:49:59 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4596B13F6D1 for <rtg-open-source@ietf.org>; Mon, 30 Oct 2017 15:49:59 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id s66so18745184wmf.5 for <rtg-open-source@ietf.org>; Mon, 30 Oct 2017 15:49:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RMEsBVM2Nf8wCBKjb4l7l17HbgkULr2+hrbSEK4eO4E=; b=XSWa8jGMJ59Fpep1Ekf7gd+D6lomRQDyswy/znS7/PaAoijkDj5w1qMfLfQZgeYxIa ApO68mpfO7R0+nLGj9Z0nSMjMRm86VE3gvxKNz1BguogMT7XQ0f/05iu1riC2kGrWPRH uYhBRKPOfS4rkTdJcXrNzWoSEjZGXC4ITOt+3hNe7QhtAEMSLwxfl2FO8ptMWKEi7X4N u1Yy73OxdHhLuZtCO1B9MjXcsdCCpNs69Qxsjqag0F0XoygI3ThoK87tcw4gJdGyf5bp myYmRQvDFr4ZtJygrdHbeh2t6Ax0wB05znapgeE5GL5cYjakUspUNf2jfO7iCMmHGX7Y chww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RMEsBVM2Nf8wCBKjb4l7l17HbgkULr2+hrbSEK4eO4E=; b=D3+LdN04LIHFT8A9QkNbARcFmwFhQ2C5VS8t7bEwQVAIcxY4A0FJqkTzMwec15Vp+J OSIBuQD4jQ5XvWxPTOnGSiPrYIug2d+OE0AXIoAKmy42fZ/qwpEXT1S8S6CJrFG6aOUO 94yFg2cyn/3ta4rxqlMuRYNJqwG3pnCi/46ERz5ABBeVqdulXo66ufMdTHAWOxvrUjX+ VDVZot3A/Hn/R6fHUfIToIQDpaonMsQ0DaSO+OWk8+hRMkIecFcWSEDPi3gircYmI+BZ 9cj7kgKjAFpJ2dnFGFxJ76M+bZ6jUfHwUc4v8brNUa7gw1zGlwccyUccuCJckpKx9hCI YscA==
X-Gm-Message-State: AMCzsaWZog1BnGr5SaD9vIrbUkApSlpL3tHlTMpJRvhfHPsWiB+QctSL k3mk2GvoUlHRBRn5mJHDiQ4EM33z7k4+9sbjp2A0tw==
X-Google-Smtp-Source: ABhQp+Sr73WivXfZipVimr5apbgCzDKVq9dCdfZJA5qmEKvY0//D37DE0bTHxeyCKM7tbW+OUuNWSBMCXutxA1OGrMs=
X-Received: by 10.28.178.81 with SMTP id b78mr178679wmf.157.1509403797608; Mon, 30 Oct 2017 15:49:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.150.10 with HTTP; Mon, 30 Oct 2017 15:49:57 -0700 (PDT)
In-Reply-To: <20171030180448.GV19957@faui40p.informatik.uni-erlangen.de>
References: <CAG4d1rdD4tLWqjeQOuOFGyKSo4ahupAFwhBm-C+zSNguo0St4g@mail.gmail.com> <20171030180448.GV19957@faui40p.informatik.uni-erlangen.de>
From: Alia Atlas <akatlas@gmail.com>
Date: Mon, 30 Oct 2017 18:49:57 -0400
Message-ID: <CAG4d1rdq160tAJi1wnu5mBCpHF7Bgm+it1EuHxw_fw+teBqWYg@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: rtg-open-source@ietf.org
Content-Type: multipart/alternative; boundary="001a11443e362ddf80055ccb7550"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-open-source/gysFmO_rROBK0ou9nqm0Xi2JTQg>
Subject: Re: [Rtg-open-source] normatively referencing open source work from standards-track RFCs
X-BeenThere: rtg-open-source@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion and collaboration for Open Source efforts related to the Routing Area <rtg-open-source.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-open-source>, <mailto:rtg-open-source-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-open-source/>
List-Post: <mailto:rtg-open-source@ietf.org>
List-Help: <mailto:rtg-open-source-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-open-source>, <mailto:rtg-open-source-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2017 22:50:03 -0000

Hi Toerless,

On Mon, Oct 30, 2017 at 2:04 PM, Toerless Eckert <tte@cs.fau.de>; 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 (rtg-open-source@ietf.org).
>  If somebody stumbles across the draft thats the important pointer.
>

Yes - the primary discussion is happening on ietf@ietf.org.  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: <internet-drafts@ietf.org>;
> > Date: Sun, Oct 29, 2017 at 10:36 PM
> > Subject: I-D Action: draft-atlas-external-normref-00.txt
> > To: i-d-announce@ietf.org
> >
> >
> >
> > 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
> > I-D-Announce@ietf.org
> > 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
>
>
> --
> ---
> tte@cs.fau.de
>