Hi Rob, > On 31 Jan 2017, at 00:13, Rob Austein <[email protected]> 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. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
