[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..."