Re: [RTG-DIR] RTG-DIR QA review of draft-ietf-babel-rfc6126bis-04.txt

[Donald Eastlake <[e-mail]>]

Hi Juliusz,

On Fri, Jan 5, 2018 at 1:19 PM, Juliusz Chroboczek <[e-mail]> wrote:
> Dear Susan,
>
> Thank you very much for the kind words, and thank you for your review.
> Unfortunately, I cannot help but be somewhat puzzled.  As it currently
> stands, your review is not likely to help us improve the document.
>
> If I read your review right, it consists of three parts.
>
> In a first part, you comment about the lack of discussion of management.
> Rfc6126bis has a very precise scope: it defines the on-the-wire protocol
> and associated algorithms in a way that is sufficiently precise to enable
> independent reimplementation of the protocol in an interoperable way
> without overly restricting implementers' freedom.  It has arguably been
> successful with this goal: there are currently three independent,
> interoperable implementations of RFC 6126, at least two of which have been
> independently updated to comply with rfc6126bis.
>
> The Babel community has done a significant amount of work on management of
> Babel networks in a wide range of very different environments, some of it
> within the IETF, some of it outside, some of it publicly available, some
> of it proprietary.  I would be interested in discussing Babel management
> issues with you and Barbara in a separate mail exchange, or even on the
> mailing list.
>
> However, management issues are out of scope for rfc6126bis, which deals
> with the on-the-wire protocol only.  Hence, your comments about management
> in your review of rfc6126bis are somewhat puzzling to me, and do not help
> us improve the document.

Well, the title of rfc6126bis is simply "The Babel Routing Protocol"
and there are many in the IETF who would consider the specification of
a routing protocol that says nothing about management to be
incomplete. Management messages are sent on-the-wire. My apologies for
not thinking about this aspect earlier.

Let me point to one example, with which I am particularly familiar, of
how this was handled: In order to get the TRILL base protocol
specification (RFC 6325) approved, it was necessary to add one
paragraph near the front of the document (the last paragraph of
Section 2.1) and add Section 5 (RBridge Parameters). The added
paragraph starts with "Rbridges SHOULD support SNMPv3 [RFC3411]. The
Rbridge MIB will be specified in a separate document. ..." Of course
TRILL is not BABEL and RFC 6325 was some years ago but, for example,
saying that BABEL implementations SHOULD support NETCONF, a YANG model
will be in a separate document, and providing some specific
enumeration of the knobs (perhaps starting from the current Appendix
B) in the text does not seem that burdensome.

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

> In a second part, you comment about Section 2, the conceptual overview
> the protocol, and mention that it is incomplete.  I have re-read this part
> carefully, and I think that it is perfectly clear that this part is not
> meant to be exhaustive; for what it's worth, none of people independently
> reimplementing Babel have been confused by that.  (As a matter of fact,
> you missed the most important simplification that's done in that section
> -- we use a mesh model there, rather than the more complicated but more
> realistic link model used on the Internet and hence used by the protocol
> description in Section 3.)
>
> I think that it is important that Section 2 remains concise and readable.
> Hence, I disagree with your comments about triggerred updates or technical
> details of the packet format needing to be described in Section 2.  Doing
> that would not improve the document.
>
> In a third part of your review, you make a fairly large number of comments
> about particular issues you have with this document.  Unfortunately, your
> comments range from incomplete ("but I am not sure you’ve caught all the
> problems") through cryptic ("however the details are not there") to
> somewhat enigmatic ("there is no list in the beginning on what
> algorithms").  While we can guess in many cases what you mean, I don't
> think that this list is precise enough for us to work with in order to
> improve rfc6126bis.
>
> Dear Susan, I realise that you are a busy person.  However, I would like
> to strongly encourage you to send us another review, one that fits the
> scope of rfc6126bis and is precise and detailed enough to help us improve
> the document.
>
> Thank you very much for your help,
>
> -- Juliusz