Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
Lou Berger writes: >This starts a two week working group last call on >draft-ietf-netmod-revised-datastores-04. I have reviewed this document and have several minor recommendations. In addition, there were comments at the mic at the last IETF during the NETCONF WG meeting regarding the draft-dsdt-nmda-netconf-00.txt draft that refer to the architecture rather than the NETCONF mapping of that architecture, specifically on validation, and restraints on templating mechanisms. The video is: https://www.youtube.com/watch?v=wTlyEqTSuqo&feature=youtu.be&list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h&t=4726 I'm submitting these comments as a "diff" against the text source of the draft. Hopefully this is clear and precise. Thanks, Phil diff --git a/draft-ietf-netmod-revised-datastores.org b/draft-ietf-netmod-revised-datastores.org index b859760..be3b3b8 100644 --- a/draft-ietf-netmod-revised-datastores.org +++ b/draft-ietf-netmod-revised-datastores.org @@ -210,8 +210,8 @@ Some observations: - Operational state has not been defined as a datastore although there were proposals in the past to introduce an operational state datastore. -- The NETCONF operation returns the content of the running - configuration datastore together with the operational state. It is +- The NETCONF operation returns the content of + together with the operational state. It is therefore necessary that "config false" data is in a different branch than the "config true" data if the operational state can have a different lifetime compared to configuration or if @@ -318,6 +318,26 @@ If a device does not have a distinct and non-volatile is available, the device will typically use that non-volatile storage to allow to persist across reboots. +*** Validation + +The process of "validation" examines a datastore to ensure the +resulting configuration data will satisfy all data models constraints +given in ^YANG^ section 8.1. All constraints in all supported +data models must be satisfied for the data to be considered "valid". + +Validation will examine the data after any locally-defined templating +mechanism is performed and any inactive configuration is removed. + +While the operation of any specific templating mechanism is outside +the scope of this document, such mechanisms are constrained by the +rules of any data models, and cannot break the constraints given in +^YANG^. + +The implication of the existence of templating mechanisms is that + is now explicitly allowed to be invalid, since the +templating mechanism may be supplying additional data that satisfies +constraints that may be satisfied by itself. + ** The Intended Configuration Datastore () The intended configuration datastore () is a read-only @@ -422,6 +442,7 @@ error. does not persist across reboots. *** Remnant Configuration @remnant@ + Changes to configuration may take time to percolate through to . During this period, may contain nodes for both the previous and current configuration, as closely as @@ -709,12 +730,14 @@ This example defines a dynamic configuration datastore called "ephemeral", which is loosely modeled after the work done in the I2RS working group. - 1. Name: ephemeral - 2. YANG modules: all (default) - 3. YANG data nodes : all "config true" data nodes - 4. How applied : automatic - 5. Protocols : NC/RC (default) - 6. YANG Module : (see below) +| Name| Value| +|-+--| +| Name| ephemeral| +| YANG modules| all (default)| +| YANG data nodes | all "config true" data nodes | +| How applied | automatic| +| Protocols | NC/RC (default) | +| YANG Module | (see below) | !! include-figure example-ds-ephemeral.yang ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] syslog-model-17 shepherd writeup issues -references
Hi Tom, Thanks. The fix I'm looking for is for the 'pattern-match' leaf to have a 'reference' statement to Std-1003.1-2008, and for S4.1 to also list Std-1003.1-2008 as a draft-level reference. I was going to point out the typo "the the" as well, but figured that the RFC Editor would get it. K. // shepherd -- Kent You flag Std-1003.1-2008 as listed as a normative reference but not used anywhere in the document. In the Descriptions, but not in the s.4.1 references, I see This leaf describes a Posix 1003.2 regular expression ... twice, which may, or may not, relate to this issue. Back in July, clyde said "I will insert a normative reference to POSIX 1003.2 in the next revision of the draft." In a similar vein, RFC6991 appears in a reference statement but nowhere else. As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so should not be. And in a slightly different vein, registry [RFC7895]/>. Following the format in [RFC7950]/>, the the looks odd for plain text and for the repetition of 'the'.. Tom Petch - Original Message - From: "Kent Watsen" To: Cc: Sent: Tuesday, September 12, 2017 10:50 PM Subject: [netmod] syslog-model-17 shepherd writeup issues > Clyde, all, > > In reviewing the draft for Shepherd writeup, I found the following issues that I think need to be addressed before the document can be sent to Benoit for AD review: > > > 1. Idnits found the following: > > Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). > > ** There are 2 instances of too long lines in the document, the longest one > being 3 characters in excess of 72. > > ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) > > ** Downref: Normative reference to an Historic RFC: RFC 6587 > > == Missing Reference: 'RFC5425' is mentioned on line 359, but not defined > '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]' > > == Unused Reference: 'RFC7895' is defined on line 1406, but no explicit > reference was found in the text > '[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module L...' > > == Unused Reference: 'RFC6242' is defined on line 1435, but no explicit > reference was found in the text > '[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Sh...' > > > 2. `rfcstrip` extracted "ietf-syslog.yang", which is missing "@-mm-dd" in its name > > 3. neither `pyang` nor `yanglint` found any errors with ietf-syslog.yang.pyang says > for vendor-syslog-types-example: statement "identity" must have a "description" > substatement. > > 4. testing the examples in the draft against yanglint: > - for both examples: Missing element's "namespace". (/config) > - just removing the "" element envelop resolves this error. > > 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this SHOULD be a > domain name (e.g., foo.example.com) > > 6. in the YANG module, anywhere you have an RFC listed in a 'description' statement, > there should be a 'reference' statement for that RFC. > > 7. in the tree diagram, the leafrefs no longer indicate what they point at, they now all > just say "leafref". Did you do this on purpose, or are you using a different tree > output generator from -15? > > 8. RFC6536 is listed as a normative reference, but it probably should be informative. > > 9. Std-1003.1-2008 is listed as a normative reference, but it is not used anywhere in the document. > > 10. RFC6242 is listed as an informative reference, but it is not used anywhere in the document. > > 11. the document fails to declare its normative references to ietf-keystore and ietf-tls-client-server. > Note: you manually entered the "[RFC ], and [RFC ]" references… > > 12. The IANA considerations section seems asymmetric. Either put both registry insertions into > subsections, or keep them both at the top-level… > > 13. reviewing the final document against my original YD review, I have the following responses. Let's be sure to close out these items as well. Ref: https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11 s-0gOfCe8NSE > > 1. ok > 2. better > 3. should be: s/the message/these messages/ [RFC Editor might've caught this] > 4. better > 5. still feel the same way, but no biggee > 6. better, but from 8174, you should add the part "when, and only when, they appear in all capitals, as shown here." > 7. fixed > 8. fixed > 9. you did what I asked, but the result still isn't satisfying... > 10. some improvements made in this area, but my ask wasn't among them > 11. better > 12. better, but I think the 4th line should be indented too, right? > 13. better, but I wish you called S1.3 "Tree Diagram Notation" > 14. fixed > 15. fixed > 16. fixed > 17. fine > 18. still a weird line brake here. try putting the quoted string on the next line. > 19. fixed > 20. fixed > 21. not fixed (re: yang-security-
Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 duplicaiton
> I believe that text such as this would make the I-D much easier to > follow. As it stands, you have to read between the lines and speculate. Tom, Thank you for the comments. Do you have a specific change in mind, or could your propose text, that would address this? Thanks, Lou On 9/13/2017 12:42 PM, t.petch wrote: > I think that in one respect, perhaps the key respect, this I-D fails to > state the obvious (or at least what is likely obvious to those who have > been at this for a while:-). > > The problem that is hinted at but never explicitly stated is that data > objects can appear both as configuration and as state, e.g. when learned > by other means or at other times. The original model of datastores > required these data objects to be modelled twice, as configuration false > and as configuration true, and since there could be many of them, and > the rules of YANG require them to be in separate trees, this led to a > twin-trees approach such as can be seen in RFC7277 or RFC7223. > > Amongst other problems, this separation of operational state from > configuration in a >separate branch in the data model has been found to be operationally >complicated and impacts the readability of module >definitions. The relationship between >the branches is not machine readable and filter expressions operating >on configuration and on related operational state are different. > > With revised datastores, there is a single data object to model both > values but this now appears in two datastores, one for the > configuration value, one for the operational state value. > > Instead of two YANG data nodes there is one data node in two datastores, > a more elegant and simpler solution to the problem. > > > I believe that text such as this would make the I-D much easier to > follow. As it stands, you have to read between the lines and speculate. > > Tom Petch > > > - Original Message - > From: "Lou Berger" > To: "netmod WG" > Cc: ; > > Sent: Friday, September 01, 2017 10:02 PM > >> All, >> >> This starts a two week working group last call on >> draft-ietf-netmod-revised-datastores-04. >> >> The working group last call ends on September 17. >> Please send your comments to the netmod mailing list. >> >> Positive comments, e.g., "I've reviewed this document and >> believe it is ready for publication", are welcome! >> This is useful and important, even from authors. >> >> Thank you, >> Netmod Chairs >> >> ___ >> 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
Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 duplicaiton
I think that in one respect, perhaps the key respect, this I-D fails to state the obvious (or at least what is likely obvious to those who have been at this for a while:-). The problem that is hinted at but never explicitly stated is that data objects can appear both as configuration and as state, e.g. when learned by other means or at other times. The original model of datastores required these data objects to be modelled twice, as configuration false and as configuration true, and since there could be many of them, and the rules of YANG require them to be in separate trees, this led to a twin-trees approach such as can be seen in RFC7277 or RFC7223. Amongst other problems, this separation of operational state from configuration in a separate branch in the data model has been found to be operationally complicated and impacts the readability of module definitions. The relationship between the branches is not machine readable and filter expressions operating on configuration and on related operational state are different. With revised datastores, there is a single data object to model both values but this now appears in two datastores, one for the configuration value, one for the operational state value. Instead of two YANG data nodes there is one data node in two datastores, a more elegant and simpler solution to the problem. I believe that text such as this would make the I-D much easier to follow. As it stands, you have to read between the lines and speculate. Tom Petch - Original Message - From: "Lou Berger" To: "netmod WG" Cc: ; Sent: Friday, September 01, 2017 10:02 PM > All, > > This starts a two week working group last call on > draft-ietf-netmod-revised-datastores-04. > > The working group last call ends on September 17. > Please send your comments to the netmod mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > Netmod Chairs > > ___ > 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
Re: [netmod] schema mount open issue #1
Hi,
Lou Berger wrote:
> Hi,
>
> The LNI/NI authors/RTG Area DT met yesterday and discussed the proposed
> change as well as the other topics that came up in the subsequent
> discussion. The high order bit is that the proposed and current
> definitions are adequate for our needs. Read further if you care about
> details, including confirming our understanding:
>
> 1) WRT xpath context change proposed by martin
>
> Our understanding is that absolute paths continue to be allowed
Yes, this is correct.
> , for
> example the following remains valid:
>
> "use-schema": [
> {
> "name": "ni-schema",
> "parent-reference": [
> "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
> ]
> }
> ]
>
> Assuming yes, then we have no objection to the change (as it allows the
> server implementor to choose how/if they support vrf name filtering.
> Obviously, using the new syntax exposes the restriction to the client
> which is probably desirable.)
>
> 2. parent-reference location is adequate for our needs.
> This said, we think parent-references are more appropriately contained
> within the schema list and having them there will yield less complex
> operational data.
>
> 3. current mount point extension usage definition (must be in a list or
> container).
> Our use case is covered by always having a single mount point contained
> in a container. We don't see the need for mount point extensions within
> lists or for there to ever be siblings of mount point extensions.
>
> We don't see a need to discuss items 2 and 3 further at this time.
> Assuming our understanding is correct, we will update the NI and LNE
> draft as soon as schema mount is updated as proposed.
Ok, since we haven't seen any objections to the proposal, I will
update the schema mount draft accordingly.
/martin
>
> Lou
> (as contributor and NI/LNE draft co-author)
>
>
> On 8/30/2017 5:29 AM, Lou Berger wrote:
> > FYI I've asked folks in the routing area, i.e., the ietf users of schema
> > mount, if they have an opinion on the node discussion. I will also do so on
> > the point I raised on parent reference location. (Which is independent from
> > your format change.) Clearly, if I'm the only one to be raising objections,
> > I'll be the one in the rough on these points.
> >
> > Thanks,
> >
> > Lou
> > - as contributor
> >
> >
> > On August 30, 2017 3:42:26 AM Martin Bjorklund wrote:
> >
> >> Ladislav Lhotka wrote:
> >>> Lou Berger writes:
> >>>
> Lada,
>
>
> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
> > Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400:
> >> [...]
> >>
> >> PS is your view aligned with martin or our example?
> > If you mean shifting the XPath context node to the mount point
> > instance,
> >>> then
> > yes.
> >> So, going back to the original issue; does anyone have any objection
> >> to changing the XPath context for parent-reference as describied in my
> >> original post?
> >>
> >>
> >> /martin
> >>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] syslog-model-17 shepherd writeup issues -references
Kent You flag Std-1003.1-2008 as listed as a normative reference but not used anywhere in the document. In the Descriptions, but not in the s.4.1 references, I see This leaf describes a Posix 1003.2 regular expression ... twice, which may, or may not, relate to this issue. Back in July, clyde said "I will insert a normative reference to POSIX 1003.2 in the next revision of the draft." In a similar vein, RFC6991 appears in a reference statement but nowhere else. As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so should not be. And in a slightly different vein, registry [RFC7895]/>. Following the format in [RFC7950]/>, the the looks odd for plain text and for the repetition of 'the'.. Tom Petch - Original Message - From: "Kent Watsen" To: Cc: Sent: Tuesday, September 12, 2017 10:50 PM Subject: [netmod] syslog-model-17 shepherd writeup issues > Clyde, all, > > In reviewing the draft for Shepherd writeup, I found the following issues that I think need to be addressed before the document can be sent to Benoit for AD review: > > > 1. Idnits found the following: > > Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). > > ** There are 2 instances of too long lines in the document, the longest one > being 3 characters in excess of 72. > > ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) > > ** Downref: Normative reference to an Historic RFC: RFC 6587 > > == Missing Reference: 'RFC5425' is mentioned on line 359, but not defined > '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]' > > == Unused Reference: 'RFC7895' is defined on line 1406, but no explicit > reference was found in the text > '[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module L...' > > == Unused Reference: 'RFC6242' is defined on line 1435, but no explicit > reference was found in the text > '[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Sh...' > > > 2. `rfcstrip` extracted "ietf-syslog.yang", which is missing "@-mm-dd" in its name > > 3. neither `pyang` nor `yanglint` found any errors with ietf-syslog.yang.pyang says > for vendor-syslog-types-example: statement "identity" must have a "description" > substatement. > > 4. testing the examples in the draft against yanglint: > - for both examples: Missing element's "namespace". (/config) > - just removing the "" element envelop resolves this error. > > 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this SHOULD be a > domain name (e.g., foo.example.com) > > 6. in the YANG module, anywhere you have an RFC listed in a 'description' statement, > there should be a 'reference' statement for that RFC. > > 7. in the tree diagram, the leafrefs no longer indicate what they point at, they now all > just say "leafref". Did you do this on purpose, or are you using a different tree > output generator from -15? > > 8. RFC6536 is listed as a normative reference, but it probably should be informative. > > 9. Std-1003.1-2008 is listed as a normative reference, but it is not used anywhere in the document. > > 10. RFC6242 is listed as an informative reference, but it is not used anywhere in the document. > > 11. the document fails to declare its normative references to ietf-keystore and ietf-tls-client-server. > Note: you manually entered the "[RFC ], and [RFC ]" references… > > 12. The IANA considerations section seems asymmetric. Either put both registry insertions into > subsections, or keep them both at the top-level… > > 13. reviewing the final document against my original YD review, I have the following responses. Let's be sure to close out these items as well. Ref: https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11 s-0gOfCe8NSE > > 1. ok > 2. better > 3. should be: s/the message/these messages/ [RFC Editor might've caught this] > 4. better > 5. still feel the same way, but no biggee > 6. better, but from 8174, you should add the part "when, and only when, they appear in all capitals, as shown here." > 7. fixed > 8. fixed > 9. you did what I asked, but the result still isn't satisfying... > 10. some improvements made in this area, but my ask wasn't among them > 11. better > 12. better, but I think the 4th line should be indented too, right? > 13. better, but I wish you called S1.3 "Tree Diagram Notation" > 14. fixed > 15. fixed > 16. fixed > 17. fine > 18. still a weird line brake here. try putting the quoted string on the next line. > 19. fixed > 20. fixed > 21. not fixed (re: yang-security-guidelines) > 22. fine > > > PS: please also be sure to follow-up with Benoit on his AD review. > > Thanks, > Kent // shepherd & yang doctor > > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > __
Re: [netmod] draft-srivastav-netmod-formulae-00
Hi Sudhanshu,
Thanks for posting this.
The premise of what you are trying to achieve here is interesting. My
interpretation is that your idea is to allow a NETCONF/RESTCONF
server/device to take existing data in the operational state data tree
and to construct new derived data (or perhaps just metadata) by
executing a client defined algorithm that is described via extensions
statements to YANG.
This broadly seems a reasonable idea to me, but I'm not sure that I
would implement it in quite the same way, and I've put forward some
other points or issues that you may want to consider.
1) In particular, rather than modeling the expression directly in YANG
using YANG extensions, which effectively makes the expression look like
quite a verbose abstract syntax tree, I think that you may be better off
defining a separate expression language, similar to how Xpath is used
today. Probably it could be related to Xpath, perhaps it could be a
superset.
E.g .to take your example in 3.10, I think that it would be better if
the expression was written more like a normal mathematical expression.
E.g. I think that the following would be easier to read/understand.
Obviously an implementation needs to parse the expression, but that
shouldn't be too difficult, and they would need to write code to
interpret the expression anyway.
container formula {
leaf a {
type int32;
}
... leaves b to d defined similarly ...
leaf e {
type int32;
}
mt:math x {
leaf x {
type int32;
mt:expression"((a+b) - (c-d)/(e*100))";
}
}
2) I think that there are some questions about how these expressions
would get programmed into the device. Are they statically included as
part of the schema loaded by the NETCONF/RESTCONF server? Or are they
programmed dynamically via the NETCONF/RESTCONF client. For the latter
case it would be necessary to either define new RPC operations, or
perhaps better a configuration and operational YANG data model to manage
the expressions.
3) I think that it would also need to be considered whether the
constructed expression values are represented as new nodes in the YANG
schema (which would probably prevent them from be constructed
dynamically), or perhaps they should make use of YANG metadata (RFC
7952) instead so that the base underlying schema isn't changed.
4) Any solution should probably also consider how it would inter-operate
with the work currently being doing in NETCONF on YANG push and related
technologies.
5) They may be security implications of allowing a client to execute
arbitrarily complex expressions would may degrade the performance of the
system, although perhaps the memory and cpu available to execute the
expressions could be limited.
I hope the brief feedback is useful. I'm not sure how familiar you are
with the IETF process, but please note that these comments just
represent my personal opinion and do not necessarily reflect those of
the wider participants in the NETMOD WG. Other opinions may, and in my
experience probably will, differ :-)
Thanks,
Rob
On 13/09/2017 08:30, Sudhanshu Kumar Srivastav wrote:
Dear NETMOD Team,
I have submitted a draft for new YANG module that defines new YANG
extension statements and method to model the formulae/KPI's.
Request you to please check and provide your comments.
*Draft Details:*
Name: draft-srivastav-netmod-formulae
Revision: 00
Title: YANG extension Statements for formulae modeling
Document date: 2017-09-12
Group: Individual Submission
Pages: 28
URL:
https://www.ietf.org/internet-drafts/draft-srivastav-netmod-formulae-00.txt
Status: https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/
Htmlized: https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00
Regards
Sudhanshu
___
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
[netmod] draft-srivastav-netmod-formulae-00
Dear NETMOD Team, I have submitted a draft for new YANG module that defines new YANG extension statements and method to model the formulae/KPI's. Request you to please check and provide your comments. Draft Details: Name: draft-srivastav-netmod-formulaeRevision: 00Title: YANG extension Statements for formulae modelingDocument date: 2017-09-12Group: Individual SubmissionPages: 28URL: https://www.ietf.org/internet-drafts/draft-srivastav-netmod-formulae-00.txtStatus: https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/Htmlized: https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00Htmlized: https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00 Regards Sudhanshu ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
