Jeffrey Haas <[email protected]> wrote: > On Wed, Sep 24, 2014 at 09:00:26AM +0200, Juergen Schoenwaelder wrote:
> > > It is noted, however, that introducing something like a secondary identity > > > would require changes to SSH and/or TLS and may be somewhat difficult to > > > make the case to the owning working groups. > > > > 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? In general, NETCONF / RESTCONF with YANG supports the concept of meta-data, and meta-data is in XML transported as an XML attribute. (For JSON encoding see http://tools.ietf.org/id/draft-lhotka-netmod-yang-metadata-00.txt) > > > 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? Yes this would help. /martin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
