Re: [irsg] An IETF repository for working code in our protocols?

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Thu, 20 August 2020 14:30 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62E03A09B8 for <wgchairs@ietfa.amsl.com>; Thu, 20 Aug 2020 07:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VV9/qA8h; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FTAI8tMt
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 SQdHM8N2ei6T for <wgchairs@ietfa.amsl.com>; Thu, 20 Aug 2020 07:30:55 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAA13A09AA for <wgchairs@ietf.org>; Thu, 20 Aug 2020 07:30:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11466; q=dns/txt; s=iport; t=1597933855; x=1599143455; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zXXN2VgyTI1hREPYT/0QYcdpOPwCksQ9U4DLrl+j6tQ=; b=VV9/qA8h7ku9z++DBmpU+PIx7Nn8RSNP5nse9y5S/p6q9sHPL+Lqp5E7 0kEkndYtHE6ivp+Pja1Ux4NVse21ci7hJVUA1MIMzgFSwQHSjryGiXj5k +eZoe4DVGDV4xg477PomWB9kboEoz6u9AntcQn3WlccnfaKV/kdm8w8Zw w=;
X-IPAS-Result: =?us-ascii?q?A0BNBwBEiD5f/4gNJK1VChwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFKgVJRB4FILyyEN4NGA41AJZhtgUKBEQNVCwEBAQwBAS0CBAEBhEwCF4IrA?= =?us-ascii?q?iQ4EwIDAQEBAwIDAQEBAQUBAQECAQYEbYVcDIVyAQEEEhERDAEBLgkBDwIBC?= =?us-ascii?q?BgCAiMDAgICMBQBEAIEAQ0FIoMEgkwDLgGmUAKBOYhhdoEygwEBAQWCSoMCG?= =?us-ascii?q?IIOCYEOKoJxg2KGTRuCAIERJwwQgU9QLj6EAw0tFyECgl0zgi2PSYM+ozYKg?= =?us-ascii?q?mOaIgMegwGJX4UyjhiSQJ9EAgQCBAUCDgEBBYFrI4FXcBU7KgGCPlAXAg1Yj?= =?us-ascii?q?UcMF4NOilZ0NwIGAQkBAQMJfJBRAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3AmtaqYRE9wGsYIhh3B5khJZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gGbX4LW7/JNj/LbqaamUmsFst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8X+14DoSEx?= =?us-ascii?q?HnOBBzYO/yH92ag8G+zevn/ZrVbk1Bjya8ZrUnKhKwoE3Ru8AajJEkJLw2z0?= =?us-ascii?q?7Co2BDfKJdwmY7KA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.76,333,1592870400"; d="scan'208";a="522317916"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Aug 2020 14:30:54 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 07KEUsCe032003 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Aug 2020 14:30:54 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 20 Aug 2020 09:30:54 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 20 Aug 2020 10:30:53 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 20 Aug 2020 09:30:53 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iSDV074enMLaNmS2S86z2dbsHehfMkYVDpKRT5PHvDq+fp9fwqQS7Erky880fdm869fK3GhZ5P0+o6f/cmDwFj/6T1PVtrYwUs/ecZFGVOwFP6ICdaqsXHeawekNqwqyguhKFoxBovY3mTcbP5qmAYxT/jECB4aoLyh1OW4HMC6AiTdyrrza6XdQ5b79Fk8mQ99jhvW0121jBjEbtM5yOD/DgigZJ3kqW39a/ai+6rC0mU5ocLCWudNQC4C4sCr9x+jNVfs7J+5sLveXas23I4GofRuzmYmUotHRp8D47BWoEcDuNA0d81xnrm962IXna/oGHskhxHaQiVdLeNhUWg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zXXN2VgyTI1hREPYT/0QYcdpOPwCksQ9U4DLrl+j6tQ=; b=hVU+tpJMBZ17QOxGdOTU01XI9rmlwrReIzPG1lnLBeWQpOQgf4tiE1Z/68RpvcFf/Aom6sPkK9Y3fh1JtAJxpDyHRFfCb5CO/YLexyQGj/nKp9J58KGMn0Wt4lwNJ05zlKUvmx/Hr5cRJHbe98e9SVb1EHAs1kYfpQuKN3pCgBs/DiG3e7EWpipR//Jk6oMM1imbsWqjsQhlZzuWiB0OYvdSj9RGez2gnBseFzBU70yCOlqOXdvHpoL247Wjf+Heg//hn3148hk+0FqY0dj4NRs6WKDJiEPuDF1aaROGyQ78OPalw8i/ijhzK7mbKs35bxEyf2wez4fVfW9fD/89oA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zXXN2VgyTI1hREPYT/0QYcdpOPwCksQ9U4DLrl+j6tQ=; b=FTAI8tMtcouJ8qWjjAYj37eCbfMGZcuG5sVpqLTclMX8odrT6PDgrKFeufxzcp180/kmQqzewQL7SHIamsmSgQTfPZI7nT+d3UMcI10P6fRMEx8K14/ZYoi10uEbj4Lnrc099u9lNay8tHZ4vsv2qbiIZXMT3wDW2nK0/QefTFE=
Received: from BYAPR11MB3237.namprd11.prod.outlook.com (2603:10b6:a03:1e::19) by BYAPR11MB2999.namprd11.prod.outlook.com (2603:10b6:a03:90::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Thu, 20 Aug 2020 14:30:52 +0000
Received: from BYAPR11MB3237.namprd11.prod.outlook.com ([fe80::d43b:cd64:b100:84b5]) by BYAPR11MB3237.namprd11.prod.outlook.com ([fe80::d43b:cd64:b100:84b5%7]) with mapi id 15.20.3305.024; Thu, 20 Aug 2020 14:30:52 +0000
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
CC: "wgchairs@ietf.org" <wgchairs@ietf.org>
Subject: Re: [irsg] An IETF repository for working code in our protocols?
Thread-Topic: [irsg] An IETF repository for working code in our protocols?
Thread-Index: AQHWdlVCxI8fqhJaDkmPR/oV4PiG7Kk/xXIAgAA8d4CAAAMSAIAABPWAgAAFCQCAAAkNAIAAgviA
Date: Thu, 20 Aug 2020 14:30:52 +0000
Message-ID: <C4B683BB-5660-49EA-ABEA-84A9705CCA30@cisco.com>
References: <81300C20-AC38-465C-A17C-743F3D4CD947@nbcuni.com> <CAMMTW_+P60jB-MLsB6R_x7z3uk5xK56ZwkZnHOtzaxex3tDREA@mail.gmail.com> <90cb740e-8663-58df-5c99-cbc053142566@joelhalpern.com> <a484f593-d037-ca9e-c4e9-6e28731b3152@cs.tcd.ie> <e6ae9107-48a9-cf04-2772-90b4b357fe3b@joelhalpern.com> <e99af73a-0ffa-f4e3-dcc8-6666066ceaa6@cs.tcd.ie> <536362ab-3a8a-d584-eb17-b5e8c927bfc6@joelhalpern.com>
In-Reply-To: <536362ab-3a8a-d584-eb17-b5e8c927bfc6@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.40.20081000
authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:4401:e580:6cbc:f6b6:aee0:54f0]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fd1fb3eb-58e1-445b-347c-08d84515a44c
x-ms-traffictypediagnostic: BYAPR11MB2999:
x-microsoft-antispam-prvs: <BYAPR11MB2999E32447E4EFE2F378BFC2B25A0@BYAPR11MB2999.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JcA1bbQyvU4s5VfvbdlQIJetL3f4iWpQEb22mM1kT1fyTO8rmNtP04ep+2GpZWXlyb+9g8vPzfVMJ9yTsPkQFmWV3jr3VsTElloXvEaWmS2TVq/RzDYA4EEEiTq55Atk0JucGGE5HoQw3uAYuwyoi53zzJ3iweNR+DjA3YM+JZnZC79tuCc0C4OLstrVRKo0tREuvk4bTNhe8+Gr32nbX60nTkbZuhQ1HJ5CWO+jFH3DO6AE2/B41IL5tne2TdRQT1PVG2Q3+8rXwBK/XPpNvZzBKgqkFsRGss/ELYgfEdZgScf1fCEEjWN+yjcSJuf3Lisp/MMQ5Ivf4xgaLMPE4g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3237.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(39860400002)(396003)(346002)(376002)(66476007)(5660300002)(8676002)(8936002)(66446008)(66556008)(76116006)(71200400001)(66946007)(83380400001)(33656002)(4326008)(2906002)(64756008)(6512007)(36756003)(2616005)(86362001)(6486002)(53546011)(186003)(478600001)(316002)(6506007)(110136005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: e496vVc+r31QJeLjmnJVdCmUdRderW5h3vkDLyfExH6Ulw0AjwraC6nJodORy6Ofq1eFxhHF+cllgKCD8UhkrvyernXr9A2Nb/i0gaLEOjTvaRToJ1ju68rtT/hlEpyyngZXBpaqA2je3ZwxeRiLyjuh9N+TjGmV08eWUX01UbmUmRqcAvZA5qohtShuxDsJrjlzpxNy3zBLOGEYCfna3vdV14Dh+ExVyX7Z7PBnAifr1bIrU4yriRYJmbyhDy5IZDJ3VUdWck+vS+/M+H/xqfh1oioXMndrQaLkC2LvlujTUVeAZO3aT3t9QTVoG82vc3jA/Jbk71Il5xiymzvi8/rtfBe00Z8KG4lKKxA+AaeHQQt2J23AkqSss0ScDwqXVGyfCNj1klTG+IAZxPA44tL53oRwDFFoDuSNRM2RXASzYNUYNPJXC2RX4WCTVHCEpePW2IAl9RIz2nBH6Q53PHX3KiP7SPEfehx25qgIT8FuqeYZ6zqvGZVmjXVmChbgfiiVidqcCwBnxW1sO0Lc3PEzsYUjICrKtH5A3sJ7BzV//GgRq6ssk0TFpVGxRqYfIyxf47gDUJhjYldTfcma95/qJbTlMqJOkhB2SVNQ4egdACJ8527aUz8d7ZN3XWBk2hBzjT1kzBCxpskNEoBFFLBbH8R//gLLTumkotgLz6Hy8vgbkMCLMQrmbzlL6fPUGnvH5c4pTnUmxhaWszDX6w==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <CA07ACBF3140744A9C24F42ED303F860@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3237.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fd1fb3eb-58e1-445b-347c-08d84515a44c
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2020 14:30:52.4323 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mr5pTN+Or+jvZGgfRGZBOxr1yWr+0SAwbB/psEHVH8l3Ta/4LoesZMj9a/BMXiV9Da0WyiSZ+32R9CavEzsjyQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2999
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/vEd9LnCUcth8pY693euIi__SBxc>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2020 14:30:58 -0000

Hi Joel,

Please see some thoughts inline [cue].

On 8/19/20, 4:42 PM, "WGChairs on behalf of Joel M. Halpern" <wgchairs-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:

    For IETF purposes, the existence of implementations is very important.
    For some purposes, open source code is useful.
    Depending upon the license, for many purposes looking at open source 
    code can actually be harmful to the implementation work.

[cue] I do not understand how this can be the case. Can you elaborate?

    If we want to make available pointers to specific versions of open 
    source, as well as pointers to the information about the implementation, 
    that is fine.  For many uses, it is as or more important to be able to 
    look at the implementors summary of what they actually support than it 
    is to look at the code.  For other purposes, looking at the code is 
    clearly useful.

    I am not asking that the IETF not point to such available code.
    I am asking that if we are going to identify implementations that we 
    identify implementations regardless of their status.

    I presume even for open source we will not attempt to verify the code 
    correctness, operability, or quality.  We are not talking about 
    reference implementations.  For different consumers of this information, 
    different implementations will have different value.  We do not 
    currently second-guess implementation or interoperability reports, and I 
    do not suggest we start.

[cue] For open source projects, this is traditionally done using a README file. As with any code, the quality of the documentation, and in this case the documentation typically starts with a README file, varies great. However, the place to but the status, quality, prerequisites, limitations, known issues, etc., all belong in the README, or in documentation pointed to from the README.

    As just one example, if I am looking for things to interoeprate with, I 
    may well be just as happy with commercial implementations as with open 
    source.  Maybe happier as I do not have to figure out how to build 
    someone else's structures.

    Archiving the soruce has many complications.  And very little value I 
    can understand.  After all, if it is open soruce, then it is available 
    somewhere else.  if the people making it available do not want to 
    continue to do so, it is not the IETF's job to take care of their code 
    for them.  Conversely, if they are interested in their work being 
    pointed to by the IETF, I am happy to see us do so.

[cue] My hunch is we should not archive code in general There may be exceptions, but most of the code I have in mind is not something we would want to archive. Rather, we want to make it easy to discover and access for those who might find it helpful. Perhaps some code is separate from the related RFCs and worth archiving. YANG models are an example. For the sake of argument and example, let's suppose we were to move YANG models out of RFCs and replace them ptrs to standalone code/YANG models that are archived. I can see this being helpful. There are of course pros and cons, and I am using this only as an example to hopefully explain my thoughts a bit more clearly.

Cheers,
Charles

    Yours,
    Joel

    On 8/19/2020 7:09 PM, Stephen Farrell wrote:
    > 
    > Hiya,
    > 
    > On 19/08/2020 23:51, Joel M. Halpern wrote:
    >> There is different value in open and closed source implementations.  But
    >> bother are valuable.
    > 
    > I maintain that, for implementers of RFCs, the existence of
    > open-source code is valuable in a way that closed-source
    > can never match. ISTM, that means OSS is inherently better
    > for the purpose we're discussing here.
    > 
    >> There is as far as I can tell no benefit in the IETF actually storing
    >> the source for these projects.
    > 
    > I disagree. Finding the commit that matches the time at
    > which the RFC was written can be non-trivial and will
    > sometimes be useful/needed.
    > 
    >>    Either they are being maintained or they
    >> aren't.  If they aren't, the source has much less value.
    > 
    > I disagree. For an implementer of an RFC, there is still a
    > lot of value in looking at someone else's code that matches
    > the RFC (or nearly does).
    > 
    >>   If they are,
    >> the maintained one is what people should look at.
    > 
    > Not necessarily. The not-very-good but easy to read code
    > that existed at the time the RFC was written might well be
    > the most useful thing for an implementer.
    > 
    >>
    >> So again, having an easily findable and easily maintained set of
    >> pointers to any implementations that folks want to list, with whatever
    >> terms those folks like (whether that be creative commons open source,
    >> GPL, or descriptions of proprietary implementations) seems very useful.
    >> The problem of findability is real, but is not different for an archive
    >> compared with a set of pointers.
    > 
    > Given the above, I fail to see how you can think closed-
    > source can be as useful there, regardless of the mechanism
    > for de-referencing a pointer.
    > 
    > Cheers,
    > S.
    > 
    > 
    >>
    >> A set of input / output vectors along the lines Erik suggested also
    >> sounds useful.  For some protocols.  (I don't quite know how one would
    >> do that for something like OSPF.)
    >>
    >> Yours,
    >> Joel
    >>
    >> On 8/19/2020 6:33 PM, Stephen Farrell wrote:
    >>>
    >>> Hiya,
    >>>
    >>> On 19/08/2020 23:22, Joel M. Halpern wrote:
    >>>> One of the advantages of pointers to implementations is that it can
    >>>> include equally pointers to open source and pointers to closed source of
    >>>> various forms.  The IETF doesn't take a stance among implementations.
    >>>
    >>> Entirely surmountable problem IMO. Add caveats to avoid
    >>> misperceptions wrt stance.
    >>>
    >>> That said, open source implementations are plainly more
    >>> useful for people who want to implement RFCs, compared to
    >>> equivalent closed-source implementations. It'd be folly
    >>> to ignore that reality.
    >>>
    >>> I just now discovered that what I thought ought be a
    >>> compressed-point representation of a DH shared secret is
    >>> supposed to use the uncompressed format thanks to being
    >>> able to add more trace lines to someone else's code. That's
    >>> the kind of thing could suck up many more hours of effort,
    >>> or that might lead to non-interop, (as it only affects some
    >>> groups), if no open-source code were available.
    >>>
    >>> S.
    >>>
    >>>>
    >>>> Yours,
    >>>> Joel
    >>>>
    >>>> On 8/19/2020 2:46 PM, Vijay Gurbani wrote:
    >>>>> Dear Glenn: Thank you very much for your note.  More inline.
    >>>>>
    >>>>> On Wed, Aug 19, 2020 at 1:19 PM Deen, Glenn (NBCUniversal)
    >>>>> <Glenn.Deen@nbcuni.com <mailto:Glenn.Deen@nbcuni.com>> wrote:
    >>>>>
    >>>>>       Hi Vijay,
    >>>>>
    >>>>>         In additional to the points others have made, I’ll add that an
    >>>>>       IETF code repository would need to carefully work out license
    >>>>> issues
    >>>>>       and also how it fits into the IETF’s Intellectual Property set up
    >>>>>       that is managed by the IETF  Trust.
    >>>>>
    >>>>>       [...]
    >>>>>
    >>>>>       There may be more that pop up once the topic was looked at deeper.
    >>>>>
    >>>>>       I’m not saying that any of these are show stoppers, but there’s a
    >>>>>       lot of legal elements that would be need to worked out before any
    >>>>>       bits got checked into a repository.
    >>>>>
    >>>>>
    >>>>> Yes, absolutely.  All of what you listed are important and weighty
    >>>>> concerns.  But none of them appear to be insurmountable if we decided
    >>>>> to do this.  Clearly, the precedent set by IEEE and ACM in similar
    >>>>> areas seems to point to the possible existence of a happy medium,
    >>>>> should we go this route.
    >>>>>
    >>>>> Cheers,
    >>>>>
    >>>>> - vijay
    >>>>>
    >>>>
    >>