IETF Logo Mail Archive

Re: [Curdle] Adam Roach's No Objection on draft-schaad-curdle-oid-registry-02: (with COMMENT)

Jim Schaad <ietf@augustcellars.com> Thu, 25 January 2018 23:47 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B630A12EB02; Thu, 25 Jan 2018 15:47:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 LL-QiA9VhC1z; Thu, 25 Jan 2018 15:46:58 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422F612D779; Thu, 25 Jan 2018 15:46:58 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 25 Jan 2018 15:45:19 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Adam Roach' <adam@nostrum.com>, 'The IESG' <iesg@ietf.org>
CC: daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org, draft-schaad-curdle-oid-registry@ietf.org
References: <151683733787.15895.15630757079242805311.idtracker@ietfa.amsl.com> <009c01d3956e$95866370$c0932a50$@augustcellars.com> <0c489bdd-893c-04c8-2875-8aff11ab3581@nostrum.com>
In-Reply-To: <0c489bdd-893c-04c8-2875-8aff11ab3581@nostrum.com>
Date: Thu, 25 Jan 2018 15:46:50 -0800
Message-ID: <011001d39636$c7554150$55ffc3f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQE6+Vz8klSbXdx8LQNgOiRcw6p8HwF0/BhAArhVIISklQ9PAA==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/vF2Opsblml6Wk3Ddh3rJs1VePww>
Subject: Re: [Curdle] Adam Roach's No Objection on draft-schaad-curdle-oid-registry-02: (with COMMENT)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2018 23:47:01 -0000

I have issued a new version of the document that I believe picks up all of the comments made.  Given that the division for the OID tree has moved from Symantec to Digicert and the desire of Rick to update the text to reflect that I have changed the title of the document as well (also due to the nudge from Mirja).  If there are any issues please let me know.

Jim


> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Wednesday, January 24, 2018 4:00 PM
> To: Jim Schaad <ietf@augustcellars.com>; 'The IESG' <iesg@ietf.org>
> Cc: daniel.migault@ericsson.com; curdle-chairs@ietf.org; curdle@ietf.org;
> draft-schaad-curdle-oid-registry@ietf.org
> Subject: Re: Adam Roach's No Objection on draft-schaad-curdle-oid-registry-
> 02: (with COMMENT)
> 
> On 1/24/18 5:53 PM, Jim Schaad wrote:
> > Would adding the following lines be an adequate replacement?
> >
> > 0 - 99  | Retained by Symantec | [This RFC]
> > 128+   | Retained by Symantec | [This RFC]
> 
> Yep, that's good also.
> 
> 
> > I think this is more in line with normality that having a list of "this value
> open for registration".
> 
> 
> To be clear, I find your solution above to be fine without any additional
> changes; however, I would like to note that assignable ranges are handled
> both with and without explicit table entries; see the following for contrasting
> approaches:
> 
> https://www.iana.org/assignments/http-status-codes/http-status-
> codes.xhtml
> https://www.iana.org/assignments/sip-parameters/sip-
> parameters.xhtml#sip-parameters-7
> 
> /a

v2.23.0 | Report a Bug | By Email