Subject: [netmod] Units

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 10 Jul 2008 16:15:17 -0400

Hi

I think we should standardize on a small set of units, while not
precluding people from inventing their own (I've always been fond on
nano-parsecs). This will avoid the sec, second, seconds, scnds, s
problem.

Here is the text from NETCONF DSDL

"      NOTE: It is recommended that the symbol be an identifier for a
      unit of measure as specified in the Unified Code of Units of
      Measure (UCUM) [13] (http://aurora.regenstrief.org/UCUM).  This
      provides a set of symbols and a grammar for constructing
      identifiers for units of measure that are unique, and may be
      easily entered with a keyboard supporting the limited character
      set known as 7-bit ASCII.  ISO 2955 formerly provided a
      specification with this scope, but was withdrawn in 2001.  UCUM
      largely follows ISO 2955 with modifications to remove ambiguities
      and other problems.
      URL for GML specs is: http://www.opengeospatial.org/standards/gml"

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Thu, 10 Jul 2008 15:30:52 -0700

>       URL for GML specs is: http://www.opengeospatial.org/standards/gml"

I agree with you (!)
My only concern is that a SMIv2 UNITS clause converted to a
YANG units-stmt maintains the same semantics for the same string
value. (I don't know if this UCUM spec accounts for SMIv2.)

Since this is an XML-wide issue, not a NETCONF issue,
the actual solution will probably require a separate RFC.

> Canada

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 10 Jul 2008 19:40:28 -0400

>>       largely follows ISO 2955 with modifications to remove ambiguities

Just skimmed the spec (http://aurora.regenstrief.org/~ucum/ucum.html)
and am not sure what to make of it.
found none of this to be true.

It's not 7-bit ascii (Angstrom).  It allows for subscripts and other
weirdnesses.  The intro says:

    The Unified Code for Units of Measure is inspired by and heavily
    based on ISO 2955-1983, ANSI X3.50-1986, and HL7's extensions
    called ISO+. The respective ISO and ANSI standards are both
    entitled Representation of [...] units in systems with limited
    character sets where ISO 2955 refers to SI and other units
    provided by ISO 1000-1981, while ANSI X3.50 extends ISO 2955
    to include U.S. customary units. Because these standards carry
    the restriction of limited character sets in their names they
    seem to be of less value today, when graphical user interfaces
    and laser printers are in wide-spread use. For this reason, the
    european standard ENV 12435 in its clause 7.3 declares ISO 2955
    obsolete.

So it's specifically _not_ restricting itself to text.

It's also defining a grammar as well as a set of units, so it
supports constructs like "mg/(8.h.kg)" (milligram per kilogram and
8-hour shift) and "m[iU]/mL" (milli-international unit per milliliter).

It does handle the multiple definitions of units like "yard",
with names like "yd_br", "yd_i", and "yd_us", but I don't
know that "units d;" is gonna win the d.  We'll have to sit
for a few h with a Queen Anne's wine barrel of beer and put
some cal_[15] into thinking about this.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 10 Jul 2008 17:17:20 -0700

> some cal_[15] into thinking about this.

I should have said I agree with the goal of selecting some
set of standard units, and use external definitions for
the semantics of those units.  The IPPM WG has already
done work in the area of complex units.

The more I search online, the more standards I find
to choose from here.  This is a huge can of worms.

IMO, all the YANG spec should say is:
   * There SHOULD NOT be any leading or trailing whitespace
     in the units-stmt
   * Fully spelled out words SHOULD be used, and abbreviations
     SHOULD NOT be used
   * A single space character (0x20) SHOULD be used to separate
     multiple words in a units-stmt
   * Accepted standard units of measure names SHOULD be used whenever
     possible.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 10 Jul 2008 21:45:48 -0400

>   * Accepted standard units of measure names SHOULD be used whenever

I'm not sure that single space isn't a CLR, but otherwise this
is a good list.  I'd add:

    * Units should be in plural form, where appropriate

This gets us feet, seconds, meters, meters per second, parsecs per
gallon, angels per square nanometer, and chicken per pot.

I see this as documentation, not a basis for automatic conversion.
Using standard words in standard formats is more about consistency
and readability.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Jul 2008 09:20:38 +0200

>> nano-parsecs). This will avoid the sec, second, seconds, scnds, s

I just did run a simple awk script to extract the UNITS clauses from
ALL IETF MIB modules and what I found looked pretty consistent. So
obviously MIB reviews have so far dealt with the problem.

For me, such rules make sense if there is a way to automatically check
them. Otherwise, you end up relying on human MIB reviews anyway.
Anyway, I would support clearly anybody who wants to go ahead a write
a decent RFCs about units that defines the general rules for
representing units and establishes an IANA registry (ideally in a
machine readable format) where units can be registered. Once this is
in place, we can rely on it and use it in other standards.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 11 Jul 2008 10:30:57 +0200

Hello,
I would be very reluctant to include by reference 100 pages of an external standard (any 
standards) unless  it is absolutely needed. One strong point of YANG is it's concise nature. If 
you have to read extra 100 pages for units, brrr ...
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 11 Jul 2008 10:13:32 -0400

Hi

That argument doesn't really make any sense to me. But let me first say
that my point is we need to standardize on units. How we do it once we
agree this is a good goal is the continuation of the discussion. I
personally have not made any decisions on whether I like or dislike the
approach on units that I quoted, but it does seem like a nice review of
some very relevant existing work.

The idea that we reinvent things so that we can get it all defined in a
single 800 page specification is just nuts to me. There are good reasons
to reinvent, but this just isn't one from my perspective.

Sharon  

-----Original Message-----
From: Balazs Lengyel [mailto:[email-masked]] 
Sent: Friday, July 11, 2008 4:31 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [netmod] Units

Hello,
I would be very reluctant to include by reference 100 pages of an
external standard (any
standards) unless  it is absolutely needed. One strong point of YANG is
it's concise nature. If you have to read extra 100 pages for units, brrr
...
Balazs

Sharon Chisholm wrote:
>       URL for GML specs is:
http://www.opengeospatial.org/standards/gml"

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 11 Jul 2008 16:23:06 +0200

Hello,
I don't want to reinvent the wheel, but I would also like to avoid being forced to read 
hundreds of extra pages, so something like UCUM should be a SHOULD or a MIGHT in the RFC but 
hopefully not a MUST.

Reinventing the wheel is nuts, but if we end up with an 800 page specification (or more) YANG 
is doomed. How long is SMI?

Balazs

---

From: "tom.petch" <[email-masked]>
Date: Fri, 11 Jul 2008 15:10:35 +0200

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 11, 2008 3:45 AM
Subject: Re: [netmod] Units

>     * Units should be in plural form, where appropriate
I would do the exact opposite, namely all units should be in single form,
always.  I believe it improves recognition, ease of searching for in documents,
and, once upon a time, I was taught that it was the recognised correct form
(probably an undergraduate engineering course).

I am with Andy that, in principle, this is a good idea, and I do like the single
space (thinking of the mess that other I-Ds have got into with what is white
space).

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Jul 2008 19:29:33 +0200

On Fri, Jul 11, 2008 at 03:10:35PM +0200, tom.petch wrote:

> I am with Andy that, in principle, this is a good idea, and I do
> like the single space (thinking of the mess that other I-Ds have got
> into with what is white space).

I once again like to encourage everybody to extract all the SMIv2
UNITS clauses from all IETF MIB modules and after taking a look at the
result I like to see a clear problem statement what is broken and how
it is going to be fixed (and include in that how you plan to enforce
any new rules).

Given all the important open issues I see, I am wondering why we
should spend time improving the UNITS clauses. I am not saying there
is no value - I am just at odds with the priorities.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jul 2008 11:10:20 -0700

> it is going to be fixed (and include in that how you plan to enforce

I just did a grep on a subset (~40 MIBs) and noticed a few things:

  - capitalization is not consistent with YANG, which aggressively
    utilizes lower-case letters
  - there were multiple variants, even in this small subset,
    most notably Milliseconds, milliseconds, and milli-seconds.
  - there were no complex units of measure, not even 'packets per second'.
    Maybe SMIv2 UNITS is too restrictive, and YANG should
    support these complex units? It should not forbid them, at least.
  - vendor MIBs are not reviewed by MIB Doctors, and many more
    inconsistencies exist in vendor MIBs. YANG needs to support
    standard and vendor data models.

> is no value - I am just at odds with the priorities.

NASA thinks they found the wreckage of the Mars Polar Lander:
http://www.skyandtelescope.com/news/3310281.html

I am not proposing that YANG attempt to have some official list
of units.  I think a list of CLRs could help tools and humans
maintain a less ambiguous set of units than no rules at all.
Clearly, comparing the strings "meters" to "feet" would have
helped in this example.

BTW, I prefer the plural form, as Phil suggests,
and even lower-case letters and numbers only.
This is more recognizable, e.g. 'foot per second'.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Jul 2008 21:09:40 +0200

>    support these complex units? It should not forbid them, at least.

SMIv2 UNITS too restrictive? Here is what RFC 2578 says:

   This UNITS clause, which need not be present, contains a textual
   definition of the units associated with that object.

I do not think this can every be considered too restrictive. ;-)

>    standard and vendor data models.

So you want tools to check the content of units statements and to
generate warnings (failures??) if there is something unknown showing
up.  I assume if we collect some say 20-30 common strings that have
been used in the SMIv2 space so far (and we list them say in the
appendix of YANG), we likely cover 90% of what will show up in the
networking space.

I am attaching my top N list of UNITS strings extracted from IETF
SMIv2 MIB modules. Also note that there are some strings that are
perfectly valid if you ask me and pretty much outside of any
scientific units.

/js

---

From: Phil Shafer <[email-masked]>
Date: Fri, 11 Jul 2008 15:20:50 -0400

>perfectly valid if you ask me and pretty much outside of any

Here's the same data for JUNOS.  Shockingly boring.

Thanks,
 Phil

 242 seconds
  86 milliseconds
  43 bytes
  42 minutes
  22 bits per second
  21 percent
  14 bps
  12 microseconds
   7 kilobits
   7 degrees C
   6 packets
   5 ms
   5 kilobits per second
   5 kbps
   5 cells
   3 kilobytes
   3 dB
   2 seconds to a power of 2
   2 pps
   2 per second
   2 hours
   2 hops
   2 feet
   2 error(s) per second
   1 time in microsecond
   1 second
   1 priority
   1 megabytes
   1 megabits per second
   1 error(s) per 100 symbol
   1 error(s) per 100 frames
   1 bits
   1 baud
   1 YYYYMMDD
   1 HHMMSS
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jul 2008 12:26:31 -0700

> perfectly valid if you ask me and pretty much outside of any

The issue seems to be whether the units-stmt is just a
specialized description-stmt (like reference-stmt is),
or whether it can be useful to applications as well.

Humans are much better at string matching milli-seconds
and Milliseconds than machines.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Jul 2008 13:31:23 +0200

> http://www.skyandtelescope.com/news/3310281.html
To this end, it would be even safer to include the units in the instance
documents (NETCONF PDUs). Would it be too much to assign an XML
representation to units-stmt? The least intrusive seems to be an
optional XML attribute whose value, if present, must be exactly what is
prescribed by the units-stmt. For example

leaf max-lease-time {
   type uint32;
   units seconds;
   default 7200;
      }

would allow either

<max-lease-time>1200</max-lease-time>

as before, or

<max-lease-time units="seconds">1200</max-lease-time>

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Jul 2008 08:01:25 -0700

> <max-lease-time units="seconds">1200</max-lease-time>

I don't really agree.
The manager cannot do anything meaningful without the schema.
The agent certainly needs to know its own data models.
So neither NETCONF entity should need this extra hint.
They know about max-lease-time 100% or 0%.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Jul 2008 17:21:59 +0200

> They know about max-lease-time 100% or 0%.

Well, the guys with the Mars Polar Lander were probably also supposed to
know. As long as the data model is transformed to code by human
programmers, such errors happen and indicating the units explicitly with
the value could be an extra measure against them.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Jul 2008 08:33:45 -0700

> the value could be an extra measure against them.

IMO, the units clause should never change.
You can only add one later to clarify the units already
described in the description clause.

This is a slippery slope.  There are lots of clauses
from the YANG module that a manager could send to
make double-sure the agent and manager are really in sync.

Proper change control rules, well-defined data models (w/ proper units)
and module version discovery should be enough to ensure that the
manager and agent are in sync -- for every aspect of a module.

Andy