On Wed, Sep 24, 2014 at 11:38:02AM -0400, Jeffrey Haas wrote: > > > > I do not follow here. The secure transport delivers what NETCONF calls > > a username, the identity of the NETCONF client. If this client acts on > > behalf of another application (the secondary identity), then this > > identity is meta data should be attached to the information submitted > > to the ephemeral datastore. I do not see why this would lead to any > > changes to SSH or TLS. > > I tried to raise this as a question during the interim, but I think it was > lost. How should the meta-data be transported? >
Likely as meta-data attributes. https://tools.ietf.org/html/draft-lhotka-netmod-yang-metadata-00 > > > 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. > > The primary ones I am aware of are operations on network addresses and > prefixes. Was netmod looking for an explicit manifest of such operations? We are happy to receive input. A starting point is here. http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00 This I-D, however, does not define functions for network addresses. > This may have overlap in the work for the ACL module that is already a > netmod document. I am lost here. I do not see how additional xpath functions related to the NACM (which came out of NETCONF not NETMOD). /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
