> On Aug 24, 2016, at 10:54 PM, Carsten Bormann <cabo@xxxxxxx> wrote: > > "Roy T. Fielding" <fielding@xxxxxxxx> writes: > >>> The document has a reference to obsolete RFC 2616, this is intentional. >> >> What is that supposed to mean? The reference is intentionally wrong? > > RFC 7252 is referencing RFC 2616 for its security considerations, > because the RFC 723x series wasn't out yet at the time CoAP was > completed. draft-ietf-core-etch references RFC 7252 for its security > considerations. This implies a reference to RFC 2616 as well, which we > decided to make explicit (it's hard to be explicit enough about security > considerations). We could change that to leave it implicit, rendering > the downref less visible. If you think security considerations are important, they should be included in the draft and specific to the additions made by that draft. Specifying them by reference to HTTP would have made sense if you had specified CORE semantics by reference to HTTP (instead, the method definitions were copied, which creates a fork of the protocol). Regardless, this draft does not change the security considerations of RFC7252 (nor 2616, nor 7230). There is no reason to reference considerations that are not applicable to the *changes* introduced by this draft. 7252 is already a normative requirement and its normative dependency on 2616 is not changed by 2616 becoming obsolete -- the text is effectively imported by reference. If there are NEW security considerations introduced by ONLY the addition of these two methods to the semantics of CORE, then that is what should be in the security considerations of this draft. Just that and a generic link to RFC7252's security section. Nothing else. >> I looked at the text and it should be referencing section 9 of RFC7231, >> not section 15 of RFC2616. Just fix the reference or remove it entirely > > While we could add RFC 7231 to the above reference (which, as I said is > already implicitly there), a single security considerations section out > of one of the RFC 723x documents does not cover the entire security > considerations of RFC 2616 (e.g., section 15.7 does very much apply, > some of which seems to have been moved to RFC 7234). Do you see > anything specific in RFC 7231 that we should cover that isn't mentioned > in RFC 2616? It doesn't matter -- they are not relevant to these two methods. If there is something relevant from HTTP caching, then just copy the text and make it specific to these two methods. HTTP semantics could have been used verbatim by CORE, without any changes, so a normative reference to RFC 7231 (HTTP Semantics) would have been appropriate IF the CORE methods and status codes were specified by reference and not forked into your spec. My long-term advice would be to delete 50% of CORE spec and replace that with normative references to HTTP, but I wouldn't bother until after HTTP/1.1 advances to Standard status. > We could use draft-ietf-core-etch more or less randomly as the point > where we finally clean up the editorial issues caused by the sharding of > RFC 2616. The authors so far did not see a reason to do that exactly in > this document, which describes functionality not really touched by that > sharding. Should we, anyway? No, we can't make updates to a proposed standard more or less randomly. They have to be within scope and reviewed by the right folks. Method specs (which define optional features to be deployed at leisure) are not the place to make updates to the underlying protocol. People who are not implementing a given method should feel free to ignore its specification. I would actually go further and say that these two methods should have been specified in two separate documents, but it's far too late for that comment. Cheers, Roy T. Fielding <http://roy.gbiv.com/> Senior Principal Scientist, Adobe <https://www.adobe.com/>