Re: [babel] Extension of Call for WG adoption of draft-ovsienko-babel-rfc7298bis through 2018-05-28

[Denis Ovsienko <[e-mail]>]

 ---- On Thu, 24 May 2018 21:29:59 +0100 Donald Eastlake <[e-mail]> wrote ----   
 > Hi,  
 > Commenting at a slightly higher level, although it is obviously up to the WG whether or not to adopt this draft, the replay discussion seem good and is typical of discussions that happen on security draft that have been adopted. So, I would say that the current questions would not, by most WGs, be considered a bar to acceptance.  
 > I have attempted to review the draft. It seems clear that a lot of work went into but it is very wordy and also has a lot of justification and design background material that usually does not appear in an IETF protocol specification. The "bits-on-the-wire" and any necessary state / state-machine at the end points are usually the focus for an IETF protocol specification.     The draft seems to provide a lot of implementation options. For example, quantities that can either be implemented as per-interface or implemented per-babel-speaker -- I would have said that if there is clear need for it sometimes being per-interface, then just specify it as always being per-interface. It's an operator interface issue, which is mostly not in scope for a typical protocol specification, whether or not to provide a command to set it for all interfaces or set a default or whatever.     On cryptographic algorithms, I think it should just say what you MUST/SHOULD implement and very briefly give the necessary characteristics for the crypto algorithms. Lots of detail about algorithms considered bad by the crypto community and listing possibly good algorithms that could be used does not seem necessary. Assuming this is adopted as an IETF Proposed Standard, or whatever, any future changes will be by a document that will go through the IETF process including security review and it should just be assumed that bad algorithms won't be approved in the future. There is no need to try to give commands about future IETF actions ("MUST NOT consider hash algorithms ... meaningful attacks exist or that are commonly viewed as deprecated") since they are unnecessary and unenforceable.     I have a number of other detailed suggestions that I am sending directly to Denis.  
 >   
  
Hello Donald and all.  
  
Thank you for the thorough review. There is indeed space for improvements in this document, which I am willing to discuss. Before responding on particular points let me clarify upfront that the -00 I-D of 7298-bis was derived from the -09 (last before the RFC) 7298 I-D, and my goal was to identify and try to fix problems in the core design first. The supporting text around it right now remains mostly inherited, consequently what was good in an Experimental document in 2014 in several cases is not yet good enough in a Standards Track I-D in 2018. But it all looks workable to me.

For the points you have made above: 

* Yes, 7298-bis does not need to have all the prose from RFC 7298, which ended up in the document due to a number of reasons, some of which no longer apply. That said, from my experience on the implementation side of this fence it looks like extra reasoning/background in the right place helps to get things right in the field. It would be nice eventually to have a document that strikes the right balance, I suggest to look at this again after removing some text.

* Leaving some implementation options out may be an improvement. In particular, for the outgoing TS/PC numbers this is a necessity, other points may be considered, you are welcome to make particular suggestions.

* For Section 2.1 (MTI and optional crypto hash algorithms), if the appropriateness considerations can be left up to the IETF, that would make the job a bit easier.

For the points you have made inline in the I-D text:

* Most of the I-D front page was automatically generated by the xml2rfc tool, the user has only limited control over the output, sorry.

* I appreciate general English proof-reading, RFC 7298 I-Ds incorporated as much of it as I could get from the reviewers, and still the RFC Editor team made one more round before the publication (that round is not in the 7298-bis I-D yet).

* Section 2.4 (HMAC definition) had to appear in RFC 7298 to identify and stop a technical error that was introduced in RFC 4822 and kept propagating into other RFCs. Now that it had served its intended purpose, in 7298-bis it should be OK to have just a reference to RFC 2104.

* Section 4.1 (updates to protocol encoding -> justification) had to appear in RFC 7298 to review the options and explain the design choice. Subsequent publication of RFC 7557 (now incorporated into 6126-bis) indeed made this section less useful and this is one of the things to fix (reduce/move/remove) in 7298-bis.

* The notes on byte order conversion (sections 5.3 and 5.4 and elsewhere) can be reduced in 7298-bis without impacting the document's normative quality. They were in RFC 7298 purely because of my experience with software developers that kept getting byte order wrong. That said, it should be good enough for 7298-bis to say about byte order about as much as a typical Standards Track document.

* RFC 7298 had Table 1 because the Babel protocol registry did not exist at that time. I agree that at the current time a document like this should refer to the existing registry.

Thanks.

--   
    Denis Ovsienko