Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani  wrote:

> For folks that provided comments as part of LC, please verify that your
> comments have been adequately addressed by -03 version of the draft.
>
>

Most comments have been addressed.


The "with-defaults" parameter does not apply when interacting with an

operational datastore.


There is no explanation of why the with-defaults parameter does not apply
to .
This is confusing. The solution that has been a standard for years still
applies to
all datastores, except a completely different mechanism (origin-filter) is
used instead
for 1 datastore.

If the server code can identify a default so it can be tagged
origin=or:default, then it can
also support with-defaults.

I prefer the sentence above be changed, so that a server MAY implement
with-defaults
for .  If the client sends  it should be OK to
honor it instead
of returning an error.


Andy




> Thanks
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund  wrote:
> >
> > Hi,
> >
> > Mahesh Jethanandani  wrote:
> >> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.
> >>
> >> As part of the LC, there were a couple of comments/questions
> >> raised. In particular
> >>
> >> - Vladmir reported an error, which Martin said is fixed in his local
> copy.
> >
> > Fixed.
> >
> >> - Robert suggested that “/yang-library/checksum” should be a
> >>  reference. Juergen supported that comment, so I am assuming that
> >>  that will be incorporated into the draft.
> >
> > Yes, fixed.
> >
> >> - Andy had questions around datastore set to “conventional”
> >
> > Fixed.
> >
> >>  , about origin filter limited to 1 source
> >
> > Fixed.
> >
> >>  and the behavior of with-defaults.
> >
> > There were no additional changes to the document from the discussion
> > about this.
> >
> >>  I see some discussion around it with the authors
> >>  agreeing that some of them need some text clarifying the
> >>  position. Can the authors please post the suggested text/additions
> >>  for the WG to review.
> >> - Anything else??
> >>
> >> Once an updated draft has been posted, I will do a writeup on the
> >> drafts and send it to IESG.
> >
> > The issues above are now addressed, in
> > draft-ietf-netconf-nmda-netconf-03.
> >
> > There were no additional comments on
> > draft-ietf-netconf-nmda-restconf-02, so I believe this version is
> > ready.
> >
> >
> > /martin
> >
> >
> >>
> >> Thanks.
> >>
> >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> >>>
> >>> On Wed, Jan 31, 2018 at 04:53:48PM +, Eric Voit (evoit) wrote:
> 
>  I do have one additional thought below on 
>  draft-ietf-netmod-revised-datastores
> section 5.3 default handling process.  See in-line...
> 
> >>>
> >>> Well, this document is with the RFC editor now. I do not think it needs
> >>> clarification. It already has text in 5.3 such as:
> >>>
> >>>  Requests to retrieve nodes from  always return the value
> >>>  in use if the node exists, regardless of any default value specified
> >>>  in the YANG module.  If no value is returned for a given node, then
> >>>  this implies that the node is not used by the device.
> >>>
> >>> /js
> >>>
>  From: Robert Wilton -X, January 31, 2018 6:31 AM
> 
> 
>  Hi Andy,
> 
>  On 31/01/2018 09:22, Andy Bierman wrote:
> 
> 
>  On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de  jacobs-university.de>>> wrote:
> > On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> > Hi,
> >
> > I have some questions about these drafts.
> >
> > 1) what if datastore set to "conventional"?
> >   There are many places where a datastore-ref type is used.
> >   However, "conventional" is valid for base "datastore", even though
> >   it is ambiguous as a datastore selector.
> 
>  We can add explicit text that an identity that does not resolve to a
>  datastore implemented by the server results in an invalid value error.
> 
> 
>  OK
> 
> 
> > 2) origin filter is limited to 1 source
> >  This filtering seems rather limited.  A client must retrieve
> >  and check
> >   all the values in use, then make repeated requests for each source
> as a
> > different
> >leaf
> 
>  If the client does , then it has all origin information
>  and it can filter locally. That said, we could make origin-filter a
>  leaf-list which is logically ORed so that one can retrieve
>  origin-filter=or:system or origin-filter=or:learned in one request.
> 
> 
>  OK
> 
> > 3) with-defaults broken
> >   The operational datastore does not support with-defaults.
> >Instead, the client must use origin-fil

[netmod] Eric Rescorla's No Objection on draft-ietf-netmod-yang-tree-diagrams-05

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-yang-tree-diagrams-05: 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-yang-tree-diagrams/


There are no remarks associated with this position.




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

[Kent Watsen]

Hi Clyde,

The chairs were discussing the HISTORIC reference to RFC 6587.   As we 
understand it, RFC 6587 was actually originally published as a HISTORIC 
document to accommodate Security area concerns.  Apparently, Benoit was AD at 
the time, so he may recall.  The IETF took special effort to publish RFC 6587 
anyway, likely due to TCP being in common use.  Anyway, we're wondering, must 
this document have a normative reference to RFC 6587?  - could it be made 
Informational instead?  Is understanding RFC 6587 necessary to implement the 
syslog draft?

We also discussed the normative references to the keystore-and-friends drafts.  
 As it stands, my shepherd write-up is going to have to call these out as 
unstable dependencies.   I know that it was discussed before, but would you 
have any appetite to revisit having TLS in the first version of this module?  
Perhaps it could be picked it up in a bis?

When can you post an update?  Would you rather us appoint an Editor to help get 
it done sooner?  I think that we've been in this post-LC phase for nearly four 
months now...

Kent // shepherd


= original message =

Kent

My request for a reference for Posix hs been fixed in -19.

Tom Petch

- Original Message -
From: "Kent Watsen" 
To: 
Sent: Tuesday, January 16, 2018 4:59 PM

> Clyde,
>
> This draft still isn't passing idnits.  I provided the link to idnits
previously, but here it is again: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tools_idnits&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q&s=HHa4Kg7ZoXOz6uC9VkiT_-jMeGdW9Kbfo1CydiT4bM8&e=.
Below is the idnits output for -19 with inlined comments.
>
> PS: I didn't also checked the other issues we're tracking, but will
when we get past these idnits issues.
>
> Kent
>
>
> = START =
> idnits 2.15.00
>
> /tmp/draft-ietf-netmod-syslog-model-19.txt:
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__trustee.ietf.org_license-2Dinfo&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q&s=L95k8rDeNKaSZXkCpqx2hwzmGDw8trmzmYOT0SLU-fQ&e=):
>   

>
>  No issues found here.
>
>   Checking nits according to
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_1id-2Dguidelines.txt&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q&s=wrmo4jVcBb7-_LFH7ty-TOpG80tfe3pWbfCSFZaT6eY&e=:
>   

>
>  No issues found here.
>
>   Checking nits according to 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_checklist&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q&s=_seSaCKfzxYeb3b1tfX2RqUk7CKbOsRr3pRVJrQ8lEc&e=
>  :
>   

>
>   ** There is 1 instance of too long lines in the document, the
longest one
>  being 1 character in excess of 72.
>
> Kent: this isn't a big deal IMO, but if it's easy to fix, it saves the
RFC editor a step later on.
>
>
>   Miscellaneous warnings:
>   

>
>   == Line 352 has weird spacing: '...gorithmide...'
>
> Kent: this is fine.  it is in a tree diagram.
>
>
>   == The document seems to lack the recommended RFC 2119 boilerplate,
even if
>  it appears to use RFC 2119 keywords -- however, there's a
paragraph with
>  a matching beginning. Boilerplate error?
>
>  (The document does seem to have the reference to RFC 2119 which
the
>  ID-Checklist requires).
>
> Kent: I can't find the error.  Looking at the xml, it is verbatim what
I have in the zerotouch draft.  my guess is that this is a tooling error
and we should ignore it.
>
>
>   -- The document date (January 12, 2018) is 4 days in the past.  Is
this
>  intentional?
>
> Kent: this is fine, it is intentional.
>
>
>   Checking references for intended status: Proposed Standard
>   

>
>  (See RFCs 3967 and 4897 for information about using normative
references
>  to lower-maturity documents in RFCs)
>
>   == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line
1386,
>  but no explicit reference was found in the text
>
> Kent: looking at the XML, I see that the entire paragraph uses '[' and
']' as opposed to .  Please fix this.
>
>
>   == Unused Reference: 'RFC7895' is defined on line 1456, but no
explicit
>  reference

Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[Acee Lindem (acee)]

I support netmod WG adoption.
Thanks,
Acee

From: netmod  on behalf of joel jaeggli 

Date: Tuesday, February 6, 2018 at 6:58 PM
To: "netmod@ietf.org" 
Subject: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: 
draft-rtgyangdt-netmod-module-tags-02


Sorry, Feb 20th is the end date for the adoption call.

regards

joel

On 2/6/18 3:47 PM, joel jaeggli wrote:

Hi,

This is the start of a *two* week poll on making 
draft-rtgyangdt-netmod-module-tags-02 a working group document.

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or "no/do not support".  
If indicating no, please state your reservations with the document.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-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] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[Dean Bogdanovic]

yes/support

no, I'm not aware of any IPR that applies to this document...

Dean
> On Feb 6, 2018, at 18:57, joel jaeggli  wrote:
> 
> Sorry, Feb 20th is the end date for the adoption call.
> 
> regards
> 
> joel
> 
>> On 2/6/18 3:47 PM, joel jaeggli wrote:
>> Hi, 
>> 
>> This is the start of a *two* week poll on making 
>> draft-rtgyangdt-netmod-module-tags-02 a working group document.  
>> 
>> https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02
>> This document was most recently discussed at IETF 100.
>> 
>> Please send email to the list indicating "yes/support" or "no/do not 
>> support".  If indicating no, please state your reservations with the 
>> document.  If yes, please also feel free to provide comments you'd like to 
>> see addressed once the document is a WG document. 
>> 
>> This poll ends on February 8. 
>> 
>> Thank you! 
>> Joel Jaeggli and IETF NETMOD Co-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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IPR call draft-rtgyangdt-netmod-module-tags-02

[joel jaeggli]

If any authors or participants are aware of IPR covering the proposed
working-group item:

draft-rtgyangdt-netmod-module-tags-02

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

Now would be a good time to declare it.

Thanks

joel


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[Lou Berger]

yes/support

no, I don't know of any IPR that applies to this document...

Lou

(as co-author)

On 2/6/2018 6:57 PM, joel jaeggli wrote:


Sorry, Feb 20th is the end date for the adoption call.

regards

joel


On 2/6/18 3:47 PM, joel jaeggli wrote:


Hi,

This is the start of a *two* week poll on making 
draft-rtgyangdt-netmod-module-tags-02 a working group document.


https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or "no/do not 
support".  If indicating no, please state your reservations with the 
document.  If yes, please also feel free to provide comments you'd 
like to see addressed once the document is a WG document.


This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-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


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[Andy Bierman]

Hi,

support starting this work.
The draft avoids discussion of any useful operations based on tags.
Setting and clearing tags is fine, but what about ?
What about NACM rules based on tags?
If protocol operations using tags are out of scope, then the draft should
say that.

(And don't forget NMDA compliance ;-)


Andy


On Tue, Feb 6, 2018 at 3:47 PM, joel jaeggli  wrote:

> Hi,
>
> This is the start of a **two** week poll on making
> draft-rtgyangdt-netmod-module-tags-02 a working group document.
>
> https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02
>
> This document was most recently discussed at IETF 100.
>
> Please send email to the list indicating "yes/support" or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd like to
> see addressed once the document is a WG document.
>
> This poll ends on February 8.
>
> Thank you!
>
> Joel Jaeggli and IETF NETMOD Co-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] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[Jeff Tantsura]

Yes/support

 

On 2/6/18 3:47 PM, joel jaeggli wrote:

Hi, 

This is the start of a *two* week poll on making 
draft-rtgyangdt-netmod-module-tags-02 a working group document.  

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or "no/do not support".  
If indicating no, please state your reservations with the document.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document. 

This poll ends on February 8. 

Thank you! 

Joel Jaeggli and IETF NETMOD Co-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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[joel jaeggli]

Sorry, Feb 20th is the end date for the adoption call.

regards

joel


On 2/6/18 3:47 PM, joel jaeggli wrote:
>
> Hi,
>
> This is the start of a *two* week poll on making
> draft-rtgyangdt-netmod-module-tags-02 a working group document.  
>
> https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02
>
> This document was most recently discussed at IETF 100.
>
> Please send email to the list indicating "yes/support" or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd
> like to see addressed once the document is a WG document.
>
> This poll ends on February 8.
>
> Thank you!
>
> Joel Jaeggli and IETF NETMOD Co-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

[netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[joel jaeggli]

Hi,

This is the start of a *two* week poll on making
draft-rtgyangdt-netmod-module-tags-02 a working group document.  

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.

This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-Chairs

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-16.txt

[Mahesh Jethanandani]

Kristian,

As I commented on the PR, putting the ‘container’ inside of the ‘choice’ 
statement allows me to collapse the ‘container’ and the ‘case’ statement into a 
single ‘container’ statement. With your changes, I see an additional ‘case’ 
statement, bloating the model in four places.

Cheers.

> On Feb 6, 2018, at 1:42 AM, Kristian Larsson  wrote:
> 
> Mahesh,
> 
> I suppose, since you posted the update Friday night, that I missed my chance 
> of prettifying the source/destination port choice/container structure that 
> was just added. If not, it's in a PR towards your repo - 
> https://github.com/mjethanandani/acl-model/pull/4
> 
> Kind regards,
>   Kristian.
> 
> 
> 
> On 2018-02-03 02:41, Mahesh Jethanandani wrote:
>> This update addresses the comments that were received as part of LC. For 
>> those of you who commented on the draft during the LC, please verify that 
>> your comments have been addressed.
>> Thanks.
>>> On Feb 2, 2018, at 5:26 PM, 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   : Network Access Control List (ACL) YANG Data Model
>>>Authors : Mahesh Jethanandani
>>>  Lisa Huang
>>>  Sonal Agarwal
>>>  Dana Blair
>>> Filename: draft-ietf-netmod-acl-model-16.txt
>>> Pages   : 54
>>> Date: 2018-02-02
>>> 
>>> Abstract:
>>>   This document describes a data model of Access Control List (ACL)
>>>   basic building blocks.
>>> 
>>>   Editorial Note (To be removed by RFC Editor)
>>> 
>>>   This draft contains many placeholder values that need to be replaced
>>>   with finalized values at the time of publication.  This note
>>>   summarizes all of the substitutions that are needed.  Please note
>>>   that no other RFC Editor instructions are specified anywhere else in
>>>   this document.
>>> 
>>>   Artwork in this document contains shorthand references to drafts in
>>>   progress.  Please apply the following replacements
>>> 
>>>   o  "" --> the assigned RFC value for this draft both in this
>>>  draft and in the YANG models under the revision statement.
>>> 
>>>   o  Revision date in model needs to get updated with the date the
>>>  draft gets approved.  The date also needs to get reflected on the
>>>  line with .
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16
>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-16
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-16
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> Mahesh Jethanandani
>> mjethanand...@gmail.com
>> ___
>> 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

Mahesh Jethanandani
mjethanand...@gmail.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Robert Wilton]

Yes, my comment on the YANG library checksum reference has been 
adequately addressed by the -03 version of the draft.


Thanks,
Rob


On 05/02/2018 21:33, Mahesh Jethanandani wrote:

For folks that provided comments as part of LC, please verify that your 
comments have been adequately addressed by -03 version of the draft.

Thanks

Mahesh Jethanandani
mjethanand...@gmail.com


On Feb 5, 2018, at 9:43 AM, Martin Bjorklund  wrote:

Hi,

Mahesh Jethanandani  wrote:

This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.

As part of the LC, there were a couple of comments/questions
raised. In particular

- Vladmir reported an error, which Martin said is fixed in his local copy.

Fixed.


- Robert suggested that “/yang-library/checksum” should be a
  reference. Juergen supported that comment, so I am assuming that
  that will be incorporated into the draft.

Yes, fixed.


- Andy had questions around datastore set to “conventional”

Fixed.


  , about origin filter limited to 1 source

Fixed.


  and the behavior of with-defaults.

There were no additional changes to the document from the discussion
about this.


  I see some discussion around it with the authors
  agreeing that some of them need some text clarifying the
  position. Can the authors please post the suggested text/additions
  for the WG to review.
- Anything else??

Once an updated draft has been posted, I will do a writeup on the
drafts and send it to IESG.

The issues above are now addressed, in
draft-ietf-netconf-nmda-netconf-03.

There were no additional comments on
draft-ietf-netconf-nmda-restconf-02, so I believe this version is
ready.


/martin



Thanks.


On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder 
 wrote:

On Wed, Jan 31, 2018 at 04:53:48PM +, Eric Voit (evoit) wrote:

I do have one additional thought below on draft-ietf-netmod-revised-datastores 
section 5.3 default handling process.  See in-line...


Well, this document is with the RFC editor now. I do not think it needs
clarification. It already has text in 5.3 such as:

  Requests to retrieve nodes from  always return the value
  in use if the node exists, regardless of any default value specified
  in the YANG module.  If no value is returned for a given node, then
  this implies that the node is not used by the device.

/js


From: Robert Wilton -X, January 31, 2018 6:31 AM


Hi Andy,

On 31/01/2018 09:22, Andy Bierman wrote:


On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de>>> wrote:

On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
Hi,

I have some questions about these drafts.

1) what if datastore set to "conventional"?
   There are many places where a datastore-ref type is used.
   However, "conventional" is valid for base "datastore", even though
   it is ambiguous as a datastore selector.

We can add explicit text that an identity that does not resolve to a
datastore implemented by the server results in an invalid value error.


OK



2) origin filter is limited to 1 source
  This filtering seems rather limited.  A client must retrieve
 and check
   all the values in use, then make repeated requests for each source as a
different
leaf

If the client does , then it has all origin information
and it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=or:system or origin-filter=or:learned in one request.


OK


3) with-defaults broken
   The operational datastore does not support with-defaults.
Instead, the client must use origin-filter=or:default or with-origin
and check all the origin attributes.  Since a client needs to use
with-defaults for other datastores, this special handling of

seems unhelpful.

I think the with-defaults semantics for conventional configuration
datastores are much more complicated than necessary for the
operational state datastore. Note that that the operational state
datastore reports in-use values not really defaults:

foo

This reports that the value 'foo' is in use and that it originates
from a default value. Note that this could also be

foo

in case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The with-defaults
solution is pretty complex because it tries to handle how different
systems deal with configuration defaults. The idea is to not carry
this complexity over to in-use values in the operational state
datastore.


Before NMDA, the client could decide if it wanted to retrieve default nodes or 
not.
This client-choice has been removed from NMDA, which is a problem.
We tried to reach a sensible compromise on the data returned from operational 
(defined in section 5.3 of the NMDA architecture):
- it should return explicit values for everything that is affecting the actual 
running state of the device (re

Re: [netmod] schema-mount pre09 branch

[Robert Wilton]

On 06/02/2018 14:16, Juergen Schoenwaelder wrote:

On Tue, Feb 06, 2018 at 10:19:49AM +0100, Martin Bjorklund wrote:

Hi Juergen,

Thanks for your review, comments inline.

Juergen Schoenwaelder  wrote:

On Wed, Jan 31, 2018 at 09:36:07PM +, Kent Watsen wrote:

The authors created a "pre09" branch on GitHub a few weeks back.  On this 
branch, they completed a full update of the draft.  While waiting for details on how to 
proceed with regards to a SM-bis, we thought it would be helpful to make this text 
available now so that the technical parts can be discussed.  With this in mind, can folks 
please have a quick look and post any technical comments they have?


I have reviewed draft-ietf-netmod-schema-mount-pre-09 that I fetched
today from GitHub. Here are my comments:

* Perhaps the abstract can be improved. The single sentence that we
   have is not even quite correct.

This document defines a mechanism to combine YANG modules into the
schema defined in other YANG modules.

   According to YL bis, a datastore has a schema, which consists of a
   set of YANG modules. The terminology used in RFC 7950 is 'schema
   node' and 'schema tree'. Perhaps this sentence can be rewritten to
   better explain the purpose of this document.

Maybe something along the lines of:

   This document defines a mechanism to extend a datastore schema with
   other schemas.

It is still a bit terse...

One question here is: Does the datastore schema include the mounted
schema tree or not? We can side step this question by writing:

   This document defines a mechanism to extend a YANG schema tree with
   other schema trees.

This is still terse but I think in terms of terminology this is
clear and correct.
  

* Definition of inline schema:

o  inline schema: a mounted schema whose definition is provided as
   part of the mounted data, using YANG library
   [I-D.ietf-netconf-rfc7895bis].

I am not sure 'as part of the mounted data, using YANG library' is
a good definition. Which YANG library? I think what this term means
is a mount point specific YANG library, not the master server's
YANG library.

This is also why I was largely confused about the inline case; the
schema used by the mountpoint is not defined inline from the master
server's point of view, from which the document is written. From
the master server's point of view, the 'inline schema' is actually
the opposite, it is an 'external schema' since I have to pull the
schema information from an external source;

No this is not quite correct.  It is "inline" from the master's point
of view, in the sense of "inline in the data tree", as opposed to
"part of the (augmented) yang-library schema definition".

This means its inline from the viewpoint of the mounted data, it is
external from the viewpoint of the master. You are swapping the
viewpoint here.
  

And it is *not* external.  The client still fetches this data from the
"master" server; and how the master server handles this is an
implementation detail (or possibly standardized in the future - *one*
use case is peer mount in which case the data is fetched from another
system, but again, this is just one example).

It is external from the viewpoint of the master servers YANG library. The
schema sits in a different YANG library instantiation. I have to fetch
this separately. This makes it kind of external for me.
I think that the term "external" could also be confusing, since I think 
that sort of implies peer mount like semantics.


I would suggest the term "dynamic" instead of "inline " but that could 
easily be confused with dynamic datastores.


Perhaps rather than "inline" another choice could be "discoverable", 
i.e. the schema is not known, and is dynamically discoverable inline at 
the mount point.
Equally, rather than "use-schema", perhaps a better choice would be 
"known", i.e. the schema is already known, and made available as part of 
YANG library.


Whether it would be right to change these at this time, I've no idea ...

Thanks,
Rob

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] schema-mount pre09 branch

[Robert Wilton]

Hi Martin,


On 06/02/2018 14:00, Martin Bjorklund wrote:

Hi,

Thanks for your comments, see inline.

Robert Wilton  wrote:

Hi,

Some comments on the pre-09 version, particularly the data model.


1) I still don't get why this draft is called "YANG Schema Mount"
rather than "YANG Mount", since to me this implies that it *only* the
schema that is being made available, and by implication not the
instance data.  I.e. I can see what schema a VM is using, but I cannot
access the instance data of that VM.

I understand the scope of the draft (and I'm not trying to change that
at all), and agree that it doesn't specify any protocol for how to
remotely mount data (e.g. peer mount).  But my understanding of the
solution here is that it doesn't just mount the schema.  I think that
it also always makes the mounted instance data available using the
regular NETCONF/RESTCONF operations right?  Which sounds like it is
doing more than just mounting the schema!

Once you have a mounted schema, even in the inline case, a server
might be just a single normal server with no extra VMs or anything;
you just have a nested schema.  Such a server would allow you to use
normal edit-config to add mounted data, and it would just affect that
single server's database and instrumentation.
OK.  So, it is not just the schema that is available, but also the 
instance data associated with that schema.



The point is that schema mount says nothing about *how* things are
instantiated.

I agree.

But I think that is also consistent with how the term "mount" is used 
from its Unix heritage.


I.e. just because some data is mounted doesn't imply that it is remote.  
E.g. if I look at my Linux VM's /etc/mtab I see a dozen mount points, 
only one of which I would class as being remote (from the perspective of 
the VM).


Whereas, to me the term "schema mount" implies that it is only the 
schema that are being mounted.  Why would there be instance data 
available if the only thing that is being mounted is the schema?




Peer mount, OTOH, attaches instance-specific meaning to its mount
points - if you try to write to peer mounted data the server will act
as a "proxy" and write to the remote server.  (ok, current peer mount
is defined to be read-only, but you get my point).

Yes, OK.  But I don't think that the term "YANG Mount" implies "Peer mount".

Extending the filesystem analogy further, I think that YANG mount tell 
you the mounted path, whether it is read/write, and where to find the 
schema.  It doesn't specify what protocol is being used to access that 
data.  E.g. in future I could imagine that peer mount might want to 
augment the mount-point/inline to indicate further properties about the 
mount point.  But this would seem to be somewhat odd if what it is 
augmenting is a "YANG schema mount" rather than just a "YANG mount".





2) Regarding the YANG Data Model:

(i) Should "schema-mounts" just be "mounts", since it is already under
the "schema" container.

I don't have a strong opinion on this.


(ii) Should "parent-references" be part of the "use-schema" container,
or should then be part of a schema directly.  E.g. should schema-mount
augment yanglib:schema with both a "mounts" container and a
"parent-reference" leaflist.

This would mean the same parent-references for all mount points in a
schema, as opposed to per-mount-point parent-references as we have
today.  Lada, what's your opinion on this?


(iii) Do we definitely need the namespace list?  Shouldn't the
prefixes/namespaces be resolved against the implemented modules in the
referenced schema, or is this not sufficient?  If this is not
sufficient, I wonder if it would be helpful for the draft to describe
this.

It is not sufficient b/c the only prefixes available from the
implemented modules are the prefixes in the modules themselves, and
they aren't necessarily unique.
OK.  So would another choice could be to rather than having the 
namespace map from  prefix to namespace, instead have it as a map from 
prefix to module name (which is resolved against the implemented modules 
in the parent schema(s))?


The URI would still be available form the module entry in the parent 
schema (if required).  I'm just wondering whether this would make the 
binding feel a bit less XML encoding specific.


Thanks,
Rob




(iv) I agree with Juergen that "inline" is a confusing term because it
is meaning that the mounted schema is available inline in the instance
data tree, not that it is inline in the schema tree.



/martin




Thanks,
Rob


On 31/01/2018 21:36, Kent Watsen wrote:

All,

The authors created a "pre09" branch on GitHub a few weeks back.  On
this branch, they completed a full update of the draft.  While waiting
for details on how to proceed with regards to a SM-bis, we thought it
would be helpful to make this text available now so that the technical
parts can be discussed.  With this in mind, can folks please have a
quick look and post any technical comments they have?


The "

Re: [netmod] schema-mount pre09 branch

[Juergen Schoenwaelder]

On Tue, Feb 06, 2018 at 10:19:49AM +0100, Martin Bjorklund wrote:
> Hi Juergen,
> 
> Thanks for your review, comments inline.
> 
> Juergen Schoenwaelder  wrote:
> > On Wed, Jan 31, 2018 at 09:36:07PM +, Kent Watsen wrote:
> > > 
> > > The authors created a "pre09" branch on GitHub a few weeks back.  On this 
> > > branch, they completed a full update of the draft.  While waiting for 
> > > details on how to proceed with regards to a SM-bis, we thought it would 
> > > be helpful to make this text available now so that the technical parts 
> > > can be discussed.  With this in mind, can folks please have a quick look 
> > > and post any technical comments they have?  
> > >
> > 
> > I have reviewed draft-ietf-netmod-schema-mount-pre-09 that I fetched
> > today from GitHub. Here are my comments:
> > 
> > * Perhaps the abstract can be improved. The single sentence that we
> >   have is not even quite correct.
> > 
> >This document defines a mechanism to combine YANG modules into the
> >schema defined in other YANG modules.
> > 
> >   According to YL bis, a datastore has a schema, which consists of a
> >   set of YANG modules. The terminology used in RFC 7950 is 'schema
> >   node' and 'schema tree'. Perhaps this sentence can be rewritten to
> >   better explain the purpose of this document.
> 
> Maybe something along the lines of:
> 
>   This document defines a mechanism to extend a datastore schema with
>   other schemas.
> 
> It is still a bit terse...

One question here is: Does the datastore schema include the mounted
schema tree or not? We can side step this question by writing:

  This document defines a mechanism to extend a YANG schema tree with
  other schema trees.

This is still terse but I think in terms of terminology this is
clear and correct.
 
> > * Definition of inline schema:
> > 
> >o  inline schema: a mounted schema whose definition is provided as
> >   part of the mounted data, using YANG library
> >   [I-D.ietf-netconf-rfc7895bis].
> > 
> >I am not sure 'as part of the mounted data, using YANG library' is
> >a good definition. Which YANG library? I think what this term means
> >is a mount point specific YANG library, not the master server's
> >YANG library.
> > 
> >This is also why I was largely confused about the inline case; the
> >schema used by the mountpoint is not defined inline from the master
> >server's point of view, from which the document is written. From
> >the master server's point of view, the 'inline schema' is actually
> >the opposite, it is an 'external schema' since I have to pull the
> >schema information from an external source;
> 
> No this is not quite correct.  It is "inline" from the master's point
> of view, in the sense of "inline in the data tree", as opposed to
> "part of the (augmented) yang-library schema definition".

This means its inline from the viewpoint of the mounted data, it is
external from the viewpoint of the master. You are swapping the
viewpoint here.
 
> And it is *not* external.  The client still fetches this data from the
> "master" server; and how the master server handles this is an
> implementation detail (or possibly standardized in the future - *one*
> use case is peer mount in which case the data is fetched from another
> system, but again, this is just one example).

It is external from the viewpoint of the master servers YANG library. The
schema sits in a different YANG library instantiation. I have to fetch
this separately. This makes it kind of external for me.
 
> > * YANG library has a drawing of the underlying conceptual model. It
> >   may help to agree on how schema mount is extending the model. Here
> >   is a drawing that I created for myself:
> > 
> > +---+
> > | datastore |
> > +---+
> >  |
> >  | has a
> >  V
> > +---+++++
> > | datastore |  union of  | module |  consists of   | modules +  |
> >  .->|  schema   |--->|  set   |--->| submodules |
> >  |  +---+++++
> >  |   |
> >  |   | has
> >  |   v
> >  |  +---+
> >  '--|   mount   |-->  external YANG library
> >uses |   points  | uses  schema reference
> > +---+
> > 
> >   Note that this makes drawing makes my struggle with the term
> >   'inline' even more obvious.
> 
> I like the drawing, but I don't see the problem with the terms.  Maybe
> just b/c I'm used to them.  I think we can include this figure but
> s/external/inline/

Inline suggests to me that the schema details are reported inline of
this YANG library instantiation, i.e. the opposite of today's "inline"
case. In today's "inline" case, I have to fetch a different YANG
library instance and look things up there. I find it very confusing to
call this "inline"

Re: [netmod] schema-mount pre09 branch

[Martin Bjorklund]

Hi,

Thanks for your comments, see inline.

Robert Wilton  wrote:
> Hi,
> 
> Some comments on the pre-09 version, particularly the data model.
> 
> 
> 1) I still don't get why this draft is called "YANG Schema Mount"
> rather than "YANG Mount", since to me this implies that it *only* the
> schema that is being made available, and by implication not the
> instance data.  I.e. I can see what schema a VM is using, but I cannot
> access the instance data of that VM.
> 
> I understand the scope of the draft (and I'm not trying to change that
> at all), and agree that it doesn't specify any protocol for how to
> remotely mount data (e.g. peer mount).  But my understanding of the
> solution here is that it doesn't just mount the schema.  I think that
> it also always makes the mounted instance data available using the
> regular NETCONF/RESTCONF operations right?  Which sounds like it is
> doing more than just mounting the schema!

Once you have a mounted schema, even in the inline case, a server
might be just a single normal server with no extra VMs or anything;
you just have a nested schema.  Such a server would allow you to use
normal edit-config to add mounted data, and it would just affect that
single server's database and instrumentation.

The point is that schema mount says nothing about *how* things are
instantiated.

Peer mount, OTOH, attaches instance-specific meaning to its mount
points - if you try to write to peer mounted data the server will act
as a "proxy" and write to the remote server.  (ok, current peer mount
is defined to be read-only, but you get my point).

> 2) Regarding the YANG Data Model:
> 
> (i) Should "schema-mounts" just be "mounts", since it is already under
> the "schema" container.

I don't have a strong opinion on this.

> (ii) Should "parent-references" be part of the "use-schema" container,
> or should then be part of a schema directly.  E.g. should schema-mount
> augment yanglib:schema with both a "mounts" container and a
> "parent-reference" leaflist.

This would mean the same parent-references for all mount points in a
schema, as opposed to per-mount-point parent-references as we have
today.  Lada, what's your opinion on this?

> (iii) Do we definitely need the namespace list?  Shouldn't the
> prefixes/namespaces be resolved against the implemented modules in the
> referenced schema, or is this not sufficient?  If this is not
> sufficient, I wonder if it would be helpful for the draft to describe
> this.

It is not sufficient b/c the only prefixes available from the
implemented modules are the prefixes in the modules themselves, and
they aren't necessarily unique.

> (iv) I agree with Juergen that "inline" is a confusing term because it
> is meaning that the mounted schema is available inline in the instance
> data tree, not that it is inline in the schema tree.



/martin



> 
> Thanks,
> Rob
> 
> 
> On 31/01/2018 21:36, Kent Watsen wrote:
> > All,
> >
> > The authors created a "pre09" branch on GitHub a few weeks back.  On
> > this branch, they completed a full update of the draft.  While waiting
> > for details on how to proceed with regards to a SM-bis, we thought it
> > would be helpful to make this text available now so that the technical
> > parts can be discussed.  With this in mind, can folks please have a
> > quick look and post any technical comments they have?
> >
> >
> > The "txt" version of the draft:
> > https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt
> >
> >
> > rfcdiff against the current -08 draft:
> > https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08&url2=https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt
> >
> >
> > Since rfc7895bis obsoletes RFC 7895, the
> > server-must-implement-rfc7895bis requirement is no surprise, right?
> >
> > Thanks,
> > Kent // shepherd
> >
> >
> > ___
> > 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 pre09 branch

[Robert Wilton]

Hi,

Some comments on the pre-09 version, particularly the data model.


1) I still don't get why this draft is called "YANG Schema Mount" rather 
than "YANG Mount", since to me this implies that it *only* the schema 
that is being made available, and by implication not the instance data.  
I.e. I can see what schema a VM is using, but I cannot access the 
instance data of that VM.


I understand the scope of the draft (and I'm not trying to change that 
at all), and agree that it doesn't specify any protocol for how to 
remotely mount data (e.g. peer mount).  But my understanding of the 
solution here is that it doesn't just mount the schema.  I think that it 
also always makes the mounted instance data available using the regular 
NETCONF/RESTCONF operations right?  Which sounds like it is doing more 
than just mounting the schema!


2) Regarding the YANG Data Model:

(i) Should "schema-mounts" just be "mounts", since it is already under 
the "schema" container.


(ii) Should "parent-references" be part of the "use-schema" container, 
or should then be part of a schema directly.  E.g. should schema-mount 
augment yanglib:schema with both a "mounts" container and a 
"parent-reference" leaflist.


(iii) Do we definitely need the namespace list?  Shouldn't the 
prefixes/namespaces be resolved against the implemented modules in the 
referenced schema, or is this not sufficient?  If this is not 
sufficient, I wonder if it would be helpful for the draft to describe this.


(iv) I agree with Juergen that "inline" is a confusing term because it 
is meaning that the mounted schema is available inline in the instance 
data tree, not that it is inline in the schema tree.


Thanks,
Rob


On 31/01/2018 21:36, Kent Watsen wrote:

All,

The authors created a "pre09" branch on GitHub a few weeks back.  On this 
branch, they completed a full update of the draft.  While waiting for details on how to 
proceed with regards to a SM-bis, we thought it would be helpful to make this text 
available now so that the technical parts can be discussed.  With this in mind, can folks 
please have a quick look and post any technical comments they have?


The "txt" version of the draft:  
https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt


rfcdiff against the current -08 draft:  
https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08&url2=https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt


Since rfc7895bis obsoletes RFC 7895, the server-must-implement-rfc7895bis 
requirement is no surprise, right?

Thanks,
Kent // shepherd


___
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 pre09 branch

[Robert Wilton]

On 06/02/2018 09:19, Martin Bjorklund wrote:

Hi Juergen,

Thanks for your review, comments inline.

Juergen Schoenwaelder  wrote:


* YANG library has a drawing of the underlying conceptual model. It
   may help to agree on how schema mount is extending the model. Here
   is a drawing that I created for myself:

 +---+
 | datastore |
 +---+
  |
  | has a
  V
 +---+++++
 | datastore |  union of  | module |  consists of   | modules +  |
  .->|  schema   |--->|  set   |--->| submodules |
  |  +---+++++
  |   |
  |   | has
  |   v
  |  +---+
  '--|   mount   |-->  external YANG library
uses |   points  | uses schema reference
 +---+

   Note that this makes drawing makes my struggle with the term
   'inline' even more obvious.

I like the drawing, but I don't see the problem with the terms.  Maybe
just b/c I'm used to them.  I think we can include this figure but
s/external/inline/

I think that Juergen's diagram is helpful.

I also think that there needs to be some text to help explain how mount 
points interact with datastores.  I.e. each datastore can have separate 
mount points so data could be mounted in  but not  
or vice-versa.


Thanks,
Rob

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-16.txt

[Kristian Larsson]

Mahesh,

I suppose, since you posted the update Friday night, that I missed my 
chance of prettifying the source/destination port choice/container 
structure that was just added. If not, it's in a PR towards your repo - 
https://github.com/mjethanandani/acl-model/pull/4


Kind regards,
   Kristian.



On 2018-02-03 02:41, Mahesh Jethanandani wrote:

This update addresses the comments that were received as part of LC. For those 
of you who commented on the draft during the LC, please verify that your 
comments have been addressed.

Thanks.


On Feb 2, 2018, at 5:26 PM, 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   : Network Access Control List (ACL) YANG Data Model
Authors : Mahesh Jethanandani
  Lisa Huang
  Sonal Agarwal
  Dana Blair
Filename: draft-ietf-netmod-acl-model-16.txt
Pages   : 54
Date: 2018-02-02

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.

   Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  Please note
   that no other RFC Editor instructions are specified anywhere else in
   this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements

   o  "" --> the assigned RFC value for this draft both in this
  draft and in the YANG models under the revision statement.

   o  Revision date in model needs to get updated with the date the
  draft gets approved.  The date also needs to get reflected on the
  line with .


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com

___
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 pre09 branch

[Martin Bjorklund]

Hi Juergen,

Thanks for your review, comments inline.

Juergen Schoenwaelder  wrote:
> On Wed, Jan 31, 2018 at 09:36:07PM +, Kent Watsen wrote:
> > 
> > The authors created a "pre09" branch on GitHub a few weeks back.  On this 
> > branch, they completed a full update of the draft.  While waiting for 
> > details on how to proceed with regards to a SM-bis, we thought it would be 
> > helpful to make this text available now so that the technical parts can be 
> > discussed.  With this in mind, can folks please have a quick look and post 
> > any technical comments they have?  
> >
> 
> I have reviewed draft-ietf-netmod-schema-mount-pre-09 that I fetched
> today from GitHub. Here are my comments:
> 
> * Perhaps the abstract can be improved. The single sentence that we
>   have is not even quite correct.
> 
>This document defines a mechanism to combine YANG modules into the
>schema defined in other YANG modules.
> 
>   According to YL bis, a datastore has a schema, which consists of a
>   set of YANG modules. The terminology used in RFC 7950 is 'schema
>   node' and 'schema tree'. Perhaps this sentence can be rewritten to
>   better explain the purpose of this document.

Maybe something along the lines of:

  This document defines a mechanism to extend a datastore schema with
  other schemas.

It is still a bit terse...

> * The following text is not consistent with what YLbis says:
> 
>2.  Implementation-time: the mounted schema is defined by a server
>implementor and is as stable as YANG library information, i.e.,
>it may change after an upgrade of server software but not after
>rebooting the server.  Also, a client can learn the entire schema
>together with YANG library data.
> 
>   YLbis does allow YANG library to change. I think this text should
>   change as follows:
> 
>2.  Implementation-time: the mounted schema is defined by a server
>implementor and is as stable as YANG library information of the
>server. A client can learn the entire schema by reading the
>server's YANG library data.

Yes this is better.

>I think 3. should also be changed. The phrase 'is part of the
>mounted data model' may not be exactly true with NMDA - well
>depending what the 'mounted data model' really means. Perhaps
>something like this:
> 
>3.  Run-time: the mounted schema is defined by instance data that
>is associated with the mount point and reported outside the
>server's YANG library information. If there are multiple
>instances of the same mount point (e.g., in multiple entries of
>a list), the mounted data model may be different for each
>instance.

Ok.

> * Terminology - should this document import the terms client, server,
>   notification from the NMDA document instead of the NETCONF document?

Ok + "datastore schema".

>   I assume the terms are understood more broadly than just NETCONF
>   client and server.
> 
> * Definition of inline schema:
> 
>o  inline schema: a mounted schema whose definition is provided as
>   part of the mounted data, using YANG library
>   [I-D.ietf-netconf-rfc7895bis].
> 
>I am not sure 'as part of the mounted data, using YANG library' is
>a good definition. Which YANG library? I think what this term means
>is a mount point specific YANG library, not the master server's
>YANG library.
> 
>This is also why I was largely confused about the inline case; the
>schema used by the mountpoint is not defined inline from the master
>server's point of view, from which the document is written. From
>the master server's point of view, the 'inline schema' is actually
>the opposite, it is an 'external schema' since I have to pull the
>schema information from an external source;

No this is not quite correct.  It is "inline" from the master's point
of view, in the sense of "inline in the data tree", as opposed to
"part of the (augmented) yang-library schema definition".

And it is *not* external.  The client still fetches this data from the
"master" server; and how the master server handles this is an
implementation detail (or possibly standardized in the future - *one*
use case is peer mount in which case the data is fetched from another
system, but again, this is just one example).


>the schema is not
>reported with the server's schema information - this is what I
>would consider inline.
> 
>It may be too late to change this term but at least for me 'inline'
>has been very confusing since we describe everything from the
>perspective of the master server.
> 
>   Later on, the phrase "use-schema" case is used as well. Perhaps this
>   should also be a defined term

Ok, this makes sense.

>   and a better term should be used. The
>   terms should describe the concepts and the YANG model should follow;
>   what we have is kind of backwards, there is a YANG model and then
>   model names are used

Re: [netmod] schema-mount pre09 branch

[Juergen Schoenwaelder]

On Wed, Jan 31, 2018 at 09:36:07PM +, Kent Watsen wrote:
> 
> The authors created a "pre09" branch on GitHub a few weeks back.  On this 
> branch, they completed a full update of the draft.  While waiting for details 
> on how to proceed with regards to a SM-bis, we thought it would be helpful to 
> make this text available now so that the technical parts can be discussed.  
> With this in mind, can folks please have a quick look and post any technical 
> comments they have?  
>

I have reviewed draft-ietf-netmod-schema-mount-pre-09 that I fetched
today from GitHub. Here are my comments:

* Perhaps the abstract can be improved. The single sentence that we
  have is not even quite correct.

   This document defines a mechanism to combine YANG modules into the
   schema defined in other YANG modules.

  According to YL bis, a datastore has a schema, which consists of a
  set of YANG modules. The terminology used in RFC 7950 is 'schema
  node' and 'schema tree'. Perhaps this sentence can be rewritten to
  better explain the purpose of this document.

* The following text is not consistent with what YLbis says:

   2.  Implementation-time: the mounted schema is defined by a server
   implementor and is as stable as YANG library information, i.e.,
   it may change after an upgrade of server software but not after
   rebooting the server.  Also, a client can learn the entire schema
   together with YANG library data.

  YLbis does allow YANG library to change. I think this text should
  change as follows:

   2.  Implementation-time: the mounted schema is defined by a server
   implementor and is as stable as YANG library information of the
   server. A client can learn the entire schema by reading the
   server's YANG library data.

   I think 3. should also be changed. The phrase 'is part of the
   mounted data model' may not be exactly true with NMDA - well
   depending what the 'mounted data model' really means. Perhaps
   something like this:

   3.  Run-time: the mounted schema is defined by instance data that
   is associated with the mount point and reported outside the
   server's YANG library information. If there are multiple
   instances of the same mount point (e.g., in multiple entries of
   a list), the mounted data model may be different for each
   instance.

* Terminology - should this document import the terms client, server,
  notification from the NMDA document instead of the NETCONF document?
  I assume the terms are understood more broadly than just NETCONF
  client and server.

* Definition of inline schema:

   o  inline schema: a mounted schema whose definition is provided as
  part of the mounted data, using YANG library
  [I-D.ietf-netconf-rfc7895bis].

   I am not sure 'as part of the mounted data, using YANG library' is
   a good definition. Which YANG library? I think what this term means
   is a mount point specific YANG library, not the master server's
   YANG library.

   This is also why I was largely confused about the inline case; the
   schema used by the mountpoint is not defined inline from the master
   server's point of view, from which the document is written. From
   the master server's point of view, the 'inline schema' is actually
   the opposite, it is an 'external schema' since I have to pull the
   schema information from an external source; the schema is not
   reported with the server's schema information - this is what I
   would consider inline.

   It may be too late to change this term but at least for me 'inline'
   has been very confusing since we describe everything from the
   perspective of the master server.

  Later on, the phrase "use-schema" case is used as well. Perhaps this
  should also be a defined term and a better term should be used. The
  terms should describe the concepts and the YANG model should follow;
  what we have is kind of backwards, there is a YANG model and then
  model names are used a conceptual terms.

* YANG library stability

  I reported this already. The statement 'In particular, it SHOULD NOT
  change during the same management session.' is not consistent with
  what YL and YLbis say.

* YANG library has a drawing of the underlying conceptual model. It
  may help to agree on how schema mount is extending the model. Here
  is a drawing that I created for myself:

+---+
| datastore |
+---+
 |
 | has a
 V
+---+++++
| datastore |  union of  | module |  consists of   | modules +  |
 .->|  schema   |--->|  set   |--->| submodules |
 |  +---+++++
 |   |
 |   | has
 |   v
 |  +---+
 '--|   mount   |-->  external YANG library
   uses |   points  | uses  schema reference
+---+

  Not