Subject: [netmod] undecided Y21 statement to define new XPath functions in a module

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jun 2014 10:17:14 +0200

We need to decide whether this is in scope of YANG 1.1 or not.

Is there a risk that this may get abused, leading to non-interoperable
vendor specific sets of functions in XPATH expressions?

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Jun 2014 08:46:10 -0700

> vendor specific sets of functions in XPATH expressions?

Although I like this technical solution, I think it permits too much
variability in the standard, so it should be rejected.
The YANG 1.1 XPath library should be hard-wired (just like 1.0).

> /js

Andy

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 03 Jun 2014 14:23:53 +0200

> The YANG 1.1 XPath library should be hard-wired (just like 1.0).

+1.

I think such a feature would be misused by vendors for locking customers in their silos, as it was the case e.g. with Internet Explorer extensions. All extensions must remain strictly optional.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jun 2014 21:20:03 +0200

> vendor specific sets of functions in XPATH expressions?

Interim proposal:

  Proposal: Reject this request for a YANG statement to declare new
  XPATH functions but add a new issue to define additional XPATH
  functions that we know are needed to make for examples identity
  derivations accessible.

If you disagree, please speak up by June 18th.

/js