I don't feel strongly about this either way, but... > On 9 Feb 2017, at 21:39, Rob Austein <[email protected]> wrote: > > At Wed, 8 Feb 2017 10:03:32 -0500, Alissa Cooper wrote: >>>> On Jan 19, 2017, at 9:34 AM, Alvaro Retana (aretana) <[email protected]> >>>> 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. > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
