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

[Rob Austein <[e-mail]>]

At Tue, 20 Dec 2016 14:24:27 +0000, Alvaro Retana (aretana) wrote:
> 
> 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.

There's a longer history behind it :)

This protocol started out circa 2010 as part of another non-IETF
protocol ("myrpki", which long since went to the big bit-bucket in the
sky).  So this is a revised protocol with semantics identical to the
useful subset of the "myrpki" protocol, with some syntax changes to
make the protocol operation clearer (some of the "myrpki" syntax
choices were obscure, to put it mildly, mea culpa).

All that said, this protocol in its current form has been in use for
years now, so there's deployed code which I'd really rather not break
if we can avoid it.

> 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.

Good catch(es).  If I recall correctly, XML attributes are an
unordered set, so "first" doesn't really make sense for attributes
(elements are a different story).  So my text cited in 4.1 is wrong.

That said, I agree that having attribute order in the examples agree
with attribute order in the text would be clearer.  Order in the
examples is arbitrary because the examples are produced by a program
which doesn't preserve ordering, but I think I know how to convince
the lxml library to use a particular order, so this is probably just a
small tweak to the example generator.

> 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.

A <parent_response/> containing both an offer and referrals would be
unusual, but I don't think it's illegal, nor can I think of any reason
why we should make it illegal.

> 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.

Yep, libxml2 RelaxNG, examples validated during compilation, same as
with the publication protocol.

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

Good catch.  Guess that should have been "syntax-error" rather than
"refused" :(.  Schema validation doesn't help here, as the schema
deliberately allows encapsulation of a non-compliant PDU (otherwise
"syntax-error" would be problematic).  Root cause is a bug in the way
the example generator constructs the error examples, will fix.

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

Grey area, since one can't generate some of the PDUs unless one can
generate X.509 and CMS, but I have no objection to changing these to
Informative if you prefer.