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

[Rob Austein <[e-mail]>]

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.

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.