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

[Alexey Melnikov <[e-mail]>]

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

> On 9 Feb 2017, at 21:39, Rob Austein <[e-mail]> wrote:
> 
> At Wed, 8 Feb 2017 10:03:32 -0500, Alissa Cooper wrote:
>>>> On Jan 19, 2017, at 9:34 AM, Alvaro Retana (aretana) <[e-mail]> 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.
>