Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT)

Alexey Melnikov <aamelnikov@fastmail.fm> Thu, 09 February 2017 22:03 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 695A6129CAA; Thu, 9 Feb 2017 14:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=OgtWVAgf; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Jq4OWlSl
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 iPFlhtUlV_Pa; Thu, 9 Feb 2017 14:03:50 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4FE127ABE; Thu, 9 Feb 2017 14:03:50 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7832D20C74; Thu, 9 Feb 2017 17:03:49 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 09 Feb 2017 17:03:49 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=hTV3mTiTWYEBkfb oODY+pbwWavs=; b=OgtWVAgfVILVGAoF4FTBNyIx4yzXuCQtw02plDheLeZjEXn MFs/sM/4v4TphU0VlbS3+7cNJr+GoODX+EEBurDg1ymcaSpuU6c5RWTIvTX/ZC2P clg+9S+xagZZPcYUATesBI1GaDKPri2r/4R6qFmcq7wIO6pWZYK99LKLu7So=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=hTV3mTiTWYEBkfboODY+pbwWavs=; b=Jq4OWlSl3P+mdyl/G4dA pMc3YuQbBQ505uX6SpswU5eSiJFptqL+/ces7c0cAeaAmYyaD2QW9geyDZq/vzKm yvEhJ8J0WUeSecS/L9NkmMKgQ9mmKwddeK8G2zml913Bk+x1CVpd3l6gTxn6wAgV MpoZRmIo7fRBhS5AugH7xeo=
X-ME-Sender: <xms:ReecWBFqOkmerzu2NrdCmkhrWxalrmsk50D9whwJ_JrJ0fKE5_ZPZQ>
X-Sasl-enc: gzG9o++U/TA99e1GHIzpkVgpZzgR0kGM+RVIVNETOxyU 1486677829
Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by mail.messagingengine.com (Postfix) with ESMTPA id F3AF67E077; Thu, 9 Feb 2017 17:03:48 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: iPad Mail (14A456)
In-Reply-To: <20170209213910.C39584684B49@minas-ithil.hactrn.net>
Date: Thu, 9 Feb 2017 22:22:18 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <544C672B-D26F-449F-9CC0-B861E787BAED@fastmail.fm>
References: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> <6549BAF8-95A7-42C6-A8E6-A80754DB2867@cisco.com> <F95A3287-C1F6-4BE1-840F-683DDF045ECE@cooperw.in> <20170209213910.C39584684B49@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/vdPB5KHS9NojeZoW75R92UIKl4o>
Cc: Alissa Cooper <alissa@cooperw.in>, Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, IESG <iesg@ietf.org>, sidr@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org
Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT)
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: Thu, 09 Feb 2017 22:03:51 -0000

I don't feel strongly about this either way, but...

> On 9 Feb 2017, at 21:39, Rob Austein <sra@hactrn.net>; wrote:
> 
> At Wed, 8 Feb 2017 10:03:32 -0500, Alissa Cooper wrote:
>>>> On Jan 19, 2017, at 9:34 AM, Alvaro Retana (aretana) <aretana@cisco.com>; wrote:
>>>> 
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> (1) I agree with Mirja that this document seems to be missing the actual
>>>> protocol specification, unless Section 6 is meant to provide the
>>>> normative specification of how the messages are to be exchanged. Is it?
>>>> If so, I would expect that to be explicit in the document.
>>>> 
>>>> (2) If there is in fact supposed to be a protocol specified here, I have
>>>> the same question as I had on draft-ietf-sidr-publication, which is how
>>>> do the entities migrate from one version to another and do version
>>>> negotiation?
>>> 
>>> Picking up from Benoit?s comment ? the use of ?protocol? is
>>> misleading.  What is described is a process that can be followed
>>> and the necessary information exchanged ?to simplify
>>> configuration?by setting up relationships and exchanging keying
>>> material used to authenticate those relationships.?
>> 
>> Is this going to be clarified in the document?
> 
> [Mostly offline this week, including a multi-day power outage, whee!]
> 
> With respect, I don't concede the point that this is not a protocol.
> 
> UUCP (RFC 976) and Batch SMTP (RFC 2442) were protocols, so is this.
> It has senders and receivers, rules for who initiates the conversation
> and what each party is allowed to say, and so forth.  The only things
> it doesn't have are a required underlying transport protocol and
> corresponding channel security mechanism.  These omissions are
> deliberate, as stated in the introduction (last two paragraphs).  As
> Stephen observe, it's a sneakernet protocol.

Right. I think you meant "protocol" in a more generic sense that is commonly used in IETF, but I think that is Ok. I think keeping the text as is is Ok.
> 
> Sections 5 and 6 are intended to be read together.  The explicit rules
> for what goes into each PDU are in section 5.2, but it's easier to see
> how the protocol operates with the worked examples in section 6.
> 
> The only thing I can see in re-reading this that looks unclear (to me)
> is that section 5.2.3 ought to state explicitly that it comes after
> the <child_request/> / <parent_response/> exchange.  This is sort of
> there already in implicit form (the <referral/> sub-element of the
> <publisher_request/> message requires an <authorization/> from the
> <parent_response/> message), but it probably ought to be explicit.
>