[sidr] Eric Rescorla's No Objection on draft-ietf-sidr-rpki-validation-reconsidered-08: (with COMMENT)
Eric Rescorla <ekr@rtfm.com> Sat, 26 August 2017 19:46 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0E4126E64; Sat, 26 Aug 2017 12:46:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.58.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150377679405.25829.10187635753258337816.idtracker@ietfa.amsl.com>
Date: Sat, 26 Aug 2017 12:46:34 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/voN16G-k3SgiKdqjEEUtVPDkkPs>
Subject: [sidr] Eric Rescorla's No Objection on draft-ietf-sidr-rpki-validation-reconsidered-08: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Aug 2017 19:46:34 -0000
Eric Rescorla has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- TECHNICAL S 4.2.4.4. Point 5 says: Section 4.2.4.2 or Section 4.2.4.3, or both. The value(s) for each of these extensions MUST satisfy the constraints established for each extension in the respective sections. Any extension not thus identified MUST NOT appear in certificate x. Assuming I am reading this correctly, you are saying that no other extensions at all can be added? That seems contrary to the point of extensions. The 4th bullet of point 7 says: * If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension. I think you mean AS Identifier Delegation Can you please clarify whether the new syntax defined in 4.2.2.2 and 4.2.2.3 is just the same syntax as in 6487 with a new OID? If not, can you please describe the differences clearly in this document? EDITORIAL It would help if the abstract were more clear about the problem you were trying to solve. 8. If there is any difference in resources in the VRS-IP and the IP Address Delegation extension on certificate x, or the VRS-AS and This might read better if it were "difference in resources between the..."
- [sidr] Eric Rescorla's No Objection on draft-ietf… Eric Rescorla