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

Barry Leiba <barryleiba@computer.org> Sun, 13 October 2019 18:11 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A617312003F; Sun, 13 Oct 2019 11:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.477
X-Spam-Level:
X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 O5GnYIlQfvEU; Sun, 13 Oct 2019 11:11:17 -0700 (PDT)
Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (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 2792D120024; Sun, 13 Oct 2019 11:11:17 -0700 (PDT)
Received: by mail-io1-f52.google.com with SMTP id b136so32721254iof.3; Sun, 13 Oct 2019 11:11:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/bgtgR5X8HdgFIeiLm1KguLQzKtLOAqdaIESitfgatU=; b=LTIIN3Og4o3pEj39eyz1OHShHEGT4a+QwyX7OLZaGabdoeOV3TX5nFXk5MK+LlV8ft zA3RWiRGvAN8Gw63b3jbtkNqMpZYi07ZmxnyrOFSpJEqBk/eJVwnpfMYb0zBAayduLaA xcv0/yawLC6h4jlJ43t8NTln4FEiU5jW5OK7xFTjIb/9r0+95CW3gP2ciFRQlwmi1LrR hbNqhi2mEhgj/DetyOIuSh58lKqx+IJ1cn28StK/JDhs0KuJYdwUFpoRpt5v2rwAFdWO chzl6yl2UxZC/z4lOB9UFLbb5jQ7pfU3FRQMgK2AY4sgvpIOpTP5SKHZ7vCiesQRfH1f 1e2Q==
X-Gm-Message-State: APjAAAUJ4hHogaXVlzKMNdkk1o5JXKgMxiq0ED/Cb8ljxX6pUdaxPFMC 1jgzb4fClzE1qVPGqYA6YCzSKD5fvHxbigHQ9PJ24SvN
X-Google-Smtp-Source: APXvYqy4Rb78dUEZYJffTWUZyo9I6qwM5Y55bhCuRkNpxygGCbo040DEcF4kK8lO6yz4KXl4mWFIU6RR4rfvMUOvlOg=
X-Received: by 2002:a6b:7f01:: with SMTP id l1mr15087694ioq.90.1570990276026; Sun, 13 Oct 2019 11:11:16 -0700 (PDT)
MIME-Version: 1.0
References: <157071977760.20403.2267644082355726284@ietfa.amsl.com> <CALaySJ+_cGwUA94O8b09nU+qujQbPmBUGQATQmzpp-ko8SLoNA@mail.gmail.com> <4F9A6DFB-AF74-4578-924C-CB2E5D620331@vpnc.org>
In-Reply-To: <4F9A6DFB-AF74-4578-924C-CB2E5D620331@vpnc.org>
From: Barry Leiba <barryleiba@computer.org>
Date: Sun, 13 Oct 2019 20:11:03 +0200
Message-ID: <CALaySJKXJ6FkmcnJ5A0t14L+_TZ5gf_=mpGyO67QSyiB7ciEmg@mail.gmail.com>
Subject: Re: Secdir telechat review of draft-ietf-regext-bundling-registration-11
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org, secdir@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005925c00594ceadc4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/bp2EZ-eHTJgOvWznYqy8sKEdRZE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Oct 2019 18:11:19 -0000

Works for me: I had suggested “proprietary”, so I will now unsuggest it.
Authors, sorry about that: please remove that word in both places the next
time you make a revision.  Thanks.

Barry

On Sun, Oct 13, 2019 at 1:29 PM Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> 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
>