Subject: [netmod] revisit 'real' typedef in yang-types-05

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Jan 2010 09:39:40 -0800

Hi,

I think the 'real' typedef should be added to the ietf-yang-types
module.  The thread occurred in May 2009, and the final
proposal from David Spakes in in this email:

  http://www.ietf.org/mail-archive/web/netmod/current/msg02682.html

I am working on some XPath-based power tools for NETCONF.
Now that we got rid of float64, there is no way to expose
an XPath number result, which is a double.  The 'real' typedef
allows decimal64 to be used for this purpose.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 17 Jan 2010 20:43:58 +0100

> allows decimal64 to be used for this purpose.

As far as I know, XPath uses double-precision 64-bit format IEEE 754
numbers [1] and hence the 'real' typedef won't do it.

/js

[1] http://www.w3.org/TR/xpath#numbers

-- 
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/>

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 17 Jan 2010 20:49:20 +0100 (CET)

> numbers [1] and hence the 'real' typedef won't do it.

Right.  So should we put back float64 into YANG?  I agree with Andy
that such a datatype is necessary (somehow) when we want to expose the
result of an XPath expression in YANG.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Jan 2010 13:06:31 -0800

> result of an XPath expression in YANG.

I agree.  We lost this important compatibility with XPath.

In fact, we only support 1 of the 3 XPath result formats -- string.

I have asked many times for a 'varbind' data type, which is
the same as a node in an XPath node-set result.

  list xpath-node {
      key id;

      leaf id {
        description "YANG ID for this node";
        type instance-identifier;
      }
      leaf yang-type {
        description
          "Name of the 'final' YANG base type.
           If the type is union or leafref, then it is resolved
           until the base type is not one of these YANG types.";
         type string;    // could be enum to be more exact
      }
      leaf value {
         description
            "The value of the node indicated by 'id', cast as a 'string'.";
          type string;
      }
  }

I think we should support XPath results in our filtering,
and I am tired of explaining why NETCONF XPath doesn't
work that way.  If the client knows it wants an XPath node set
result, not a reconstructed <config> element, then the client
should be able to ask for that.

(Uh-oh, that's a NETCONF comment; not our department!)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 17 Jan 2010 22:15:45 +0100 (CET)

> In fact, we only support 1 of the 3 XPath result formats -- string.

We support boolean as well.

A node-set can be represented as a leaf-list of instance-identifiers
(sort-of; it can only refer to the 'node' type, not 'comment' etc, but
that doesn't matter).

So that's 3 out of 4.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Jan 2010 08:21:10 +0100

> result of an XPath expression in YANG.

As far as I am concerned, the introduction of decimal64 was a good
thing, the removal of the float types was a bad thing. Giving data
modelers the choice is a good thing, denying them the choice because
we believe to know better is a bad thing.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Jan 2010 08:44:19 +0100 (CET)

> we believe to know better is a bad thing.

I just re-read the old threads on floating point numbers in the
archive.  We should probably not re-open this issue...

*Maybe* we could avoid some of the problems by adding a type
'xpath1.0-number' instead, for the sole purpose of represeting a
number as defined in XPath 1.0.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Jan 2010 09:16:00 +0100

> archive.  We should probably not re-open this issue...

Probably.
 
> number as defined in XPath 1.0.

I am missing the smiley here. Is this meant as a serious proposal? In
that case, I will object. How many <bla>-number types do we need? Or
do we then derive a float typedef from <bla>-number to get the basic
type we try to avoid to add? Are we repeating the Counter64 story or
are we learning form the past?

Lets just accept that as of -10, the WG designed YANG such that it
can't natively represent the result of an XPATH expression (and lets
keep in mind that the original YANG proposal coming from the design
team was able to do so).

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Jan 2010 22:50:57 +0100 (CET)

> are we learning form the past?

The reasons we removed the float types were that (i) we believed that
a fixed point type was what people really needed and (ii) that we
couldn't find a representation that would work for XPath, XSD (RNG)
and easily for code.

Now maybe we can see a use case for the XPath-flavor.

But you are right - if we want to add a float type we should do it
right, and since we won't do that now, we should not add anything.

> keep in mind that the original YANG proposal coming from the design

Well, we had a float64 type, but it wasn't properly specified.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Jan 2010 13:59:44 -0800

> Well, we had a float64 type, but it wasn't properly specified.

Yet Another content-tagging extension:

   leaf xpath-number {
      type string;
      acme:xpath-number;
   }

That's OK.  I don't want to change any more text
in either draft, especially if it won't actually
fix the problem.

Andy

---

From: David Spakes <[email-masked]>
Date: Wed, 20 Jan 2010 11:16:10 -0500 (EST)

If you want to review the 'real' typedef, use this link instead
of the one Andy provided.  This message contained the final version
of the proposal including the description statement.  The description
text may be relevant for the discussion.

http://www.ietf.org/mail-archive/web/netmod/current/msg02987.html

-dss

On Sun, 17 Jan 2010, Andy Bierman wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Jan 2010 08:35:22 -0800

> http://www.ietf.org/mail-archive/web/netmod/current/msg02987.html

Actually, for my needs, using a 'string' works better
because it maintains every encoded value that could occur
in a float64.  Since XML encoding is a string no matter
what YANG calls it, the implementation is the same
for float64 as it is for string.

Andy

---

From: David Spakes <[email-masked]>
Date: Wed, 20 Jan 2010 11:59:03 -0500 (EST)

When float32 and float64 were replaced with decimal64, YANG document
writers lost the ability to represent data having variable-length
precision.  My entire purpose for creating the 'real' typedef was to
give that choice back to YANG document writers.

Even if the 'real' typedef can't be used for XPath, is there a compelling
argument to leave the 'real' typedef out of yang-types-05?  There are
probably other applications for it that this working group can't
anticipate.  I would like to propose one more time that we should add the
'real' typedef to yang-types-05 for the sake of those applications.

-dss

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Jan 2010 09:36:30 -0800

> 'real' typedef to yang-types-05 for the sake of those applications.

We can always extend this module, or create
a new module later.  I prefer that the YANG drafts
to go to the IESG ASAP, so we can get started on some content
and an access control model.

Andy