Subject: [netmod] octal numbers (again)

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Feb 2009 08:47:06 -0800

Hi,

I really do not like the 2nd para of 9.2.1, because
it creates a lot of confusion with XML and XPath.
It requires that implementations and users be aware
of the context in which a leading zero is used (XML or YANG).

   033 is an octal number in a YANG default but a valid decimal
   number everywhere else.

   08 and 09 are invalid octal numbers in YANG but are
   valid decimal numbers everywhere else.

IMO, this is confusing.
I do not understand why octal notation needs to be supported.
Hex notation is more modern, and should be sufficient.

Andy

---

From: David Kessens <[email-masked]>
Date: Mon, 9 Feb 2009 11:17:29 -0800

> Hex notation is more modern, and should be sufficient.

I agree (speaking as an individual working group contributor).

Speaking as one of the cochairs:

Our charter is fairly tight in terms of timelines.
We can have long discussions on features/options that might
be useful but that we have no actual users for.
Or we can move on and remove such things and work on more important issues
that actually make a difference.

Basically, when there is doubt about something, in the interest of
meeting our timelines it seems prudent to have a bias towards making
things simpler. Obviously, this message is not to overrule anybodies
opinion, but a reminder that we need to keep our timelines in mind as
well when discussing features/options etc.

David Kessens
---

---

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Feb 2009 17:16:50 -0800

> well when discussing features/options etc.

Does simpler mean leave octal in YANG and move on?
I don't care that much.  Nobody is ever going to think
of using octal notation anyway.  Most people know
to avoid leading zeros in integers as well, so
the problem will not likely show up.

It seems a bit odd to be worried about the YANG draft
milestone now (due in September), while the architecture draft WGLC
milestone (due in February) or the initial draft of the the
architecture draft (due last October) does not raise any flags.

Andy

---

From: David Kessens <[email-masked]>
Date: Mon, 9 Feb 2009 18:16:45 -0800

Andy,

> the problem will not likely show up.

I think I was pretty clear by stating (my personal opinion) that I
agreed with you: if there is no obvious use for it remove it. Keeping
it means more rules and complexity in order to keep apart the
different representations.

> architecture draft (due last October) does not raise any flags.

We are and should be concerned about all the milestones in general.
This issue just happened to be a nice example to raise awareness of
such concerns.

David Kessens
---

---

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Feb 2009 20:45:56 -0800

> different representations.

I found a workaround in the code, which is simply to
run the 'number-format' test according to the YANG rules,
but for XML/XPath, if the answer is 'octal', change it
to 'decimal'. (Then run strtol with a forced radix).

The issue before was that somebody will expect octal
to be supported, because the 'strtol' fn supports octal.
The 'least astonishment' principle is quite subjective,
changing the notion of 'expected behavior' for each person.

> This issue just happened to be a nice example to raise awareness of

I want to get done ASAP too.
We should hurry the other drafts up,
not slow down on YANG.

Andy

---

From: Johan Rydberg <[email-masked]>
Date: Tue, 10 Feb 2009 09:23:15 +0100

> Hex notation is more modern, and should be sufficient.

I for one use have a "umask" leaf in my data model, and file
permissions in UNIX tend to be defined using octal numbers.

It will be horrible to have to convert those to hex-humbers
or decimal.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Feb 2009 03:38:24 -0800

> It will be horrible to have to convert those to hex-humbers

You understand that octal is only available for the
the default-stmt, and not for setting the value via NETCONF, right?
There is no built-in type called 'octal', just a YANG file data format.

Andy

---

From: Johan Rydberg <[email-masked]>
Date: Tue, 10 Feb 2009 13:23:28 +0100

> There is no built-in type called 'octal', just a YANG file data format.

Of course!

---

From: David Partain <[email-masked]>
Date: Wed, 11 Feb 2009 11:32:24 +0100

Hi,

There's been an awful lot of mail about octal numbers... 

Could those who see a problem please suggest some delta text from the -03 
draft so we'll have something concrete to decide on?

Thanks.

David

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Feb 2009 12:44:10 +0100

> draft so we'll have something concrete to decide on?

See below. The same literal such as '010' meaning different things in a
default statement and in XPath expressions could be very confusing.

Lada

--- draft-ietf-netmod-yang-03.txt  2009-01-19 14:46:03.000000000 +0100
+++ draft-ietf-netmod-yang-03.new  2009-02-11 12:41:58.000000000 +0100
@@ -6125,18 +6125,10 @@
    is specified, "+" is assumed.
 
    For convenience, when specifying a default value for an integer in a
-   YANG module, an alternative lexicographic representation can be
used,
-   which represents the value in a hexadecimal or octal notation.  The
-   hexadecimal notation consists of an optional sign ("+" or "-"), the
+   YANG module, the hexadecimal notation can be used,
+   which consists of an optional sign ("+" or "-"), the
    characters "0x" followed a number of hexadecimal digits, where
-   letters may be upper- or lowercase.  The octal notation consists of
-   an optional sign ("+" or "-"), the character "0" followed a number
of
-   octal digits.
-
-   Note that if a default value in a YANG module has a leading zero
-   ("0"), it is interpreted as an octal number.  In the XML encoding,
an
-   integer is always interpreted as a decimal number, and leading zeros
-   are allowed.
+   letters may be upper- or lowercase.
 
    Examples:
 
@@ -6146,7 +6138,6 @@
      -123                        // legal negative value
      0xf00f                      // legal positive hexadecimal value
      -0xf                        // legal negative hexadecimal value
-     052                         // legal positive octal value
 
      // illegal values
      - 1                         // illegal intermediate space

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Feb 2009 13:04:44 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> The same literal such as '010' meaning different things in a

But with this logic we should also remove the hexadecimal notation.

I think people will be able to understand that the notation for
defaults is different.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Feb 2009 13:17:22 +0100

> But with this logic we should also remove the hexadecimal notation.

No, the difference is that 0x10 is an error in XPath.

> I think people will be able to understand that the notation for

leaf umask {
    type uint8;
    default 0022;
}

leaf foo {
    when "../umask = 0022";
    ...
}

This bug would be very easy to make and hard to spot.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Feb 2009 06:59:09 -0800

> This bug would be very easy to make and hard to spot.

That was my original point exactly, and I was hesitant
to raise the issue again, but this was the exact use-case
that made me send the email.

Both statements (default and when) above are perfectly legal,
but one sets the umask to 18 and the other checks if it
is equal to 22.  XML values (via edit-config) and XPath
expressions (when, must, select) will accept octal
numbers as decimal numbers.

There are dozens of details the user must get right, which each
occupy 2 sentences of text in a 168 page draft.  At a certain
point the WG needs to accept that YANG is full of 'surprises',
and a new user should study all 168 pages before starting
to use YANG.  There is too much complexity for it to stand
out and be easily recognized.

So go ahead an leave octal in YANG.
There is one use-case, unlike some features that have almost one.
It is just one of many things for a newbie to trip over.

Andy