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

["Susan Hares" <[e-mail]>]

Juliusz: 

 

On my review: 

 

1) On management -  

 

Management considerations are like security considerations.  Something must be said in the protocol specification to help the reader find out how to manage the protocol. It is always within scope of a protocol specification. 

 

If you have specific management that is proprietary outside the IETF, this does not apply to the IETF.  If it is open and outside the IETF, you can point to it.  If you are going to manage with yang models, you can provide a short paragraph with your design and point to the yang models (just as Donald points to). 

 

The point is - give some consideration to how all those "knobs" are going to be managed.   Say something short, sweet, and substantive. 

 

2) On the summary  in the front 

 

If you think it is perfectly clear, then we are on a different page. My point was that it was incomplete and therefore gave the reader an unclear and incomplete set of statements.  I gave you a list of topics to provide additional points for.   You can disagree at any time with the review.  If you wish to simply disagree, please take that up with the chairs or your AD. 

 

I am reading this protocol without your years of work.  The purpose was to provide you with hints where a little work up front would clear out lots of required comments in sections 3 and 4. 

 

3) On the third part, I assumed some long-term routing background.  

 

Please let me know if you feel all the comments were unclear or what areas you want to provide a deeper set of comments.   

 

The reason I left some of this vague is that I thought that if you cleared up some the issues with #1 and #2, then the text would be easier to clear up in section 3 and 4.  If you feel section 2 is complete, well I disagree.  However, I can roll up my sleeves and send you a detailed comments on the sections 3 and 4. 

 

 

Cheerily, Susan  Hares 

 

 

-----Original Message-----
From: Donald Eastlake [mailto:[e-mail]] 
Sent: Saturday, January 6, 2018 11:13 AM
To: Juliusz Chroboczek
Cc: Susan Hares; David Schinazi; Alia Atlas; Russ White; [e-mail]
Subject: Re: RTG-DIR QA review of draft-ietf-babel-rfc6126bis-04.txt

 

Hi Juliusz,

 

On Fri, Jan 5, 2018 at 1:19 PM, Juliusz Chroboczek < <mailto:[e-mail]> [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   <mailto:[e-mail]> [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