Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)
On Mon, Oct 15, 2018 at 09:33:09AM +0200, Martin Bjorklund wrote: > Hi, > > Benjamin Kaduk wrote: > > On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote: > > > Hi, > > > > > > Benjamin Kaduk wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-netmod-schema-mount-11: No Objection > > > > > > > > When responding, please keep the subject line intact and reply to all > > > > email addresses included in the To and CC lines. (Feel free to cut this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > > > > > > > > > > > > > -- > > > > COMMENT: > > > > -- > > > > > > > > Whenever we introduce a new namespace "sub-hierarchy" there is some > > > > level > > > > of risk about surpirses with respect to the security properties of the > > > > combined system. I appreciate that the mounted schemas are "jailed" > > > > into > > > > their own subtree except for the specific exceptions for XPath access, > > > > which helps a lot. But there may still be potential for surprise with > > > > respect to, e.g., access control on mounted schemas, if an administrator > > > > previously assumed that such controls would only be needed at the > > > > top-level. The document itself doesn't give me a great picture of to > > > > what > > > > extent these risks and the possible consequences of the new nested > > > > structure have been considered; I'd be happy to hear if they've been > > > > thought about a lot already and the conclusion was that the situation > > > > is so > > > > boring that nothing needs to be mentioned in the document. > > > > > > The intention was that this is covered in Section 7, Interaction with > > > the Network Configuration Access Control Model (NACM). > > > > > > But it is probably a good idea to explicitly mention this in the > > > Security Considerations section as well (together with your last point > > > below). So maybe add a paragraph at the end of Section 11: > > > > > > It is important to take the security considerations for all nodes in > > > the mounted schemas into account, and control access to these nodes > > > by using the mechanism described in Section 7. > > > > I guess this addresses my concern; thanks. > > > > > > Section 3.3 > > > > > > > >If multiple mount points with the same name are defined in the same > > > >module - either directly or because the mount point is defined in a > > > >grouping and the grouping is used multiple times - then the > > > >corresponding "mount-point" entry applies equally to all such mount > > > >points. > > > > > > > > Does this mean that the multiple mount points must serve the same > > > > data/contents, or just that they must use the same schema? > > > > (Is this related to "inline" vs. "shared-schema"?) > > > > > > No, this document intentionally doesn't assume anything about the > > > source of the instance data (as explained in section 1). So the > > > answer is that they just use the same schema. > > > > > > > Section 3.4 > > > > > > > > So this means that there can be multiple > > > > ietf-yang-schema-mount:schema-mounts:mount-point nodes at different > > > > locations in the hierarchy? When I was first reading the document, the > > > > design seemed fairly clean with just a single list of mount-points at > > > > the > > > > "top-level" that tracks everything, but this kind of recursion seems > > > > like > > > > it would make implementation potentially quite complex. What kind of > > > > implementation experience do we have that can replace my half-informed > > > > suppositions about complexity? > > > > > > I agree with you that multiple levels of mounting probably can be > > > complex. But there is nothing in the design of schema mount that > > > prohibits this. In fact, it "falls out for free" from the design. > > > > > > A 2-level example is a physical device with LNEs > > > (draft-ietf-rtgwg-lne-model) which has NIs > > > (draft-ietf-rtgwg-ni-model). > > > > > > > Section 4 > > > > > > > >Therefore, schema mount also allows for such references. For every > > > >mount point in the "shared-schema" case, it is possible to specify a > > > >leaf-list named "parent-reference" that contains zero or more XPath > > > >1.0 expressions. [...] > > > > > > > > editorial: """the "shared-schema" case""" reads oddly to me; it might be > > > > clearer to refer to schemas mounted using "shared-schema" instead. As > > > > in, > > > > """For every mount
Re: [netmod] schematree-statement extension?
On 15/10/2018 21:49, Kent Watsen wrote: > Hi Robert, > > Picking up on your YANG 1.2 comment. Please add a YANG-next issue, if this > is not being tracked already. https://github.com/netmod-wg/yang-next/issues. https://github.com/netmod-wg/yang-next/issues/53 I think I captured the gist of the issue, but let's fleshing out the definition. Regards, Robert signature.asc Description: OpenPGP digital signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-01.txt
On 06/03/2018 00:56, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Network Modeling WG of the IETF.
>
> Title : YANG Data Extensions
> Authors : Andy Bierman
> Martin Bjorklund
> Kent Watsen
> Filename: draft-ietf-netmod-yang-data-ext-01.txt
> Pages : 11
> Date: 2018-03-05
>
> Abstract:
>This document describes YANG mechanisms for defining abstract data
>structures with YANG. It is intended to replace and extend the
>"yang-data" extension statement defined in RFC 8040.
Sorry to be a late reviewer on this.
To me "augment-yang-data" feels really like "augment a particular
instance of a schema tree", i.e. increasing specificity of augment
target node with knowledge on which tree instantiation it operates.
RFC7950 already does this (implicitly) for notification, rpc and action
statements by making them members of the schema tree and the same
"augment" and "deviation" mechanics for them being defined shared with
the data tree.
I would argue this problem from a different point of view.
I think the purpose of "augment-yang-data" would be much better
addressed with an extension usable within augment (and deviate) to
reference a particular schema tree instantiation.
What that means in terms of YANG metamodel is two-fold:
1) an extension statement can define a conceptual schema tree
instantiation -- very much like NMDA does, but applied not to datastore,
but to schema tree.
2) an augment (or deviation) statement can be restricted to operate on a
schema tree instantiation defined by an extension statement
Rough example:
extension augmentable-statement;
extension schematree-instance;
extension yang-data {
as:augmentable-statement;
}
yd:yang-data foo;
augment /foo {
// i.e. interpret argument as a target valid in the schema tree
// as defined by yang-data, with the semantics specified therein
si:schematree-instance "yd:yang-data";
}
Note how as:schematree-instance is completely unnecessary here:
yang-data's use of as:augmentable-statement is already indicating that
the statement is augmentable, thus bridging it to RFC7950 section 7.19:
An extension can allow refinement (see Section 7.13.2) and deviations
(Section 7.20.3.2), but the mechanism for how this is defined is
outside the scope of this specification.
hence the only extension that is needed for yang-data and future similar
extensions is augmentable-statement, simply because as soon as "augment"
argument touches an extension statement, you have to know something
about it. If an augment argument crosses an extension statement, it must
share fate with the parser's handling of the extension: if the parser
chooses to ignore the extension, it should reasonably also ignore the
augment statement.
Unless "augment" is not allowed to touch extension statements (i.e.
extensions must never define a schema tree member) -- if that is the
case, that should be normatively defined somewhere, too.
Regards,
Robert
signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] xpath expressions in JSON
On 10/15/18 4:25 PM, Ladislav Lhotka wrote:
Martin Bjorklund writes:
Ladislav Lhotka wrote:
On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:
On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman)
wrote:
On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:
Ladislav Lhotka wrote:
> Martin Bjorklund writes:
>
> > Hi,
> >
> > While reviewing restconf-notif, I saw this example:
> >
> >{
> > "ietf-subscribed-notifications:input": {
> > "stream": "NETCONF",
> > "stream-xpath-filter": "/ds:foo/",
> > "dscp": "10"
> > }
> >}
> >
> > Note the "stream-xpath-filter". It has a prefix in the XPath
string.
> > How are prefixes declared when JSON is used?
> >
> > The leaf "stream-xpath-filter" says:
> >
> > o The set of namespace declarations are those in
scope on
> > the 'stream-xpath-filter' leaf element.
> >
> > (I think I provided that text...)
> >
> > This assumes that the encoding is XML, or at leas that the encoding
> > can somehow transfer namespace declarations.
>
> It can't. There are two options:
>
> 1. have different representations of this value in XML and JSON,
>analogically to instance indentifiers (sec. 6.11 in RFC 7951).
>
> 2. use a module name rather than a prefix in XML, too.
>
> I would suggest #2.
But that means making non-backwards compatible change to the XML
representation?
Not really. It means NETMOD WG would be creating its own special variant of
XPath.
The thing is that XPath is "XML Path Language", so using it outside XML is
problematic.
Not necessarily. Section 5 of the XPath 1.0 spec defins the "data
model" where an XPath expression is applied. We could make a formal
specification of how a YANG data tree maps to this data model (pretty
straightforward...). I think experience from implementations over the
last 8 years show that this in fact works quite well.
Except some parts that don't apply. For example, siblings nodes in XPath
are ordered, whereas in YANG 'foo[1]' may give unpredictable results.
Not all XPath expressions map to something meaningful in the context of
YANG data. However a subset of them do.
IMO introducing yang:ypath1.0 makes sense but it is practical to define
it as a subset of yang:xpath1.0. Martins proposal 2) for an encoding
independent solution where the prefixes are restricted to be module
names works. Proposal 1) seems to be a step back clogging YANG with
encoding specific details.
Vladimir
This is probably OK in YANG modules but not so much if XPath expressions
are used as configuration data.
Lada
/martin
Lada
Hmm, so you mean change the leaf "stream-xpath-filter" to say:
o The set of namespace declarations has one member for each
YANG module supported by the server. This member maps
from the YANG module name to the YANG module namespace.
This means that in the XPath expression, the module name
serves as the prefix.
and then also give an example of this.
This is probably what we need to do in all places where yang:xpath1.0
is used, going forward. Maybe even define a new type
yang:xpath1.0-2 (name?) with the set of namespace declarations
built-in.
We should avoid making off-the-shelf implementations of standards like XPath
unusable.
At the very least this should be only available if the server supports it
(with a capability URI)
So we need an update to RFC7951?
Regards,
Reshad.
Andy
/martin
>
> Lada
>
> >
> > How is this supposed to work with JSON?
> >
> >
> > /martin
> >
> > ___
> > 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
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] schematree-statement extension?
Hi Robert,
Picking up on your YANG 1.2 comment. Please add a YANG-next issue, if this
is not being tracked already. https://github.com/netmod-wg/yang-next/issues.
Thanks,
Kent
-Original Message-
From: netmod on behalf of Robert Varga
Date: Monday, October 15, 2018 at 3:36 PM
To: Martin Bjorklund
Cc: "netmod@ietf.org"
Subject: Re: [netmod] schematree-statement extension?
On 15/10/2018 21:09, Martin Bjorklund wrote:
> Hi,
>
> Robert Varga wrote:
>> It is wide-spread practice to use tailf:action and target statements
>> within it with augment/deviate statements -- which I think is a failure
>> to follow RFC7950 section 6.3.1:
>>
>>Care must be taken when defining extensions so that modules that use
>>the extensions are meaningful also for applications that do not
>>support the extensions.
>
> Yes, but note that 7950 means a 1.1 module, and tailf:action should be
> replaced with 'action' in a 1.1 module.
I think the argument applies (and proposed extension would be
applicable) to RFC6020 as well.
I am not complaining about tailf:action specifically, I will just map it
YANG 1.1 action even in YANG 1.0 mode and I'm done :)
> One reason we added the quoted paragraph to 7950 was because of the
> problem you describe with tailf:action.
I suspected as much, thank you for that :)
>> I think the proper way of fixing this would be to define a YANG
>> extension, which, when used within another extension, would indicate
>> that the extension being defined is part of the schema tree, for example:
>>
>>extension schematree-statement;
>>
>>extension foo {
>>argument bar;
>>
>>sts:schematree-statement;
>>}
>
> Unfortunately, this doesn't solve the problem, since a parser that
> doesn't understand sts:schematree-statement still wouldn't know that
> foo defined a schema node, and thus it will still complain if it sees
> an augment of a node introduced with "ex:foo".
>
> In order for this to work, "schematree-statement" would have to be a
> builtin statement.
>
> (... and if we had this statement, we could have used it in yang-ext
> as well, and avoid augement-yang-data)
Understood and agreed, parsers not supporting schematree-statement would
be left unfixed, but also no worse off.
My skin in the game is to future-proof my parser (based on supporting
widely-available specifications) until this is fixed for everyone with
YANG 1.2. Adding support for a language extension is much simpler than
to bump YANG language support by 0.1, at least in my experience.
This could even help augment-yang-data in that the semantics of what it
does would be kept with the extension (yang-data) as opposed to a
different, related (as understandable by humans), language extension. An
an implementor,
Such extension would also address a piece of RFC7950 section 7.19's:
An extension can allow refinement (see Section 7.13.2) and deviations
(Section 7.20.3.2), but the mechanism for how this is defined is
outside the scope of this specification.
by defining how an extension can declare that it _does_allow_ refinement
and deviations without getting into the business of how that
refinement/deviations are done. This could even be separate extensions:
extension augmentable-statement;
extension deviable-statement;
Such a language extension can be picked up by parsers across all YANG
versions, making adoption much easier and faster.
>> Using that knowledge, the parser can correctly interpret
>> augment/deviation arguments as validly pointing to a particular use of
>> foo (or its descendants) and correctly ignore their effects.
>>
>> Is this something the WG feels is a real problem and would be interested
>> in solving?
>
> The current advice is of course to NEVER add nodes to the schema tree
> with an extension. I think it is probably best to stick to this
> advice...
That advice I missed. Is there a link I can quote? :)
Thanks,
Robert
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] schematree-statement extension?
On 15/10/2018 21:09, Martin Bjorklund wrote:
> Hi,
>
> Robert Varga wrote:
>> It is wide-spread practice to use tailf:action and target statements
>> within it with augment/deviate statements -- which I think is a failure
>> to follow RFC7950 section 6.3.1:
>>
>>Care must be taken when defining extensions so that modules that use
>>the extensions are meaningful also for applications that do not
>>support the extensions.
>
> Yes, but note that 7950 means a 1.1 module, and tailf:action should be
> replaced with 'action' in a 1.1 module.
I think the argument applies (and proposed extension would be
applicable) to RFC6020 as well.
I am not complaining about tailf:action specifically, I will just map it
YANG 1.1 action even in YANG 1.0 mode and I'm done :)
> One reason we added the quoted paragraph to 7950 was because of the
> problem you describe with tailf:action.
I suspected as much, thank you for that :)
>> I think the proper way of fixing this would be to define a YANG
>> extension, which, when used within another extension, would indicate
>> that the extension being defined is part of the schema tree, for example:
>>
>>extension schematree-statement;
>>
>>extension foo {
>>argument bar;
>>
>>sts:schematree-statement;
>>}
>
> Unfortunately, this doesn't solve the problem, since a parser that
> doesn't understand sts:schematree-statement still wouldn't know that
> foo defined a schema node, and thus it will still complain if it sees
> an augment of a node introduced with "ex:foo".
>
> In order for this to work, "schematree-statement" would have to be a
> builtin statement.
>
> (... and if we had this statement, we could have used it in yang-ext
> as well, and avoid augement-yang-data)
Understood and agreed, parsers not supporting schematree-statement would
be left unfixed, but also no worse off.
My skin in the game is to future-proof my parser (based on supporting
widely-available specifications) until this is fixed for everyone with
YANG 1.2. Adding support for a language extension is much simpler than
to bump YANG language support by 0.1, at least in my experience.
This could even help augment-yang-data in that the semantics of what it
does would be kept with the extension (yang-data) as opposed to a
different, related (as understandable by humans), language extension. An
an implementor,
Such extension would also address a piece of RFC7950 section 7.19's:
An extension can allow refinement (see Section 7.13.2) and deviations
(Section 7.20.3.2), but the mechanism for how this is defined is
outside the scope of this specification.
by defining how an extension can declare that it _does_allow_ refinement
and deviations without getting into the business of how that
refinement/deviations are done. This could even be separate extensions:
extension augmentable-statement;
extension deviable-statement;
Such a language extension can be picked up by parsers across all YANG
versions, making adoption much easier and faster.
>> Using that knowledge, the parser can correctly interpret
>> augment/deviation arguments as validly pointing to a particular use of
>> foo (or its descendants) and correctly ignore their effects.
>>
>> Is this something the WG feels is a real problem and would be interested
>> in solving?
>
> The current advice is of course to NEVER add nodes to the schema tree
> with an extension. I think it is probably best to stick to this
> advice...
That advice I missed. Is there a link I can quote? :)
Thanks,
Robert
signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] schematree-statement extension?
Hi,
Robert Varga wrote:
> Hello,
>
> I have recently been reminded that there is a potential interoperability
> issue between RFC6020/RFC7950 and extension statements. So far the only
> case where this has manifested is tailf:action, but there may be others
> lurking in the future.
>
> The issue is that a YANG extension has no standardized way of declaring
> it is a part of the schema tree, which means that unless a parser has at
> least partial support for a particular extension, attempting to use
> deviation or augment statements with it cannot work.
>
> It is wide-spread practice to use tailf:action and target statements
> within it with augment/deviate statements -- which I think is a failure
> to follow RFC7950 section 6.3.1:
>
>Care must be taken when defining extensions so that modules that use
>the extensions are meaningful also for applications that do not
>support the extensions.
Yes, but note that 7950 means a 1.1 module, and tailf:action should be
replaced with 'action' in a 1.1 module.
One reason we added the quoted paragraph to 7950 was because of the
problem you describe with tailf:action.
> Therefore a parser which ignores the extension in its entirety, as per
> section 6.3.1, will not populate the schema tree with the production of
> (for example) 'tailf:action foo' nor its descendants and hence an
> attempt to augment the use of the extension or any of its descendant
> will result in failure to resolve the schema node identifier to a schema
> tree node -- similar to what happens when an attempt is made to augment
> a non-existing statement, a grouping, a typedef or an extension
> statement (which may itself be unsupported).
>
> I think the proper way of fixing this would be to define a YANG
> extension, which, when used within another extension, would indicate
> that the extension being defined is part of the schema tree, for example:
>
>extension schematree-statement;
>
>extension foo {
>argument bar;
>
>sts:schematree-statement;
>}
Unfortunately, this doesn't solve the problem, since a parser that
doesn't understand sts:schematree-statement still wouldn't know that
foo defined a schema node, and thus it will still complain if it sees
an augment of a node introduced with "ex:foo".
In order for this to work, "schematree-statement" would have to be a
builtin statement.
(... and if we had this statement, we could have used it in yang-ext
as well, and avoid augement-yang-data)
> With that, any parser not knowing "foo", but understanding
> "sts:schematree-statement" would know that:
> - foo's argument is an identifier as per RFC7950 section 14
> - the use of "foo" follows the usual schema tree population rules
>
> Using that knowledge, the parser can correctly interpret
> augment/deviation arguments as validly pointing to a particular use of
> foo (or its descendants) and correctly ignore their effects.
>
> Is this something the WG feels is a real problem and would be interested
> in solving?
The current advice is of course to NEVER add nodes to the schema tree
with an extension. I think it is probably best to stick to this
advice...
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] schematree-statement extension?
Hello,
I have recently been reminded that there is a potential interoperability
issue between RFC6020/RFC7950 and extension statements. So far the only
case where this has manifested is tailf:action, but there may be others
lurking in the future.
The issue is that a YANG extension has no standardized way of declaring
it is a part of the schema tree, which means that unless a parser has at
least partial support for a particular extension, attempting to use
deviation or augment statements with it cannot work.
It is wide-spread practice to use tailf:action and target statements
within it with augment/deviate statements -- which I think is a failure
to follow RFC7950 section 6.3.1:
Care must be taken when defining extensions so that modules that use
the extensions are meaningful also for applications that do not
support the extensions.
Therefore a parser which ignores the extension in its entirety, as per
section 6.3.1, will not populate the schema tree with the production of
(for example) 'tailf:action foo' nor its descendants and hence an
attempt to augment the use of the extension or any of its descendant
will result in failure to resolve the schema node identifier to a schema
tree node -- similar to what happens when an attempt is made to augment
a non-existing statement, a grouping, a typedef or an extension
statement (which may itself be unsupported).
I think the proper way of fixing this would be to define a YANG
extension, which, when used within another extension, would indicate
that the extension being defined is part of the schema tree, for example:
extension schematree-statement;
extension foo {
argument bar;
sts:schematree-statement;
}
With that, any parser not knowing "foo", but understanding
"sts:schematree-statement" would know that:
- foo's argument is an identifier as per RFC7950 section 14
- the use of "foo" follows the usual schema tree population rules
Using that knowledge, the parser can correctly interpret
augment/deviation arguments as validly pointing to a particular use of
foo (or its descendants) and correctly ignore their effects.
Is this something the WG feels is a real problem and would be interested
in solving?
Thanks,
Robert
signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Yangdoctors early review of draft-ietf-ntp-yang-data-model-03
Hi Andy,
Please find our comment in line below
Thanks,
Ankit
On Tue, 9 Oct 2018 at 06:15, Andy Bierman wrote:
> Reviewer: Andy Bierman
> Review result: Almost Ready
>
>
>
>
> Overall:
>- no compiler warnings; passes --ietf check as well
>
> Normative Sections:
>
> sec 1:
>- YANG version cited should be RFC 7950, not 6020.
> YANG 1.1 is used in this document.\
>
[Authors]: Updated
>
> sec 4: Relationship with RFC 7317
> - this section should say how overlapping configuration
> objects interact. Does setting 1 field (e.g., /system/ntp/enabled)
> change the other field at the same time (e.g., /ntp/enabled)
> It seems the intent is to ignore and deprecate /system/ntp if
> /ntp is implemented. This section should explain.
>
[Authors]: Updated
>
> sec 5:
> - this section is supposed to have citations for every imported
> YANG module used in the ietf-ntp YANG module
>
[Authors]: In section 1.4, we have a table of all the improted yang modules
with references. We also use reference statement in the yang model in
section 5. All imported modules are mentioned as normative reference. Is
there any other change you would like to see?
>
>
> YANG Module Issues:
> 1 - Indexing used in /ntp/associations list
> key "address local-mode isConfigured";
>
> a) will there really be multiple instances per address for
> different association-modes? The list description-stmt
> should explain.
>
[Authors]: It is possible to have different association-modes for same
address. Example is updated in the the document
>
> b) There can be configured values (isConfigured key) and learned
> entries for the same address and association-modes? Why isn't
> NMDA used instead? (i.e. intended and operational datastores
> used instead of the isConfigured list key?)
>
[Authors]: Here /ntp/associations/ is read only, which can have learned
entries and configured entries. Configured entries depends on "unicast,
broadcast, multicast and manycast" configurations. Lets take following
examples
1) If RT1 acting as broadcast server,
and RT2 acting as broadcast client, then RT2
will form dynamic association with address as RT1,
local-mode as client and isconfigured as false.
2) When RT2 is configured
with unicast-server RT1, then RT2 will form
association with address as RT1, local-mode as client
and isconfigured as true.
>
> 2 - Purpose of /ntp/access-rules
> There is no explanation for what it means to configure an entry
> here that points at an ACL entry in /acls/acl; The description
> statement needs to specify the details. Doesn't the ACL module
> just work? How does the /ntp/access-rules/access-rule list
> change behavior?
>
[Authors]: We have updated draft with "section 5 Access Rules" with
explanation
>
> 3 - Reinvent Key Management
> It does not seem like a good idea for every protocol to
> duplicate key management functionality. The draft should
> explain why other YANG modules related to this work are not
> relevant here
>
[Authors]: We have updated draft with "section 6 Key Management" with
explanation
>
> 4 - Reference statements
> There are no reference statements used in any objects or typedes
> Definitions which are intended to match a definition in NTP
> should include a reference-stmt
>
[Authors]: Updated
>
> Minor Issues:
>- typedef names should be singular
> - access-mode not access-modes
> - association-mode not association-modes
>- grouping comman-attributes should be common-attributes
>- mixed-case naming should not be used (isConfigured)
>- indentation used in module needs a lot of corrections
>- some descriptions have incorrect tense (e.g., "NTP is enable")
>- port definition should be based on inet:port-number, not uint16
> OLD:
> type uint16 {
>range "123 | 1025..max";
> }
> NEW:
> type inet:port-number {
>range "123 | 1025..max";
> }
>
[Authors]: All the above comments are updated
- /ntp/authentication/trusted-keys
> Why is this list needed? Seems a leaf (e.g., trusted-key (true/false)
> added to the authentication-keys list is sufficient
>
[Authors]: trusted-key is removed and leaf istrusted is added to
authentication-key
- /ntp/clock-state : some leafs should have a units-stmt instead of
> specifying the units in the description-stmt (could also apply
> elsewhere)
>- Examples should use line continuation convention
> e.g.:
> OLD:
> 10-10-2017 07:33:55.300 Z+05:30
>
> NEW:
> 10-10-2017 07:33:55.300 Z+05:30\
>
>- a spell checker should be used; There are many description-stmts
> with spelling errors
>
[Authors]: All the above comments are updated
___
netmod mailing list
netmod@ietf.org
Re: [netmod] xpath expressions in JSON
Martin Bjorklund writes:
> Ladislav Lhotka wrote:
>> On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:
>> >
>> >
>> > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman)
>> >
>> > wrote:
>> > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
>> > > netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:
>> > >
>> > > Ladislav Lhotka wrote:
>> > > > Martin Bjorklund writes:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > While reviewing restconf-notif, I saw this example:
>> > > > >
>> > > > >{
>> > > > > "ietf-subscribed-notifications:input": {
>> > > > > "stream": "NETCONF",
>> > > > > "stream-xpath-filter": "/ds:foo/",
>> > > > > "dscp": "10"
>> > > > > }
>> > > > >}
>> > > > >
>> > > > > Note the "stream-xpath-filter". It has a prefix in the XPath
>> > > string.
>> > > > > How are prefixes declared when JSON is used?
>> > > > >
>> > > > > The leaf "stream-xpath-filter" says:
>> > > > >
>> > > > > o The set of namespace declarations are those in
>> > > scope on
>> > > > > the 'stream-xpath-filter' leaf element.
>> > > > >
>> > > > > (I think I provided that text...)
>> > > > >
>> > > > > This assumes that the encoding is XML, or at leas that the
>> > > encoding
>> > > > > can somehow transfer namespace declarations.
>> > > >
>> > > > It can't. There are two options:
>> > > >
>> > > > 1. have different representations of this value in XML and JSON,
>> > > >analogically to instance indentifiers (sec. 6.11 in RFC 7951).
>> > > >
>> > > > 2. use a module name rather than a prefix in XML, too.
>> > > >
>> > > > I would suggest #2.
>> > > But that means making non-backwards compatible change to the XML
>> > > representation?
>> >
>> > Not really. It means NETMOD WG would be creating its own special variant of
>> > XPath.
>>
>> The thing is that XPath is "XML Path Language", so using it outside XML is
>> problematic.
>
> Not necessarily. Section 5 of the XPath 1.0 spec defins the "data
> model" where an XPath expression is applied. We could make a formal
> specification of how a YANG data tree maps to this data model (pretty
> straightforward...). I think experience from implementations over the
> last 8 years show that this in fact works quite well.
Except some parts that don't apply. For example, siblings nodes in XPath
are ordered, whereas in YANG 'foo[1]' may give unpredictable results.
This is probably OK in YANG modules but not so much if XPath expressions
are used as configuration data.
Lada
>
>
> /martin
>
>
>
>>
>> Lada
>>
>> >
>> > > Hmm, so you mean change the leaf "stream-xpath-filter" to say:
>> > >
>> > > o The set of namespace declarations has one member for each
>> > > YANG module supported by the server. This member maps
>> > > from the YANG module name to the YANG module namespace.
>> > >
>> > > This means that in the XPath expression, the module name
>> > > serves as the prefix.
>> > >
>> > > and then also give an example of this.
>> > >
>> > > This is probably what we need to do in all places where yang:xpath1.0
>> > > is used, going forward. Maybe even define a new type
>> > > yang:xpath1.0-2 (name?) with the set of namespace declarations
>> > > built-in.
>> >
>> >
>> > We should avoid making off-the-shelf implementations of standards like
>> > XPath
>> > unusable.
>> > At the very least this should be only available if the server supports it
>> > (with a capability URI)
>> >
>> >
>> > > So we need an update to RFC7951?
>> > >
>> > > Regards,
>> > > Reshad.
>> > >
>> >
>> >
>> > Andy
>> >
>> > > /martin
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > > Lada
>> > > >
>> > > > >
>> > > > > How is this supposed to work with JSON?
>> > > > >
>> > > > >
>> > > > > /martin
>> > > > >
>> > > > > ___
>> > > > > 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
>> >
>> >
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)
Hi, Benjamin Kaduk wrote: > On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote: > > Hi, > > > > Benjamin Kaduk wrote: > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-netmod-schema-mount-11: No Objection > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > > > > > > > > > -- > > > COMMENT: > > > -- > > > > > > Whenever we introduce a new namespace "sub-hierarchy" there is some level > > > of risk about surpirses with respect to the security properties of the > > > combined system. I appreciate that the mounted schemas are "jailed" into > > > their own subtree except for the specific exceptions for XPath access, > > > which helps a lot. But there may still be potential for surprise with > > > respect to, e.g., access control on mounted schemas, if an administrator > > > previously assumed that such controls would only be needed at the > > > top-level. The document itself doesn't give me a great picture of to what > > > extent these risks and the possible consequences of the new nested > > > structure have been considered; I'd be happy to hear if they've been > > > thought about a lot already and the conclusion was that the situation is > > > so > > > boring that nothing needs to be mentioned in the document. > > > > The intention was that this is covered in Section 7, Interaction with > > the Network Configuration Access Control Model (NACM). > > > > But it is probably a good idea to explicitly mention this in the > > Security Considerations section as well (together with your last point > > below). So maybe add a paragraph at the end of Section 11: > > > > It is important to take the security considerations for all nodes in > > the mounted schemas into account, and control access to these nodes > > by using the mechanism described in Section 7. > > I guess this addresses my concern; thanks. > > > > Section 3.3 > > > > > >If multiple mount points with the same name are defined in the same > > >module - either directly or because the mount point is defined in a > > >grouping and the grouping is used multiple times - then the > > >corresponding "mount-point" entry applies equally to all such mount > > >points. > > > > > > Does this mean that the multiple mount points must serve the same > > > data/contents, or just that they must use the same schema? > > > (Is this related to "inline" vs. "shared-schema"?) > > > > No, this document intentionally doesn't assume anything about the > > source of the instance data (as explained in section 1). So the > > answer is that they just use the same schema. > > > > > Section 3.4 > > > > > > So this means that there can be multiple > > > ietf-yang-schema-mount:schema-mounts:mount-point nodes at different > > > locations in the hierarchy? When I was first reading the document, the > > > design seemed fairly clean with just a single list of mount-points at the > > > "top-level" that tracks everything, but this kind of recursion seems like > > > it would make implementation potentially quite complex. What kind of > > > implementation experience do we have that can replace my half-informed > > > suppositions about complexity? > > > > I agree with you that multiple levels of mounting probably can be > > complex. But there is nothing in the design of schema mount that > > prohibits this. In fact, it "falls out for free" from the design. > > > > A 2-level example is a physical device with LNEs > > (draft-ietf-rtgwg-lne-model) which has NIs > > (draft-ietf-rtgwg-ni-model). > > > > > Section 4 > > > > > >Therefore, schema mount also allows for such references. For every > > >mount point in the "shared-schema" case, it is possible to specify a > > >leaf-list named "parent-reference" that contains zero or more XPath > > >1.0 expressions. [...] > > > > > > editorial: """the "shared-schema" case""" reads oddly to me; it might be > > > clearer to refer to schemas mounted using "shared-schema" instead. As in, > > > """For every mount point under "shared-schema", [...]""" > > > > We use the wording "in the 'shared-schema' case" in a couple of > > places. I don't think "mount point under 'shared-schema'" is > > correct. > > Okay. > > > > Can we get a reference added for XPath? > > > > Sure, I will add this. > > > > > It's still a little unclear to me
