Subject: [RTG-DIR] RtgDir review: draft-ietf-babel-information-model-11.txt

From: Geoff Huston <[email-masked]>
Date: Tue, 20 Oct 2020 21:21:31 +1100

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing
ADs. For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: raft-ietf-babel-information-model-11.txt 
Reviewer: Geoff Huston 
Review Date: date 
IETF LC End Date: 27 Oct 2020
Intended Status: Informational

Summary: 

No issues found. This document is ready for publication.

Comments:

This document provides an information model for the Babel protocol. It uses
a pseudo programming language like notation to enumerate a lisdt of objects
that collectively comprise the information model. It appears that the
primary purpose of this document is as a reference source for implementors
of this protocol.

This is not an easily readable document, but I believe that was never the
intention. This is a list of objects and the hierarchical structure in which
the objects are placed.

The document does not attempt to justify why these objects are listed here,
nor does it elaborate as to their intended role other than a brief
functional desription of the information that is denoted by the object.

Major Issues:

None

Minor Issues:

None

Nits:

It seems anomalous to this reviewer that it goes to the bit lengths of some
integer valued objects, yet leaves string objects undefined in terms of any
maximum length. 

"centiseconds"? Really? "tenths of seconds" would be clearer to most
readers!

---

From: Joe Abley <[email-masked]>
Date: Tue, 20 Oct 2020 06:53:12 -0400

(I am not on all these lists in the headers but I'll leave the recipient list intact anyway.)

> "centiseconds"? Really? "tenths of seconds" would be clearer to most

Perhaps this was intentional, but a centisecond is a hundredth of a second, not a tenth (just as a centimetre is a hundredth of a metre). A tenth of a second is a decisecond.

Centi- is a metric prefix recognised by SI (in which system the second is a base unit) so I think it's fair to say that centisecond is not an outlandish choice of unit, although millisecond would be more consistent in many engineering contexts.

But apparently the SI system units is not taught in schools everywhere even today (notably in much of the US) so maybe spelling it out as you suggest is reasonable. 

Joe

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 20 Oct 2020 11:13:27 +0000

Joe, Geoff and all,

Please see below the text from Section 5.2.7 of RFC 5798<https://tools.ietf.org/html/rfc5798#section-5.2.7> (VRRPv3):

5.2.7<https://tools.ietf.org/html/rfc5798#section-5.2.7>.  Maximum Advertisement Interval (Max Adver Int)

   The Maximum Advertisement Interval is a 12-bit field that indicates

   the time interval (in centiseconds) between ADVERTISEMENTS.  The

   default is 100 centiseconds (1 second).

I.e., the use of centiseconds as units of time in RFCs is not new.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]

-----Original Message-----
From: rtg-dir <[email-masked]> On Behalf Of Joe Abley
Sent: Tuesday, October 20, 2020 1:53 PM
To: Geoff Huston <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] [Last-Call] RtgDir review: draft-ietf-babel-information-model-11.txt

Joe

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 20 Oct 2020 14:49:20 +0200

> Perhaps this was intentional, but a centisecond is a hundredth of a second,

The wording is consistent with Section 4.1.2 of draft-ietf-babel-rfc6126bis:

   Relative times are carried as 16-bit values specifying a number of
   centiseconds (hundredths of a second).

It then goes on to justify this somewhat unusual choice of units:

   This allows times up to roughly 11 minutes with a granularity of 10ms,
   which should cover all reasonable applications of Babel

> maybe spelling it out as you suggest is reasonable.

I agree, a parenthetical remark to define the unit would be helpful,
simlarly to what is done in rfc6126bis.

-- Juliusz

---

From: Geoff Huston <[email-masked]>
Date: Wed, 21 Oct 2020 03:36:42 +1100

I’m was not raising an issue with the use of units of one tenth of a second - I was expressing the thought that the term “centisecond” is an unusual term in English, and as a native speaker I haver also followed a convention of using the units of “tenths of seconds”, “hundredths of a second” and then heading to milliseconds, nano seconds. Until now I had never seen the term “centiseconds” and I would claim that I am familiar with scientific English.

Its as if I used terms such as furlongs, chains and perches in an RFC - yes they are =units of measurement with a defined meaning but its not a commonly used term and it would look strange. I have a similar reation of centisecond (and decisecond).

But it's not my RFC and frankly I don't care all that much. The review template wanted my nits with the document so I provided my nits. I think the string nit is more critical than the one about the latin prefix for seconds. Why define some intergers as unsigned 16 bit values yet leave strings of undefined maximum length. Can I stuff a novel into the field? How about all of wikipedia? The point is why is the document inconsistent about its treatment opf the range of acceptable values in terms of size?

> On 20 Oct 2020, at 11:49 pm, Juliusz Chroboczek <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Oct 2020 10:20:38 -0700

> I’m was not raising an issue with the use of units of one tenth of a second - I was expressing the thought that the term “centisecond” is an unusual term in English, and as a native speaker I haver…

For what little it's worth, I think I have pretty solid credentials for
"familiarity with scientific English" (Ph.D. in Chemistry), and I find the
deci- and centi- SI prefixes to be completely natural.  It is perhaps
interesting that deca- and hecto- are not so natural, which I might ascribe
to the liter being a rather large volume on laboratory scales, so that
centiliters and deciliters are often used.

-Ben

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 20 Oct 2020 13:15:56 -0700

Hi Geoff,

Appreciate your review and pointing out the nits as you see them.

> On Oct 20, 2020, at 9:36 AM, Geoff Huston <[email-masked]> wrote:
> 
> Why define some intergers as unsigned 16 bit values yet leave strings of undefined maximum length. Can I stuff a novel into the field? How about all of wikipedia? The point is why is the document inconsistent about its treatment opf the range of acceptable values in terms of size?

The reason some variables have fixed length by virtue of the fact that they are unsigned int or unsigned short is because we have a better sense of what the range of those values are. For example, you do not want the babel-mcast-hello-interval to be more than 32 bit long. The same is not true for something like babel-interface-metric-algorithm, which is a name. While we could artificially limit the string value to say 40 characters, what is to say that someone cannot come up with a name that is 41 characters long.

Implementations of this information model, whether they are YANG data model or some other modeling language can choose to further restrict the size of the string. But even there, I have seen YANG models deferring it to particular implementations to refine the definition by adding a size attribute to the node. At an information model level we are poor judges of what size string is ok for any given variable.

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 20 Oct 2020 22:29:13 +0200

> Why define some intergers as unsigned 16 bit values yet leave strings of
> undefined maximum length. Can I stuff a novel into the field?  How about
> all of wikipedia? The point is why is the document inconsistent about
> its treatment opf the range of acceptable values in terms of size?

Right.  You may have a point.

The information model consistently limits integer values to the range
supported by the protocol -- e.g. where the protocol uses a 16-bit
unsigned field to carry a value, the information model specifies that the
value must not exceed 65535.

The string values, on the other hand, are not carried by the protocol --
they are strictly the private business of the management interface.  Their
size is only limited by a particular management interface, and whatever
protocols are used to carry the configuration data (e.g. whether your XML
parser is able to carry the full text of War and Peace within an attribute
value).

So where should their size be limited?  In the information model?  In the
YANG document?  In the release notes of a particular implementation of the
YANG model?  All of the above?

-- Juliusz