Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Sat, 4 Feb 2017 17:51:03 +0000

Hi Rob,

> On 31 Jan 2017, at 00:13, Rob Austein <[email-masked]> wrote:
> 
> [Sorry for delay, was out for a while with a nasty flu, still catching up.]
> 
> At Sat, 14 Jan 2017 10:56:17 -0800, Alexey Melnikov wrote:
> ...
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> I find the document to be a bit short on normative references and some
>> implementation details. Other than that the document looks fine. My
>> specific questions and concern are as follows:
>> 
>> 1) Please add a normative reference for HTTP, URI and RelaxNG on first
>> use.
> 
> Added, will be in -11
> 
>> 2) Base64 needs a normative reference (including the section number, as
>> there are 2 variants).
> 
> Added, will be in -11.
> 
>> 3) Section 2 says that all payloads use CMS. None of your examples show
>> CMS. Can you please elaborate on how CMS is used.
> 
> The short version is already in the running text (section "Protocol
> Specification" describes the CMS wrapping).   Not shown in examples
> because CMS is, um, rather verbose, and looks like dog food.
> 
> A full-blown exposition on use of CMS would look like RFC 6492 section
> 3.1 ("CMS Profile") and all of its subsections.  Sure you want that?
> 
> Should we incorporate RFC 6492 3.1 by reference?

Incorporating by reference is fine. When you show examples, I think you should add a sentence saying that CMS bits are omitted to make examples more readable. However, it would be a good idea to say who signs various CMS payloads in your examples.
> 
>> 4) How can URI of the service be discovered?
> 
> Out of scope, but draft-ietf-sidr-oob-setup would be one way.

I was thinking that defining a .well-known HTTP URI prefix would be a good idea in order to make this protocol play nicely with other HTTP based protocols. Plus it allows running different HTTP protocols on the same port.
> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> In 2.5: is the list of error reasons extensible?
> 
> Probably, given sufficient cause.

Then maybe add an IANA registry for it?
> 
>> Was Relax NG schema validated with a tool?
> 
> Yes, using trang and xmllint.

Good to know.
> 
>> In Section 5 you should reference the document, as IANA registrations cut
>> & pasted to IANA website as separate files.
> 
> Would be happy to do so but does not appear to be on IANA website.
> Chicken and egg problem?  Leave for RFC Editor?

IANA only does it once drafts are approved for publication as RFCs. So just add [[RFCXXXX]] and RFC Editor will fix this before IANA publishes the registration.

Best Regards,
Alexey.

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Feb 2017 15:21:00 +0900

> I was thinking that defining a .well-known HTTP URI prefix would be a
> good idea

it rarely is.  in this case it is a really bad idea.  the services are
not associated with the domain name; it is a coincidence.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Feb 2017 15:53:07 +0900

> not associated with the domain name; it is a coincidence.

<blush>  a friend "suggested" i be clearer.  :)

i run a publication server.  a half dozen CAs publish there.  only one
of the CAs has a domain name related to that of the publication server.

and having to futz around with the dns would be a non-useful pita while
provisioning.

to be clear, this stuff has nothing to do with bgp or the dns, unlike
92.3% of the rest of the internet :)

randy