On Wed, Sep 24, 2014 at 09:26:58AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder <[email protected]> wrote: > > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > > > Some discussion was given to the filtering considerations. Extending the > > > filtering options of the ietf-inet-types module may be appropriate. > > > [Juergen, is this an action item for yang 1.1?] > > > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > > functions. I like to ask I2RS to tell us what functions they need. We > > do have IP prefix-length matching on our radar. If other functions are > > required, please let us know as soon as possible. > > > > Now, this mostly is about the xpath function set that can be used in > > must and when expressions. You probably want to use them also in > > filtering expressions in the protocol. This is where things again > > become a protocol issues. Note that RFC 6241 says on page 17: > > > > The XPath expression is interpreted in the following context: > > > > [...] > > > > * The function library is the core function library. > > The quoted text is for the error-path. For the filter, rfc 6241 says > (p 67): > > o The function library is the core function library, plus any > functions defined by the data model. >
Oops. So we are in a better shape than I thought. Good news I would say (although this binding of protocol and data model leads to interesting effects but I do not want to go down there). /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/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
