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

[Donald Eastlake <[e-mail]>]

Hi Denis

On Sat, May 26, 2018 at 3:15 PM, Denis Ovsienko <[e-mail]> wrote:
>  ---- On Thu, 24 May 2018 21:29:59 +0100 Donald Eastlake <[e-mail]> wrote ----
>  ...
>
> 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.

OK.

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

I think the different suggestions/options for generating TS/PC at
transmission are fine because they are handled in a uniform way on
receipt.

It seems particularly problematic to have configuration variables that
can be per-interface or per-babel-speaker. This will make any OAM
scheme significantly more complex.

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

I think they can in general. It's fine to have a sentence or two or
three about the characteristics of suitable algorithms and you
certainly need to indicate the initial mandatory or recommended to
implement algorithms. But lots of text and lists of good/bad
algorithms are not a good idea in my opinion. Such material can never
really be complete, will get out of date, etc...

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

OK. (I do my drafts in nroff so I am used to having, perhaps, too much
control...)

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

You're welcome. I actually found very few English errors and none,
that I can recall, that was likely to mislead anyone. Mostly there
just seem to be extra words and phrases thrown in, use of passive
voice, and the like. To some extent this is a matter of taste: it
gives the document more of a conversational tone but make it more
verbose and is something the RFC Editor staff is likely to want to
change anyway.

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

OK -- But I don't see how RFC 4822 could be a problem. Except maybe
for Errata, RFCs are immutable documents, like books a shelf. Even if
RFC 4822 updated RFC 2104, which it does not, that would only affect a
document referencing RFC 4822 or referencing RFC 4822 and RFC 2014. If
you just reference RFC 2104, they you just do what is in RFC 2104 and
even later updating RFCs that you do not reference are, at least in
principle, irrelevant.

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

OK.

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

OK. As I say, mentioning this just a couple of times and having a
worked example that developers can check against should be enough.

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

Ah, OK, guess I wasn't quite aware of the timing with respect to the registry.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Thanks.
>
> --
>     Denis Ovsienko