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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 20 Dec 2016 14:24:27 +0000

Rob:

Hi!  How are you?

I just finished reading this document.  Thanks for the work!

I have some comments (below) that should be easy to address.  I think the major one is about the ordering of the XML attributes (C2); I’ll start the IETF Last Call once (at least) that point is resolved.

Thanks!

Alvaro.

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.

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.

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.

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.

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

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

---

From: Rob Austein <[email-masked]>
Date: Tue, 20 Dec 2016 12:33:36 -0500

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:

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.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 20 Dec 2016 20:55:25 +0000

On 12/20/16, 12:33 PM, "Rob Austein" <[email-masked]> wrote:

| 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 :)

Ok, please include some of that in the document.

…

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

…

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

Yes, you’re right.  When I looked into it I didn’t notice the difference between attributes and elements.  ☹

I’ll go ahead and start the IETF Last Call.

…

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

If it is not illegal, what should the child do?

In Section 5 you hinted at the fact that Bob could choose.  Please make that clear – it would also be a good idea to include some of the considerations that may come into play when deciding.

Thanks!

Alvaro.

---

From: Rob Austein <[email-masked]>
Date: Tue, 20 Dec 2016 20:14:42 -0500

Proposed -05, reflecting comments from AD review:

  https://subvert-ietf.hactrn.net/rpki-oob-setup/draft-ietf-sidr-rpki-oob-setup-05.txt
  https://subvert-ietf.hactrn.net/rpki-oob-setup/draft-ietf-sidr-rpki-oob-setup-05-from-04.diff.html

Absent objections, I will post to I-D repository, probably tomorrow.

Note for anybody going over the changes with a fine-tooth comb: there
was one minor correction which could be construed as substantive.
It's purely a syntax issue, with no effect on protocol semantics.  The
textual description of the <authorization/> token reflected an earlier
version of the protocol syntax in which there was an extra <bpki_ta/>
element nested within the <authorization/> element.  This changed some
time ago in the schema, the examples, and the running code, but
apparently nobody (including me) noticed the old syntax lurking in the
text.  Had this come up after publication I would called it an
erratum, but since we caught it now, I just went ahead and fixed it. :)

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 21 Dec 2016 12:20:54 +0000

Rob:

Hi!

You added some text about offer and referral:

  A parent is unlikely to need to send both <offer> and <referral>
  elements, but strictly speaking they are not mutually exclusive, so a
  parent which really needs to express that it both offers repository
  service to its child and is also willing to refer its child to one or
  more other repository servers can do so.

That’s fine, but it still doesn’t tell me what the child should do.  I don’t think you want to specify taking up one or the other, but at least include some text that says that the child can choose.

In thinking about this I came up with another question.  A repository doesn’t have to honor every publisher_request it receives, right?   Specially ones that are the result of a referral…  There is a “refused” error reason defined, so that takes care of that…but I’m thinking that as a client I might want to take an <offer> instead of playing around with a <referral> because I know for sure my parent can do the job.  I’m sure there are other considerations that the child should take into account.  I’m ok if you just write that the selection criteria is out of scope.

Thanks!

Alvaro.

On 12/20/16, 8:14 PM, "Rob Austein" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Rob Austein <[email-masked]>
Date: Wed, 21 Dec 2016 13:13:23 -0500

At Wed, 21 Dec 2016 12:20:54 +0000, Alvaro Retana (aretana) wrote:
...
> it still doesn?t tell me what the child should do.  I don?t think
> you want to specify taking up one or the other, but at least include
> some text that says that the child can choose.
> 
> In thinking about this I came up with another question.  A
> repository doesn?t have to honor every publisher_request it
> receives, right?   Specially ones that are the result of a referral?
> There is a ?refused? error reason defined, so that takes care of
> that?but I?m thinking that as a client I might want to take an
> <offer> instead of playing around with a <referral> because I know
> for sure my parent can do the job.  I?m sure there are other
> considerations that the child should take into account.  I?m ok if
> you just write that the selection criteria is out of scope.

I just added this to the end of "Protocol Walk-Through":

      <t>
        Any RPKI operator is free to run their own publication service
        should they feel a need to do so, and a child need not accept
        any particular &lt;offer/&gt; or &lt;referral/&gt;.  In
        general, having a smaller number of larger publication
        repositories is probably good for overall system performance,
        because it will tend to reduce the number of distinct
        repositories from which each relying party will need to fetch,
        but the decision on where to publish is up to individual RPKI
        CA operators and out of scope for this protocol.
      </t>

> Absent objections, I will post to I-D repository, probably tomorrow.

I think we are close enough at this point that I will push this
version this afternoon.  Can always do another rev if we must, but I
want to get these changes into the version that directorates are being
asked to review.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 21 Dec 2016 18:50:26 +0000

Yes, I’m good.

Thanks!!

Alvaro.

On 12/21/16, 1:13 PM, "Rob Austein" <[email-masked]<mailto:[email-masked]>> wrote:

I hope this addresses the issue.