[sidr] AD Review of draft-ietf-sidr-rpki-oob-setup-04

"Alvaro Retana (aretana)" <aretana@cisco.com> Tue, 20 December 2016 14:24 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE851298A6; Tue, 20 Dec 2016 06:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.621
X-Spam-Level:
X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 CVLzCw5o9OzN; Tue, 20 Dec 2016 06:24:37 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2461298A8; Tue, 20 Dec 2016 06:24:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12162; q=dns/txt; s=iport; t=1482243869; x=1483453469; h=from:to:cc:subject:date:message-id:mime-version; bh=xmYUmBQyKbZQdnQkIHN+SjlaoGcTkI+3/r0LDKRBPVU=; b=NQQ+OR3lRG9wR+N0QRvLq12cTaV/b4lL9kU0JdO/5kMfC6m4dy+B/9rA JyzOxD0dVXJlHY9Tf6yK62I7qT4tBY3QBHM1jpwctIjrTqIXeDVd3E+B4 Hyx5W5v/ZGsung1Z+yZJKQ1bJx7EaGJffODfICP0aH/x0SmVWgvmf1aic c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAgBrPllY/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNEAQEBAQEfWoENtAyFJYIKhiIcgUlAEwECAQEBAQEBAWIdC4R?= =?us-ascii?q?rBBIRCkwSAUoCBDAnBA4niEmbVwGNdoIoL4pqAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHYY2gX2KIC2CMAWVA4VtAYljh1CBdIUDiVaSJwEhATSBJjsBhUqIV4ENAQE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.33,379,1477958400"; d="scan'208,217";a="183681605"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2016 14:24:28 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uBKEOSts010397 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Dec 2016 14:24:28 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Dec 2016 08:24:27 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 20 Dec 2016 08:24:27 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-sidr-rpki-oob-setup@ietf.org" <draft-ietf-sidr-rpki-oob-setup@ietf.org>
Thread-Topic: AD Review of draft-ietf-sidr-rpki-oob-setup-04
Thread-Index: AQHSWszFsmJTivNev0GoI5fThLpGTA==
Date: Tue, 20 Dec 2016 14:24:27 +0000
Message-ID: <C219759D-6DE4-4B23-95C3-E39156FEAFC2@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: multipart/alternative; boundary="_000_C219759D6DE44B2395C3E39156FEAFC2ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/7CVR8nmORPDSs6N8T0HJr_TQI2c>
Cc: Chris Morrow <morrowc@ops-netman.net>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: [sidr] AD Review of draft-ietf-sidr-rpki-oob-setup-04
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Tue, 20 Dec 2016 14:24:39 -0000

Rob:

Hi!  How are you?

I just finished reading this document.  Thanks for the work!

I have some comments (below) that should be easy to address.  I think the major one is about the ordering of the XML attributes (C2); I’ll start the IETF Last Call once (at least) that point is resolved.

Thanks!

Alvaro.


C1. Why isn’t an IETF namespace [RFC3688] used in the XML schema?  I would strongly suggest that you use one and request it in the IANA Considerations Section.  Unlike the publication protocol, this document specifies version 1 – which of course doesn’t mean there isn’t a longer history behind it, so I’m open to keeping a non-IETF namespace if that is the case.

C2. Section 4.1. (Common Protocol Elements) says that “The first XML attribute in each message is a version field.”, and Appendix A. (RelaxNG Schema) reflects that.  However, the examples (throughout the document) don’t reflect the same ordering.

C2.1. It would be very nice if the description of the fields was in the same order as what the schema defines.  For example, the schema says that for a child_request the order is: version, child_handle, tag and child_bpki_ta, but the text in 4.2.1. (<child_request/>) reverses the tag and child_handle.

C3. In 4.2.2. (<parent_response/>), are the offer and referral elements mutually exclusive?  What happens if the client receives a parent_response with both?  If it is an error, is it considered a syntax-error or something else?  Section 5. (Protocol Walk-Through) offers a hint (“Bob doesn't have to accept Alice's offer, but may choose to do so.”), but the specification is still not clear.

C4. The Shepherd’s write-up doesn’t mention any XML checks done, but I suspect this step has in fact happened.  Please provide details so the Shepherd can complete the writeup.

C5. The example in Section 4.4. (<error/>) doesn’t include the complete child_request message which presumably caused the error.

C6. I think the following references can be made Informative: RFC5280, RFC5652.