From nobody Sun Oct 29 19:57:10 2017 Return-Path: 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 E0D5513F50F for ; Sun, 29 Oct 2017 19:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 x2-x38rTUqre for ; Sun, 29 Oct 2017 19:57:07 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 9FFDF13F58D for ; Sun, 29 Oct 2017 19:57:06 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id p96so11094514wrb.7 for ; Sun, 29 Oct 2017 19:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zwap+E5QfQs5Mam6fbQ/sWh3ASuZfoa1WGzeb1IPtA0=; b=dcJbYXm4NIF2FfhUP9tphXsyNRe6m/0tGoKtouwkH9LxCdCccPotmJu33RJ8KlGsg6 oSEf1nam043EdxCvwVsELBW8mDKailB2utGr6HJDCBOojDFaTYy5ex62M1cQSMOSbwQm whPjLDdxJdCmPHT2a58RafARkHImf+FK/eGbT9POXaxWUFI/ACifNamd0KHLS+l4dC1g T66y2DgY97yhKkmWbwPY+XypCo3E+nrWBos7hlNuA68BjUYXxqOM15BlSV0PoZdRGMWW MJgopcze+25WOl0pgHMNnqWBItxgS2OBBA8EJ+wkVKO2icE61sqL9AoBtj4bChML6HDy /Fmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zwap+E5QfQs5Mam6fbQ/sWh3ASuZfoa1WGzeb1IPtA0=; b=otn9xZzGqyBAHfVbhceYlBcguIQmKkHdzQO4Hvx9LFZ6k3AhpgKlNiCPsEAkk4yeIT o+2qbw/d1NZx6JvGVWxkZG0t3x1z949OqWhIdj3+O6R8nTQjGOrEjXjlEn4MjNKVpKlq +9Pf4R6O757eCiPQI3y44cqs1nL3NKlT8EaAyPOYZL8zBxwtzIiE94xy9ahUFW6LN0er WMNSBBvm3m69pCscRfbYLZBgGUj2RDR4o9Bx8+zcOhgPZSBjjABv50GaR+o5vuQ975B3 pNEjRkAdS+k4cmhATt+wQIRJtLsTeq92T/0bsZPunRXi/fqLfHfO+b9WwR4QxhNhkoso WgfA== X-Gm-Message-State: AMCzsaWLykpwvp0Qu7ZB138YPbwh7nn4EZT2nFHPTMJUxHIVHrvQGPM6 I+MUjQz6wXG9hde0Uv8pzkiaT7Sk+g6quDcVhlRKqg== X-Google-Smtp-Source: ABhQp+SJcxHM5EV44BA4jt4SNExINZzisuoHDm/9geqYqHhVPRXYAZFOxWlo1C8ucPSTYf33Nqizkd5xLlUwN7EnEsI= X-Received: by 10.223.128.162 with SMTP id 31mr6472155wrl.258.1509332224740; Sun, 29 Oct 2017 19:57:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.150.10 with HTTP; Sun, 29 Oct 2017 19:57:04 -0700 (PDT) From: Alia Atlas Date: Sun, 29 Oct 2017 22:57:04 -0400 Message-ID: To: rtg-open-source@ietf.org Content-Type: multipart/alternative; boundary="94eb2c068e001a947d055cbacbf2" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 02:57:09 -0000 --94eb2c068e001a947d055cbacbf2 Content-Type: text/plain; charset="UTF-8" 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: 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 --94eb2c068e001a947d055cbacbf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Although this list has been regrettably silent, I hav= e still been thinking about what could be done
to better improve = interactions between the IETF and the variety of Open Source organizations = and projects.=C2=A0 =C2=A0I would love your opinions and perspective.
=

One obvious issue that jumped out at me is that it curr= ently is quite discouraged for a standards-track RFC to normatively referen= ce non-SDO work and part of this is the lack of clear policy around it.=C2= =A0 =C2=A0Since normative references basically restrict what technology can= be built on top of which and how, fixing this can give a means for the IET= F to publish standards that use mature Open Source technology.
Please take a look and discuss here what you think.=C2=A0 =C2= =A0What things did I miss (other than the typo for the=C2=A0 dedicated revi= ewers ;-) ?=C2=A0 Would this give clear enough guidance?

Regards & Thanks,
Alia


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, O= ct 29, 2017 at 10:36 PM
Subject: I-D Action: draft-atlas-external-normre= f-00.txt
To: i-d-announce@ietf.= org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


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

Abstract:
=C2=A0 =C2=A0IETF procedures generally require that a standards track RFC m= ay not
=C2=A0 =C2=A0have a normative reference to a non standards track specificat= ion
=C2=A0 =C2=A0except those from other
=C2=A0 =C2=A0standards bodies.=C2=A0 This document creates an External Spec= ification
=C2=A0 =C2=A0registry, similar to the DownRef registry that has been create= d based
=C2=A0 =C2=A0on [RFC3967] and permits normative references to community acc= epted
=C2=A0 =C2=A0external 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-at= las-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 submissio= n
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/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--94eb2c068e001a947d055cbacbf2-- From nobody Mon Oct 30 01:06:39 2017 Return-Path: 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 3BCDC1FABAE for ; Mon, 30 Oct 2017 01:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TIKt_W78kM8g for ; Mon, 30 Oct 2017 01:06:33 -0700 (PDT) Received: from mail.theapt.org (gir.theapt.org [IPv6:2001:67c:12f4::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE80813F75A for ; Mon, 30 Oct 2017 01:05:43 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:67c:12f4::2]) by mail.theapt.org (OpenSMTPD) with ESMTPSA id f21e3094 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO) for ; Mon, 30 Oct 2017 09:05:39 +0100 (CET) Date: Mon, 30 Oct 2017 09:05:38 +0100 From: Peter Hessler To: rtg-open-source@ietf.org Message-ID: <20171030080538.GU10247@gir.theapt.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 08:06:37 -0000 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 nobody Mon Oct 30 09:38:11 2017 Return-Path: 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 135D513FA96 for ; Mon, 30 Oct 2017 09:38:09 -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 yye1SLx3yaGp for ; Mon, 30 Oct 2017 09:38:07 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 6820C1DC389 for ; Mon, 30 Oct 2017 09:28:51 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id b189so16970033wmd.4 for ; Mon, 30 Oct 2017 09:28:51 -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=ONuuzKMntABiVdii2duY//3oYLIzopq4G8fbogUWTPc=; b=n16vsx5mvs+SQa9RGnkl4vM1FYhq/I32SlsGt3saY/CUlQlvgyCZkVgnLygdUtJs7F T9J3rQr0nRBh/bIbTPGEQ1IomFaxwusOrSZEz18GyeiT+5UfhrlfZQSVvXbthXIY7pd7 tj0cP5wk5Dvw5dbLkOvKBEGuIqD4eG8u/TP5BauA3PwxM6SRCZw0kkiIhOXXU82UIzRC RHvbQmom7NVXIvP+i4+LumNOptz/46GvhEmorRTU6nhi1pFVVMQTfaEyYPtHsKWEFxvL AgB1xyt99CPNHsM7oo3ZBAook6yxKkWGi3ILMSgUVyAmXrAuo+c6QpuAEkTw8M4oyuAT adRQ== 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=ONuuzKMntABiVdii2duY//3oYLIzopq4G8fbogUWTPc=; b=O1a5rpaEMpHeQgc9Jqk2fcY94rWFq2yKDT1Qv1uvo2Du4/dG+8OAUp5+qDe2bhLZgU nojzlo4iQPLOnU5T5zXlPaFSBP/hZi674ESNfZjVTWIAnPCFHJMLHV6us4nMqkmoxcb4 57nTp0wK8j1VZo0+0FMJZAYfwck5Kxpk0bX+j1o0L0QYHtHHjC8h9kqfKJuGeLcXhjot OUKLfhSkCkkuthf1wumgKAEzR/RBjw1ubziENMcx/5ABkbLhASZKei4umEaFjuCv2AGm Jx9pjDTrVb8xSeRokE5+uzPJwuQlKuvDSC2/buHWOdQdDLl7FcS+zX/eXxajbbmrwd5d s1Ag== X-Gm-Message-State: AMCzsaXRRrGKXryTqURimoCsqnlVG1KmjPD+oQNs/gGVEV+CnKPPnzj8 c0pcedFtzH4j9vXAzYErH8CdjjsjzntSPliJQpTe5tPp X-Google-Smtp-Source: ABhQp+TWyF5nC0OuOASorTGpHfQH9uEKva/wS3zx/hzuzRFcSNsJiQ5ybLfMXMDUTxNpszAUgBQef65gzLGEQKirCGA= X-Received: by 10.28.178.81 with SMTP id b78mr4235173wmf.157.1509380929673; Mon, 30 Oct 2017 09:28:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.150.10 with HTTP; Mon, 30 Oct 2017 09:28:49 -0700 (PDT) In-Reply-To: <20171030080538.GU10247@gir.theapt.org> References: <20171030080538.GU10247@gir.theapt.org> From: Alia Atlas Date: Mon, 30 Oct 2017 12:28:49 -0400 Message-ID: To: Peter Hessler Cc: rtg-open-source@ietf.org Content-Type: multipart/alternative; boundary="001a11443e3624e055055cc622b4" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:38:09 -0000 --001a11443e3624e055055cc622b4 Content-Type: text/plain; charset="UTF-8" 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 wrote: > 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 > > _______________________________________________ > Rtg-open-source mailing list > Rtg-open-source@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-open-source > --001a11443e3624e055055cc622b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Peter,

As a trivial example that I&#= 39;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 <phessler@thea= pt.org> wrote:
I'm afra= id I don't understand the reasoning.=C2=A0 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.=C2=A0 =C2=A0I 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 wor= k
:and part of this is the lack of clear policy around it.=C2=A0 =C2=A0Since = 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.=C2=A0 =C2=A0What thing= s did I
:miss (other than the typo for the=C2=A0 dedicated reviewers ;-) ?=C2=A0 Wo= uld this
:give clear enough guidance?
:
:Regards & Thanks,
:Alia
:
:
:---------- Forwarded message ----------
:https://tools.ietf.org/html/= draft-atlas-external-normref-00
:https://datatracker.ietf.org/<= wbr>doc/html/draft-atlas-external-normref-00

_______________________________________________
Rtg-open-source mailing list
Rtg-open-source@ietf.org https://www.ietf.org/mailman/listinfo/rtg-= open-source

--001a11443e3624e055055cc622b4-- From nobody Mon Oct 30 11:05:08 2017 Return-Path: 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 7244B9A2A for ; Mon, 30 Oct 2017 11:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnTnDdFmEer2 for ; Mon, 30 Oct 2017 11:05:00 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5659D13FE4A for ; Mon, 30 Oct 2017 11:04:54 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2F17B58C4BC; Mon, 30 Oct 2017 19:04:49 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (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 Cc: rtg-open-source@ietf.org Message-ID: <20171030180448.GV19957@faui40p.informatik.uni-erlangen.de> 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-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 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: 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. 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 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: 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 From nobody Mon Oct 30 15:50:04 2017 Return-Path: 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 ; 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 ; 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 ; Mon, 30 Oct 2017 15:49:59 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id s66so18745184wmf.5 for ; 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: <20171030180448.GV19957@faui40p.informatik.uni-erlangen.de> From: Alia Atlas Date: Mon, 30 Oct 2017 18:49:57 -0400 Message-ID: To: Toerless Eckert Cc: rtg-open-source@ietf.org Content-Type: multipart/alternative; boundary="001a11443e362ddf80055ccb7550" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:50:03 -0000 --001a11443e362ddf80055ccb7550 Content-Type: text/plain; charset="UTF-8" Hi Toerless, On Mon, Oct 30, 2017 at 2:04 PM, Toerless Eckert 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: > > 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 > --001a11443e362ddf80055ccb7550 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Toerless,

On Mon, Oct 30, 2017 at 2:04 PM, Toerless Eckert <tte@cs.fau.de> wrote:
Thanks for this work,= Alia

Thanks :-)=C2=A0
=C2=A0=

Some quick comments:

Editorial:
=C2=A0Its always helpfull to add a "change" section and write in = that section
=C2=A0where this drafts content is being discussed (rtg-open-source@ietf.org).
=C2=A0If somebody stumbles across the draft thats the important pointer.

Yes - the primary discussion is happening= on ietf@ietf.org.=C2=A0 I raised it h= ere
because I thought it was likely to be of interest.=C2=A0
=C2=A0
Payload:
=C2=A0 My first thought was "why the heck do i care about open source&= quot;, i care
=C2=A0 about well specified behavior/API, e.g.: something that can be refer= red to
=C2=A0 for users wanting to adopt an IETF work referring to that external s= ource.

=C2=A0 So, the "why do we care" should be written better. One ans= wer from you
=C2=A0 was the existance of protocols not resulting from IETF work that
=C2=A0 IETF participants want to leverage. thrift, google RPC, etc. pp.
=C2=A0 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 o= n. I didn't write the policy to be
dependent on the source.= =C2=A0

=C2=A0
=C2=A0 But IMHO there is something more fundamental that we may want to hig= hlight:

=C2=A0 1. The IETF should be able to incooperate any external work as long<= br> =C2=A0 as it meets well defined criteria. I am not on top of all the existi= ng
=C2=A0 IETF docs defining this, but it seems somewhat convoluted and restri= cted
=C2=A0 to some form of "SDO".

Right - I crawled down that rabbit hole in RFC2026 and RFC3697.=C2=A0 Tech= nically,=C2=A0
it is possible to reference proprietary specificat= ions - but the ID-nits checklist
strongly discourages it.=C2=A0

The details in the draft don't restrict the sou= rce.
=C2=A0
=C2=A0 2. What IMHO fundamentlly has happened is that because of the Intern= et
=C2=A0 (grin), we now got a lot of collaborative SW development that manage= s
=C2=A0 to establish itself as "de-facto-standards" in their area.= And if
=C2=A0 that work meets those well defined criteria, then IETF should be abl= e
=C2=A0 to use it.

Exactly!=C2=A0
<= div>=C2=A0
I don't have exact text to propose right now, but what i would like to<= br> understand is what the worst most lightweight way would be to adopt an exte= rnal
created protocol/API/etc (lowest common denominator):

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

=C2=A0 So, whats the minimum set of steps for these IETF folks to be able =C2=A0 to use this external work as normative reference ?
<= div>
Well, that's what we've specified in this versio= n - or at least our best initial thoughts.
First is whether the e= xternal work meets requirements as far as stable, immutable,
matu= re, clear IPR info, generally accessible and not confidential, and intended= as a
public interface.

Second is to hav= e 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 int= o a registry after IESG
approval - so reuse is easy and all those= steps aren't necessary.
=C2=A0
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.=C2=A0 =C2= =A0Thanks for your interest.

Regards,
Al= ia=C2=A0

=C2=A0
Cheers
=C2=A0 =C2=A0 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 thin= king
> about what could be done
> to better improve interactions between the IETF and the variety of Ope= n
> Source organizations and projects.=C2=A0 =C2=A0I would love your opini= ons and
> perspective.
>
> One obvious issue that jumped out at me is that it currently is quite<= br> > discouraged for a standards-track RFC to normatively reference non-SDO= work
> and part of this is the lack of clear policy around it.=C2=A0 =C2=A0Si= nce normative
> references basically restrict what technology can be built on top of w= hich
> and how, fixing this can give a means for the IETF to publish standard= s
> that use mature Open Source technology.
>
> Please take a look and discuss here what you think.=C2=A0 =C2=A0What t= hings did I
> miss (other than the typo for the=C2=A0 dedicated reviewers ;-) ?=C2= =A0 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.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Normative References in RFCs from Open Source
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Alia Atlas
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Eliot Lear
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Joel Halpern
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Heather Flanagan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Jeff Tantsura
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-atlas-external-normref-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2017-10-29
>
> Abstract:
>=C2=A0 =C2=A0 IETF procedures generally require that a standards track = RFC may not
>=C2=A0 =C2=A0 have a normative reference to a non standards track speci= fication
>=C2=A0 =C2=A0 except those from other
>=C2=A0 =C2=A0 standards bodies.=C2=A0 This document creates an External= Specification
>=C2=A0 =C2=A0 registry, similar to the DownRef registry that has been c= reated based
>=C2=A0 =C2=A0 on [RFC3967] and permits normative references to communit= y accepted
>=C2=A0 =C2=A0 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/dra= ft-atlas-external-normref-00
> https://datatracker.ietf.o= rg/doc/html/draft-atlas-external-normref-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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<= br>

--
---
tte@cs.fau.de

--001a11443e362ddf80055ccb7550-- From nobody Mon Oct 30 16:02:04 2017 Return-Path: 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 A8D1913FC6C for ; Mon, 30 Oct 2017 16:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU28zst8hJeV for ; Mon, 30 Oct 2017 16:02:00 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CACC650 for ; Mon, 30 Oct 2017 16:01:34 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9538958C4EA; Tue, 31 Oct 2017 00:01:30 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7A06BB0D02A; Tue, 31 Oct 2017 00:01:30 +0100 (CET) Date: Tue, 31 Oct 2017 00:01:30 +0100 From: Toerless Eckert To: Alia Atlas Cc: rtg-open-source@ietf.org Message-ID: <20171030230130.GW19957@faui40p.informatik.uni-erlangen.de> References: <20171030180448.GV19957@faui40p.informatik.uni-erlangen.de> 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-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:02:02 -0000 On Mon, Oct 30, 2017 at 06:49:57PM -0400, Alia Atlas wrote: > Yes - the primary discussion is happening on ietf@ietf.org. I raised it > here because I thought it was likely to be of interest. Not sure how detailled we can have a discussion there. ietf@ietf.org discussions are never sustained. At most it's the hot topic of the day/week. Better to move interested folks over. > > 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. Send an email around when you want folks to have a chat about it. Cheers Toerless