Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS and COMMENT)
Sorry for letting this sit so long; I must have missed it somewhere (and
thanks Alissa for the reminder!)
On Fri, May 03, 2019 at 01:48:45PM -0400, Christian Hopps wrote:
>
>
> > On Apr 11, 2019, at 9:49 AM, Benjamin Kaduk via Datatracker
> > wrote:
> >
> > --
> > DISCUSS:
> > --
> >
> > I think this document does introduce new security considerations,
> > specifically the ability for one user to remove ("mask") tags from being
> > visible to other users. A malicious user could interfere with the
> > operations of other users/entities, especially in the case mentioned in
> > an example where multiple semi-independent clients use tags to indicate
> > modules to avoid that may be broken.
>
> So here was the thinking on this, since this document doesn't define any
> actions or behaviors based on tags (or the lack of them) it's hard to talk
> about what the security considerations would be. However, it is expected that
> to be useful users (or future specifications) *will* define behaviors based
> on tag use. The security section does talk about this case:
>
> "
>Users of the tag-meta data may define various actions to be taken
>based on the tag meta-data. These actions and their definitions are
>outside the scope of this document. Users will need to consider the
>security implications of any actions they choose to define.
> "
>
> Which I believe covered this. For example, if an RFC were to define a
> behavior based on the tag presence then it would need to talk about the
> security concerns with that behavior.
In some sense it covers this, but my Discuss is more about the
somewhat-subtle point involving somewhat "long-range" interactions that it
doesn't seem reasonable to expect people specifying tags to think about
without help.
> If this doesn't adequately cover your concern though, do you have a bit of
> suggested text we could add?
I'd suggest to add another clause at the end of the paragraph you quoted:
", including the potential for a tag to get 'masked away' by another user."
> > --
> > COMMENT:
> > --
>
> >
> > Section 2
> >
> > Similarly to Alissa's DISCUSS, perhaps "registered prefix" is better
> > than "standard prefix".
> >
> > Section 2.4
> >
> > Similarly, "future registration" or "future use" seem to be better fits
> > for the intended sentiment.
> >
> > Section 3.2
> >
> > I may be misreading, but this seems to be encouraging implementations to
> > add new ietf:-prefixed tags that are not necessarily registered or
> > specified in IETF-consensus documents.
> >
> > Section 7.2
> >
> > This registry allocates prefixes that have the standard prefix
> > "ietf:". [...]
> >
> > The registry name just talks about "tags"; are we really allocating
> > *prefix*es?
> >
>
> Fixed these, thanks.
Thanks!
-Ben
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] netmod - Update to a Meeting Session Request for IETF 107
An update to a meeting session request has just been submitted by Kent Watsen, a Chair of the netmod working group. - Working Group Name: Network Modeling Area Name: Operations and Management Area Session Requester: Kent Watsen Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: netconf Technology Overlap: rtgwg i2rs teas Key Participant Conflict: saag People who must be present: Lou Berger Joel Jaeggli Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: Please place the first session in the first half of the week (i.e., M-W). - ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] validating instance data against YANG schema including 'must' statements
Hi Jason, yanglint does validate XML instance data for must statements: MAHESH-M-M8D1:/Volumes/External/git/my-YANG-public/src/model/draft *833 > yanglint -t auto -s -i -p common .../../../build/mef-legato-servi...@2018-07-17.yang MEF6.2-bwp-per-uni-mef-interface-configuration.xml err : Must condition ". >= 1 and . <= count(../../bwp-flow/rank)" not satisfied. (/mef-legato-interfaces:mef-interfaces/carrier-ethernet/subscriber-interfaces/uni[uni-id='ciscoD21:GigabitEthernet0/0/0/1']/ingress-envelopes/envelope[id='ciscoD21-per-cos-env2']/bwp-flows/bwp-flow[rank='3']/rank) err : The rank of a Bandwidth Profile Flow must be between 1 and n, where n is the number of flows in the Envelope (/mef-legato-interfaces:mef-interfaces/carrier-ethernet/subscriber-interfaces/uni[uni-id='ciscoD21:GigabitEthernet0/0/0/1']/ingress-envelopes/envelope[id='ciscoD21-per-cos-env2']/bwp-flows/bwp-flow[rank='3']/rank) > On Jan 31, 2020, at 8:21 AM, Sterne, Jason (Nokia - CA/Ottawa) > wrote: > > Thx Lada. > > If I only have XML (e.g. from a NETCONF interface) I suppose I could use > yanglint, e.g. this type of usage: > yanglint--format=json--type=config --output=data.json > ./all-my-modules/*.yang ./data.xml > > Is that correct? > > I believe yanglint can also validate instance data against a YANG schema. Can > anyone confirm that yang2dsdl and yanglint do *not* validate against the > 'must' statements? > > Jason > >> -Original Message- >> From: netmod On Behalf Of Ladislav Lhotka >> Sent: Friday, December 13, 2019 2:59 AM >> To: netmod@ietf.org >> Subject: Re: [netmod] validating instance data against YANG schema including >> 'must' statements >> >> On Thu, 2019-12-12 at 16:42 +, Sterne, Jason (Nokia - CA/Ottawa) wrote: >>> Hi all, >>> >>> A few years ago there were a few discussions on the list about tools to >>> validate instance data (e.g. the data returned by a ) against a >>> YANG model. >>> >>> yang2dsdl is one option but I'm pretty sure it doesn't actually check the >>> data >>> against 'must' statements. >>> >>> Are there some tools that check against 'must' (and 'when') statements? >> Do >>> those tools also work with YANG 1.1 modules? >> >> Yangson does a complete validation, and supports YANG 1.1, but only JSON >> representation of instance data. The GitHub link is below, a PyPI package is >> also available: >> >> https://pypi.org/project/yangson/ >> >> Lada >> >>> >>> Thx, >>> Jason >>> >>> >> ### >> ### >>> >>> Re: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 => 16.10-5..1 >>> Ladislav Lhotka Tue, 07 March 2017 12:42 UTCShow >> header >>> >>> Kent Watsen ; writes: >>> Hi Benoit, You seem to know the ins and outs of many tools these days, maybe you can point me in the right direction...which tool is able to validate instance documents against YANG 1.1 modules? >>> >>> Yangson can validate JSON documents: >>> >>> https://github.com/CZ-NIC/yangson >>> I've always used `yang2dsdl`, but currently it outputs "DSDL plugin supports only YANG version 1". >>> >>> I considered updating the DSDL plugin to 1.1 but it turned up to be >>> immensely difficult - it would basically require a complete rewrite. And >>> even then, the Schematron implementation that is included in pyang >>> distribution won't support the new XPath functions. >>> >>> Lada >>> >>> >> ### >> ### >>> >>> >>> Re: [netmod] DSDL plugin in pyang >>> Ladislav Lhotka Tue, 29 November 2016 13:39 UTCShow >> header >>> >>> Hi William, >>> >>> apart from yang2dsdl, I have personal experience with these two instance >>> validation tools: >>> >>> * yanglint - written in C, supports both XML and JSON instance encoding >>> >>> https://github.com/CESNET/libyang >>> >>> * yangson - written in Python, supports only JSON >>> >>> https://github.com/CZ-NIC/yangson >>> installation: pip install yangson >>> manual page: http://yangson.readthedocs.io/en/latest/cmdline.html >>> >>> Lada >>> >>> William Lupton ; writes: >>> Are you able to provide a list (either privately or via the NETMOD list) of >>> other instance data validators that are available and cover YANG 1.1 >> features? >>> Tx, W. > On 25 Nov 2016, at 14:33, Ladislav Lhotka ; wrote: > > Hi, > > for users of $subj: I modified the plugin so that it now immediately >>> refuses to process modules of yang-version greater than 1. Supporting some >> of >>> the YANG 1.1 features (new XPath functions, leafref handling) would require >>> massive changes and I cannot do them now - I am not even sure it is worth >> the >>> effort given that other instance data validators are available. > > Lada >>> >>> -- >>> >>> >>
Re: [netmod] validating instance data against YANG schema including 'must' statements
Thx Lada. If I only have XML (e.g. from a NETCONF interface) I suppose I could use yanglint, e.g. this type of usage: yanglint--format=json--type=config --output=data.json ./all-my-modules/*.yang ./data.xml Is that correct? I believe yanglint can also validate instance data against a YANG schema. Can anyone confirm that yang2dsdl and yanglint do *not* validate against the 'must' statements? Jason > -Original Message- > From: netmod On Behalf Of Ladislav Lhotka > Sent: Friday, December 13, 2019 2:59 AM > To: netmod@ietf.org > Subject: Re: [netmod] validating instance data against YANG schema including > 'must' statements > > On Thu, 2019-12-12 at 16:42 +, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > Hi all, > > > > A few years ago there were a few discussions on the list about tools to > > validate instance data (e.g. the data returned by a ) against a > > YANG model. > > > > yang2dsdl is one option but I'm pretty sure it doesn't actually check the > > data > > against 'must' statements. > > > > Are there some tools that check against 'must' (and 'when') statements? > Do > > those tools also work with YANG 1.1 modules? > > Yangson does a complete validation, and supports YANG 1.1, but only JSON > representation of instance data. The GitHub link is below, a PyPI package is > also available: > > https://pypi.org/project/yangson/ > > Lada > > > > > Thx, > > Jason > > > > > ### > ### > > > > Re: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 => 16.10-5..1 > > Ladislav Lhotka Tue, 07 March 2017 12:42 UTCShow > header > > > > Kent Watsen ; writes: > > > > > Hi Benoit, > > > > > > You seem to know the ins and outs of many tools these days, maybe you > > > can point me in the right direction...which tool is able to validate > > > instance documents against YANG 1.1 modules? > > > > Yangson can validate JSON documents: > > > > https://github.com/CZ-NIC/yangson > > > > > > > > I've always used `yang2dsdl`, but currently it outputs "DSDL plugin > > > supports only YANG version 1". > > > > I considered updating the DSDL plugin to 1.1 but it turned up to be > > immensely difficult - it would basically require a complete rewrite. And > > even then, the Schematron implementation that is included in pyang > > distribution won't support the new XPath functions. > > > > Lada > > > > > ### > ### > > > > > > Re: [netmod] DSDL plugin in pyang > > Ladislav Lhotka Tue, 29 November 2016 13:39 UTCShow > header > > > > Hi William, > > > > apart from yang2dsdl, I have personal experience with these two instance > > validation tools: > > > > * yanglint - written in C, supports both XML and JSON instance encoding > > > > https://github.com/CESNET/libyang > > > > * yangson - written in Python, supports only JSON > > > > https://github.com/CZ-NIC/yangson > > installation: pip install yangson > > manual page: http://yangson.readthedocs.io/en/latest/cmdline.html > > > > Lada > > > > William Lupton ; writes: > > > > > Are you able to provide a list (either privately or via the NETMOD list) > > > of > > other instance data validators that are available and cover YANG 1.1 > features? > > Tx, W. > > > > > >> On 25 Nov 2016, at 14:33, Ladislav Lhotka ; wrote: > > >> > > >> Hi, > > >> > > >> for users of $subj: I modified the plugin so that it now immediately > > refuses to process modules of yang-version greater than 1. Supporting some > of > > the YANG 1.1 features (new XPath functions, leafref handling) would require > > massive changes and I cannot do them now - I am not even sure it is worth > the > > effort given that other instance data validators are available. > > >> > > >> Lada > > > > -- > > > > > ### > ### > > > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
