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

Toerless Eckert <> Mon, 30 October 2017 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7244B9A2A for <>; Mon, 30 Oct 2017 11:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wnTnDdFmEer2 for <>; Mon, 30 Oct 2017 11:05:00 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5659D13FE4A for <>; Mon, 30 Oct 2017 11:04:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2F17B58C4BC; Mon, 30 Oct 2017 19:04:49 +0100 (CET)
Received: by (Postfix, from userid 10463) id 15ABAB0D01F; Mon, 30 Oct 2017 19:04:48 +0100 (CET)
Date: Mon, 30 Oct 2017 19:04:48 +0100
From: Toerless Eckert <>
To: Alia Atlas <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Rtg-open-source] normatively referencing open source work from standards-track RFCs
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion and collaboration for Open Source efforts related to the Routing Area <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Oct 2017 18:05:03 -0000

Thanks for this work, Alia

Some quick comments:

 Its always helpfull to add a "change" section and write in that section
 where this drafts content is being discussed (
 If somebody stumbles across the draft thats the important pointer.

  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.


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: <>
> Date: Sun, Oct 29, 2017 at 10:36 PM
> Subject: I-D Action: draft-atlas-external-normref-00.txt
> To:
> 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:
> There are also htmlized versions available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or