Re: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11

"Paul Hoffman" <paul.hoffman@vpnc.org> Sun, 13 October 2019 17:29 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2612004A; Sun, 13 Oct 2019 10:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 suluGJpixMWh; Sun, 13 Oct 2019 10:29:41 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 2684D120024; Sun, 13 Oct 2019 10:29:41 -0700 (PDT)
Received: from [10.32.60.60] (50-1-98-250.dsl.dynamic.fusionbroadband.com [50.1.98.250]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x9DHSl5l086555 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Oct 2019 10:28:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-98-250.dsl.dynamic.fusionbroadband.com [50.1.98.250] claimed to be [10.32.60.60]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: ietf@ietf.org
Cc: draft-ietf-regext-bundling-registration.all@ietf.org, regext@ietf.org, secdir@ietf.org
Date: Sun, 13 Oct 2019 10:30:20 -0700
X-Mailer: MailMate (1.13r5655)
Message-ID: <4F9A6DFB-AF74-4578-924C-CB2E5D620331@vpnc.org>
In-Reply-To: <CALaySJ+_cGwUA94O8b09nU+qujQbPmBUGQATQmzpp-ko8SLoNA@mail.gmail.com>
References: <157071977760.20403.2267644082355726284@ietfa.amsl.com> <CALaySJ+_cGwUA94O8b09nU+qujQbPmBUGQATQmzpp-ko8SLoNA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/yYgeUxE8766RtXcE8G997SZqhoQ>
Subject: Re: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Oct 2019 17:29:43 -0000

On 13 Oct 2019, at 7:25, Barry Leiba wrote:

>> The Abstract ans Section 1 say: "This is a non-standard proprietary
>> extension." I understand that this is not a standards track document, 
>> so
>> the "non-standard" part makes sense.  However, what is the point of
>> publishing a "proprietary" extension as an RFC.  I would hope that
>> interoperable implementations is the goal of publication.
>
> I’m afraid this addition is my fault.  Perhaps “proprietary” is 
> the wrong
> word here: The point is that this is documenting an extension 
> developed by
> one registry and not in use by others, with the idea that if others 
> want to
> use it they can follow this to interoperable.  It’s rather like when 
> we
> documented Apple Bonjour as Informational.
>
> Better word?

Why have any word other than "non-standard"? It is *not* proprietary in 
that multiple vendors implement it and there appears to be no licensing 
requirement from the authors.

--Paul Hoffman