Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

[Jiangyuanlong]

Tom,

Good to know all your viewpoints. We will add a sentence in Section 2 
explaining the logic of YANG style names in this document, maybe put it as a 
note in the 2nd paragraph (as these names are used in the 3rd paragraph) . 

Thanks,
Yuanlong

-Original Message-
From: t.petch [mailto:ie...@btconnect.com] 
Sent: Wednesday, November 08, 2017 9:12 PM
To: Jiangyuanlong; Alex Campbell; tic...@ietf.org
Cc: Xian Liu; Xujinchun; netmod@ietf.org
Subject: Re: [netmod] WG Last Call resolutions incorporated in 
draft-ietf-tictoc-1588v2-yang-06

Yuanglong

I think that your Introduction is fine, and would not shorten it at all.
(I think that the Introduction to most I-Ds that describe YANG modules is 
woefully weak).

I think too that you are spot on with your terminology; where IEEE
1588-2008 has an accepted way of working, then that is the right way for this 
I-D.

One fresh comment arising from that.  You commented earlier that you had 
departed from IEEE 1588-2008 in changing camel case to the YANG style names, 
with hyphens, and I think that that is a logical choice.  But I would go 
further and explain that choice so that those coming from IEEE
1588-2008 understand what has happened and why.  Not sure where to put that; 
probably Section 2, perhaps immediately before the tree diagram, since that is 
when readers will be exposed to the issue.

If you have done more than just change the style of name, then it would be 
worth having a concordance of IEEE 1588-2008 names and YANG names; this was 
common practice with MIB Modules.

Tom Petch

- Original Message -
From: "Jiangyuanlong" 
To: "Alex Campbell" ; 
Cc: "Xian Liu" ; "Xujinchun"
; 
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: [netmod] WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


> Hi Alex,
>
> Sorry for a late reply as I spent the last week for an urgent business
trip.
> Please see my comments in line with [YJ]
>
> Thanks,
> Yuanlong
>
> -Original Message-
> From: Alex Campbell [mailto:alex.campb...@aviatnet.com]
> Sent: Monday, October 30, 2017 10:15 AM
> To: Jiangyuanlong; tic...@ietf.org
> Cc: Xian Liu; Xujinchun; netmod@ietf.org
> Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
>
> Hi,
> I've reviewed this latest draft and have some more comments.
>
> 1. I find the introduction to be unnecessarily wordy; it feels like it
was written with a view of not missing any information out, rather than trying 
to keep it concise.
>For example, there is no need to elaborate on YANG data types here.
It is also not here to sell YANG.
>
> [YJ] Yes, we are trying to give some introductory information for an
outsider who may not be familiar with PTP or YANG, and explain why a YANG for 
PTP is needed. The juicy part of this document is its YANG module, and people 
can skip all the other texts if they are familiar with PTP and YANG.
> Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear message from 
the TICTOC chairs to introduce any big changes at this last call stage.
>
>
> OLD:
>
>As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
>supported in the carrier networks, industrial networks, automotive
>networks, and many other applications. It can provide high
>precision time synchronization as fine as nano-seconds. The
>protocol depends on a Precision Time Protocol (PTP) engine to
>decide its own state automatically, and a PTP transportation layer
>to carry the PTP timing and various quality messages. The
>configuration parameters and state data sets of IEEE 1588-2008 are
>numerous.
>
>According to the concepts described in [RFC3444], IEEE 1588-2008
>itself provides an information model in its normative
>specifications for the data sets (in IEEE 1588-2008 clause 8). Some
>standardization organizations including the IETF have specified
>data models in MIBs (Management Information Bases) for IEEE 1588-
>2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
>typically focused on retrieval of state data using the Simple
>Network Management Protocol (SNMP), furthermore, configuration of
>PTP data sets is not considered in [RFC8173].
>
>Some service providers and applications require that the management
>of the IEEE 1588-2008 synchronization network be flexible and more
>Internet-based (typically overlaid on their transport networks).
>Software Defined Network (SDN) is another driving factor, which
>demands an improved configuration capability of synchronization
>networks.
>
>YANG [RFC6020] is a data modeling language used to model
>configuration and state data manipulated by network management
>protocols like the Network 

[netmod] Agenda updated

[Lou Berger]

Please note that the agenda has been reordered to accommodate some
scheduling conflicts.  Please take note:
https://datatracker.ietf.org/meeting/100/materials/agenda-100-netmod/

Lou (and Kent)



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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

On Mon, Nov 06, 2017 at 07:16:11PM +, Kent Watsen wrote:
> 
> This closes the Last Call on this document.  There is
> clearly a lot of interest in the publication of an ACL
> model, but there also seems to be significant concern
> for how this model is structured.  It seems that we need
> to spend some more time to ensure the current structure
> is okay.  Based on the result of this discussion, we
> will then judge if this Last Call was successful of not.

I've probably ignited the most recent debate on this model. I'm
sorry for prolonging the process and preventing moving into RFC
but I really am not comfortable with the current structure.

Besides the structure, which is perhaps more subjective, I think
the model contains actual errors. For example, it appears that
there should be stats entries at the interface attachment points
but that data is config true and not config false and the leafref
doesn't match on the acl-type so it could point to any
acl-rule!? It's possible to match on conflicting data, like IPv4
and IPv6 or TCP and UDP in the same ACE, which just doesn't make
any sense at all. There is a match on interface but it is not
clear if this is ingress or egress interface. any-acl is empty!?

I am working on a couple of concrete suggestions for making a
more elegant model.

   kll

-- 
Kristian LarssonKLL-RIPE
+46 72 5479985k...@spritelink.net

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

Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

[Robert Wilton]

On 08/11/2017 13:26, Ladislav Lhotka wrote:

Hi Rob,

thank you for the review, my replies are inline.

Robert Wilton  writes:


Hi,

I have read this document and think that is almost ready for publication.

I have one general comment regarding the YANG module library (at the
end), and a few nits, but otherwise the draft looks good.

1. Sec 1. Introduction paragraph 2, "internal node".  It wasn't
absolutely clear to me what an internal node is, so I wonder whether
this would be more clear as  "internal (i.e. non root) node".

Agreed, but probably with a hyphen: "non-root"?

OK.




2. Sec 1. Introduction, page 4, paragraph starting "2.
Implementation-time ...".  This section states that it is a stable as
YANG library, and hence cannot change due to a server reboot. However,
YANG library doesn't appear to have that restriction, and hence this
doesn't seem to align with RFC 7895, introduction paragraph 2.

I don't know exactly under what circumstances YANG library can change
after a reboot, but in such a case schema-mounts data might be subject
to a change as well. I definitely think that the "run-time" case is
something else.
A software upgrade could quite reasonably change YANG library without a 
device reboot.  Perhaps saying less is more precise:


E.g.

   2.  Implementation-time: the mounted schema is defined by a server
   implementor and is as stable as YANG library information. Also,
   a client can learn the entire schema together with YANG library data.


Or alternatively, you say that it is at least as stable as the YANG 
library information, and then list when it could change.






3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined
anywhere (RFC 7950 doesn't define this).  Should it be defined here?
The NMDA datastores draft had a similar issue and we choose to define
"datastore schema" instead.

I think the right place for defining the term "schema" (and "data model"
as well) is the specification of YANG because it is desirable that all
documents related to YANG use the same meaning.

OK, 7950 doesn't define it today.  Is that a problem?




4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.
The text "same management session" might be more clear as "same client
management protocol session".

Hmm, I wouldn't say this is more clear - it seems to indicate that we
are managing the client.
My issue is that "same management session" isn't really that clear to 
what it is referring to.  Perhaps drop the "client" and have "same 
management protocol session"?





But it could also be that such rules are inappropriate in this document and
rather belong to a protocol spec.
I think that they are OK here if this draft defines the lifetime of the 
schema.  If it is just the same as YANG library, then perhaps this could 
be left to the YANG library spec to specify?





5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" =>
"are possible, and as such, needs"

I actually don't understand neither this sentence nor what the point of
such exceptions could possibly be.
An example would presumably be where effectively the same data is being 
mounted in a separate place.  E.g. the list of physical interfaces in an 
LNE may represent a subset of all physical interfaces in the device, 
that would also be present in the host model.



6. Sec 3.2 paragraph 5.  Would it useful to state that even though the
schema is the same, the data is different and not necessarily related.

I think this goes without saying, as it is also the case for a single mount
point that is a list node - data in each entry is different.
In Sec 3.2 paragraph 2, it clarifies that the mounted data is generally 
separate from the parent data.  For paragraph 5, I still that it is 
useful to state the equivalent that if a schema is mounted twice it 
doesn't mean the same data is mounted in both places.






7. Sec 3.3 last paragraph.  "On the other hand, " => "In addition, "

Yes.


8.  Sec 6 Implementation Notes.  Would this section be better named
"Implementation Considerations"?

Agreed.


9. Structure of ietf-yang-schema-mount module:
    - Should "uri" under namespace be marked as "mandatory" so that it
doesn't appear to be optional in the tree diagram.

Yes, this is an omission.


    - Should the "module" name be included under the namespace.  It seems
that lots of other "module bindings" are done via the module name rather
than the namespace?

We need it exclusively for XPath, so it seems natural to stay close to XML
namespaces.
I was suggesting that it might be useful to add "module" in addition to 
namespace.





10. Example A.3.  This contains some features that are enabled. Possibly
it would be useful in the description to point this out, and state that
unless the features are listed they wouldn't be enabled.

Yes, we reuse the groupings from ietf-yang-library, and the idea is to
apply the same semantics. And as you are saying below, it would be more

Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

[Ladislav Lhotka]

Hi Rob,

thank you for the review, my replies are inline.

Robert Wilton  writes:

> Hi,
>
> I have read this document and think that is almost ready for publication.
>
> I have one general comment regarding the YANG module library (at the 
> end), and a few nits, but otherwise the draft looks good.
>
> 1. Sec 1. Introduction paragraph 2, "internal node".  It wasn't 
> absolutely clear to me what an internal node is, so I wonder whether 
> this would be more clear as  "internal (i.e. non root) node".

Agreed, but probably with a hyphen: "non-root"?

>
> 2. Sec 1. Introduction, page 4, paragraph starting "2. 
> Implementation-time ...".  This section states that it is a stable as 
> YANG library, and hence cannot change due to a server reboot. However, 
> YANG library doesn't appear to have that restriction, and hence this 
> doesn't seem to align with RFC 7895, introduction paragraph 2.

I don't know exactly under what circumstances YANG library can change
after a reboot, but in such a case schema-mounts data might be subject
to a change as well. I definitely think that the "run-time" case is
something else.

>
> 3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined 
> anywhere (RFC 7950 doesn't define this).  Should it be defined here?  
> The NMDA datastores draft had a similar issue and we choose to define 
> "datastore schema" instead.

I think the right place for defining the term "schema" (and "data model"
as well) is the specification of YANG because it is desirable that all
documents related to YANG use the same meaning.

>
> 4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.  
> The text "same management session" might be more clear as "same client 
> management protocol session".

Hmm, I wouldn't say this is more clear - it seems to indicate that we
are managing the client.

But it could also be that such rules are inappropriate in this document and
rather belong to a protocol spec.

>
> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" => 
> "are possible, and as such, needs"

I actually don't understand neither this sentence nor what the point of
such exceptions could possibly be.

>
> 6. Sec 3.2 paragraph 5.  Would it useful to state that even though the 
> schema is the same, the data is different and not necessarily related.

I think this goes without saying, as it is also the case for a single mount
point that is a list node - data in each entry is different.

>
> 7. Sec 3.3 last paragraph.  "On the other hand, " => "In addition, "

Yes.

>
> 8.  Sec 6 Implementation Notes.  Would this section be better named 
> "Implementation Considerations"?

Agreed.

>
> 9. Structure of ietf-yang-schema-mount module:
>    - Should "uri" under namespace be marked as "mandatory" so that it 
> doesn't appear to be optional in the tree diagram.

Yes, this is an omission.

>    - Should the "module" name be included under the namespace.  It seems 
> that lots of other "module bindings" are done via the module name rather 
> than the namespace?

We need it exclusively for XPath, so it seems natural to stay close to XML
namespaces.

>
> 10. Example A.3.  This contains some features that are enabled. Possibly 
> it would be useful in the description to point this out, and state that 
> unless the features are listed they wouldn't be enabled.

Yes, we reuse the groupings from ietf-yang-library, and the idea is to
apply the same semantics. And as you are saying below, it would be more
straightforward to integrate it directly with YANG library. 

>
> My last general comment relates generally to the structure of the 
> Iietf-yang-schema-mount.  As Lada has pointed out previously, this 
> module and YANG library bis could be more closely aligned (e.g. along 
> the lines of reusing module-sets for the "schema" list).  It would have 
> been nice if this module could augment YANG library (so that you can 
> easily get the modules and schema mount information in a single simple 
> request), however that would put an undesired dependency delaying 
> publishing this draft until YANG library bis is completed.

Of course I agree, but I think the priority should be to make things as
simple and easy to understand as possible. They are complex enough
anyway.

Thanks, Lada

>
> Thanks,
> Rob
>
>
> On 20/10/2017 22:37, Kent Watsen wrote:
>> All,
>>
>> This starts a two-week working group last call on
>> draft-ietf-netmod-schema-mount-07.
>>
>> The working group last call ends on November 3.
>> 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.
>>
>> Could the authors, explicitly CC-ed on this email,
>> please also confirm one more time that they are
>> unaware of any IPR related to this draft.
>>
>> Thank you,
>> Netmod Chairs
>>
>>
>> ___
>> 

Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

[t.petch]

Yuanglong

I think that your Introduction is fine, and would not shorten it at all.
(I think that the Introduction to most I-Ds that describe YANG modules
is woefully weak).

I think too that you are spot on with your terminology; where IEEE
1588-2008 has an accepted way of working, then that is the right way for
this I-D.

One fresh comment arising from that.  You commented earlier that you had
departed from IEEE 1588-2008 in changing camel case to the YANG style
names, with hyphens, and I think that that is a logical choice.  But I
would go further and explain that choice so that those coming from IEEE
1588-2008 understand what has happened and why.  Not sure where to put
that; probably Section 2, perhaps immediately before the tree diagram,
since that is when readers will be exposed to the issue.

If you have done more than just change the style of name, then it would
be worth having a concordance of IEEE 1588-2008 names and YANG names;
this was common practice with MIB Modules.

Tom Petch

- Original Message -
From: "Jiangyuanlong" 
To: "Alex Campbell" ; 
Cc: "Xian Liu" ; "Xujinchun"
; 
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: [netmod] WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


> Hi Alex,
>
> Sorry for a late reply as I spent the last week for an urgent business
trip.
> Please see my comments in line with [YJ]
>
> Thanks,
> Yuanlong
>
> -Original Message-
> From: Alex Campbell [mailto:alex.campb...@aviatnet.com]
> Sent: Monday, October 30, 2017 10:15 AM
> To: Jiangyuanlong; tic...@ietf.org
> Cc: Xian Liu; Xujinchun; netmod@ietf.org
> Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
>
> Hi,
> I've reviewed this latest draft and have some more comments.
>
> 1. I find the introduction to be unnecessarily wordy; it feels like it
was written with a view of not missing any information out, rather than
trying to keep it concise.
>For example, there is no need to elaborate on YANG data types here.
It is also not here to sell YANG.
>
> [YJ] Yes, we are trying to give some introductory information for an
outsider who may not be familiar with PTP or YANG, and explain why a
YANG for PTP is needed. The juicy part of this document is its YANG
module, and people can skip all the other texts if they are familiar
with PTP and YANG.
> Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear
message from the TICTOC chairs to introduce any big changes at this last
call stage.
>
>
> OLD:
>
>As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
>supported in the carrier networks, industrial networks, automotive
>networks, and many other applications. It can provide high
>precision time synchronization as fine as nano-seconds. The
>protocol depends on a Precision Time Protocol (PTP) engine to
>decide its own state automatically, and a PTP transportation layer
>to carry the PTP timing and various quality messages. The
>configuration parameters and state data sets of IEEE 1588-2008 are
>numerous.
>
>According to the concepts described in [RFC3444], IEEE 1588-2008
>itself provides an information model in its normative
>specifications for the data sets (in IEEE 1588-2008 clause 8). Some
>standardization organizations including the IETF have specified
>data models in MIBs (Management Information Bases) for IEEE 1588-
>2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
>typically focused on retrieval of state data using the Simple
>Network Management Protocol (SNMP), furthermore, configuration of
>PTP data sets is not considered in [RFC8173].
>
>Some service providers and applications require that the management
>of the IEEE 1588-2008 synchronization network be flexible and more
>Internet-based (typically overlaid on their transport networks).
>Software Defined Network (SDN) is another driving factor, which
>demands an improved configuration capability of synchronization
>networks.
>
>YANG [RFC6020] is a data modeling language used to model
>configuration and state data manipulated by network management
>protocols like the Network Configuration Protocol (NETCONF)
>[RFC6241]. A small set of built-in data types are defined in
>[RFC6020], and a collection of common data types are further
>defined in [RFC6991]. Advantages of YANG include Internet based
>configuration capability, validation, rollback and so on. All of
>these characteristics make it attractive to become another
>candidate modeling language for IEEE 1588-2008.
>
> NEW:
>
>IEEE 1588-2008 is a time protocol that provides high precision time
>synchronization as fine as nano-seconds.
>
>IEEE 

Re: [netmod] review of draft-ietf-netmod-schema-mount-08

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Wed, 2017-11-08 at 09:50 +0100, Martin Bjorklund wrote:
> > Kent Watsen  wrote:
> > > 
> > > 
> > > > Hi Kent,
> > > >
> > > > thanks for the thorough review, see my responses inline.
> > > 
> > > Hi Lada, please see below.
> > > 
> > > 
> > > >> 1. From Section 4:
> > > >>
> > > >>Routing configuration inside an NI often needs to refer to 
> > > >> interfaces (at
> > > >>least those that are assigned to the NI), which is impossible 
> > > >> unless such
> > > >>a reference can point to a node in the parent schema (interface 
> > > >> name).
> > > >>
> > > >> This seems overstated.  Rather it is a result of an earlier design 
> > > >> decision.
> > > >> An alternate solution might have exported the global interfaces into a 
> > > >> config false list inside the mount jail.   Was such a solution
> > > >> discussed?
> > 
> > Actually, this wouldn't work, since config true leafrefs/xpaths can't
> > refer to this "config false" list inside the mount jail.
> > 
> > Besides, even a symlink approach would in fact allow for "such a
> > reference to point to a node in the parent schema tree".
> > 
> > > > Do you mean something like having "symlinks" to interfaces inside the
> > > > mount jail? Yes, this was discussed and rejected. According to Martin,
> > > > tail-f had made a very bad experience with this approach.
> > > 
> > > Yes, a little bit like a symlink inside the mount jail.  Good to hear
> > > that it was discussed.  I still think the above "impossible" word is
> > > overstating things.  Perhaps s/impossible such/possible when/?
> > 
> > See above; I think the current text is correct.
> > 
> > The point is that *somehow* the solution needs to allow for these
> > kinds of references; symlinks could be one solution, the
> > "parent-reference" that we use is another solution.
> 
> I agree, and also we don't want to make such nodes protocol-accessible in the
> mounted tree.
> 
> > 
> > > >> 3. Also from Section 4 (same paragraph):
> > > >>
> > > >>For the purposes of
> > > >>evaluating XPath expressions within the mounted data tree, the union
> > > >>of all such nodesets is added to the accessible data tree.
> > > >>
> > > >> Could this ever result in name collision?
> > > >
> > > > Potentially yes, but sibling nodes with the same name are not an issue
> > > > for XPath evaluation. 
> > > 
> > > I don't know if I agree that it can't be an issue.  What if the module
> > > has a top-level /widgets container, and there is a parent-reference to
> > > a /widgets container
> > 
> > The nodes exist in a namespace.  So if you have /widgets in two
> > different modules there is no issue.  However, if you mount a module A
> > and at the same time provide A's toplevel nodes as parent references
> > then you might have a problem - or not!  The document defines what
> > happens in this case (the result is the union).   Also note that
> > constructing the set of mounted modules and corresponding
> > parent-references is up to the implementation.
> 
> This is fine with must expressions but actually leafrefs are defined so that 
> the
> leaf instance being referred to has to be unique.

I'm not sure what you refer to, but in general a leafref can refer to
more than one node:

   The "path" expression evaluates to a node set consisting of zero,
   one, or more nodes.  If the "require-instance" property is "true",
   this node set MUST be non-empty.


> This needn't be the case here
> - I don't know if it matters.
> 
> > 
> > > >> Also, should how NACM interacts with mounted instance data be
> > > >> specified?
> > > >
> > > > This is a good question because, in principle, top-level NACM rules
> > > > can address instances of mounted schemas. On the other hand,
> > > > ietf-netconf-acm can also be a part of the mounted schema - and if
> > > > so, can its rules also address instances in the parent schema via
> > > > the parent-reference mechanism?
> > > >
> > > > But I would say it is up to rfc6536bis to deal with these questions.
> > > 
> > > I don't know, but it seems that this draft is introducing the concept.
> > > Not to mention, rfc6536bis is already with the IESG.  In either case,
> > > let's work out what it means and then decide which draft it needs to
> > > go into.
> > 
> > I think NACM in the parent node should cover access to the mounted
> > data.  For example, it should be possible to have a rule for:
> > 
> >  /network-instances/network-instance[name='foo']/vrf-root/rt:routing
> 
> Do you mean that NACM can only be used at the top level? What if it is also 
> part
> of the mounted schema?

I don't think that we can/should require that a server that mounts
nacm has to enforce the nacm rules in the mount jail.

One reason for mounting nacm would be "peer mount" where you mount all
models some other device supports.  In this case that other device
will of course enfore the nacm rules, but in the parent node these
nacm rules 

Re: [netmod] review of draft-ietf-netmod-schema-mount-08

[Ladislav Lhotka]

On Wed, 2017-11-08 at 09:50 +0100, Martin Bjorklund wrote:
> Kent Watsen  wrote:
> > 
> > 
> > > Hi Kent,
> > >
> > > thanks for the thorough review, see my responses inline.
> > 
> > Hi Lada, please see below.
> > 
> > 
> > >> 1. From Section 4:
> > >>
> > >>Routing configuration inside an NI often needs to refer to interfaces 
> > >> (at
> > >>least those that are assigned to the NI), which is impossible unless 
> > >> such
> > >>a reference can point to a node in the parent schema (interface name).
> > >>
> > >> This seems overstated.  Rather it is a result of an earlier design 
> > >> decision.
> > >> An alternate solution might have exported the global interfaces into a 
> > >> config false list inside the mount jail.   Was such a solution
> > >> discussed?
> 
> Actually, this wouldn't work, since config true leafrefs/xpaths can't
> refer to this "config false" list inside the mount jail.
> 
> Besides, even a symlink approach would in fact allow for "such a
> reference to point to a node in the parent schema tree".
> 
> > > Do you mean something like having "symlinks" to interfaces inside the
> > > mount jail? Yes, this was discussed and rejected. According to Martin,
> > > tail-f had made a very bad experience with this approach.
> > 
> > Yes, a little bit like a symlink inside the mount jail.  Good to hear
> > that it was discussed.  I still think the above "impossible" word is
> > overstating things.  Perhaps s/impossible such/possible when/?
> 
> See above; I think the current text is correct.
> 
> The point is that *somehow* the solution needs to allow for these
> kinds of references; symlinks could be one solution, the
> "parent-reference" that we use is another solution.

I agree, and also we don't want to make such nodes protocol-accessible in the
mounted tree.

> 
> > >> 3. Also from Section 4 (same paragraph):
> > >>
> > >>For the purposes of
> > >>evaluating XPath expressions within the mounted data tree, the union
> > >>of all such nodesets is added to the accessible data tree.
> > >>
> > >> Could this ever result in name collision?
> > >
> > > Potentially yes, but sibling nodes with the same name are not an issue
> > > for XPath evaluation. 
> > 
> > I don't know if I agree that it can't be an issue.  What if the module
> > has a top-level /widgets container, and there is a parent-reference to
> > a /widgets container
> 
> The nodes exist in a namespace.  So if you have /widgets in two
> different modules there is no issue.  However, if you mount a module A
> and at the same time provide A's toplevel nodes as parent references
> then you might have a problem - or not!  The document defines what
> happens in this case (the result is the union).   Also note that
> constructing the set of mounted modules and corresponding
> parent-references is up to the implementation.

This is fine with must expressions but actually leafrefs are defined so that the
leaf instance being referred to has to be unique. This needn't be the case here
- I don't know if it matters.

> 
> > >> Also, should how NACM interacts with mounted instance data be
> > >> specified?
> > >
> > > This is a good question because, in principle, top-level NACM rules
> > > can address instances of mounted schemas. On the other hand,
> > > ietf-netconf-acm can also be a part of the mounted schema - and if
> > > so, can its rules also address instances in the parent schema via
> > > the parent-reference mechanism?
> > >
> > > But I would say it is up to rfc6536bis to deal with these questions.
> > 
> > I don't know, but it seems that this draft is introducing the concept.
> > Not to mention, rfc6536bis is already with the IESG.  In either case,
> > let's work out what it means and then decide which draft it needs to
> > go into.
> 
> I think NACM in the parent node should cover access to the mounted
> data.  For example, it should be possible to have a rule for:
> 
>  /network-instances/network-instance[name='foo']/vrf-root/rt:routing

Do you mean that NACM can only be used at the top level? What if it is also part
of the mounted schema?

> 
> 
> > >> 5. This document does not say anything about how it relates to NMDA.
> > >> Clearly all this is targeted to the conventional datastores
> 
> No, or maybe I don't understand what you mean.  Schema mount allows
> for mounting config false nodes, or even doing a "read-only" mount.
> Such a mount is clearly not available in the conventional datastores.
> 
> >, but how
> > >> is it reflected in e.g., ?  Does anything need to be said
> > >> here?
> > >
> > > The "use-schema" case shouldn't pose big problems because it is
> > > essentially an externally specified augment. The "inline" case is
> > > somewhat disturbing though: could the embedded YANG library instances
> > > be different in different datastores?
> > 
> > YANG Library is only available in  (it's all config false).

OK, so if I have a mount point of the "inline" type in  or ,
I have to 

Re: [netmod] review of draft-ietf-netmod-schema-mount-08

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> 
> > Hi Kent,
> >
> > thanks for the thorough review, see my responses inline.
> 
> Hi Lada, please see below.
> 
> 
> >> 1. From Section 4:
> >>
> >>Routing configuration inside an NI often needs to refer to interfaces 
> >> (at
> >>least those that are assigned to the NI), which is impossible unless 
> >> such
> >>a reference can point to a node in the parent schema (interface name).
> >>
> >> This seems overstated.  Rather it is a result of an earlier design 
> >> decision.
> >> An alternate solution might have exported the global interfaces into a 
> >> config false list inside the mount jail.   Was such a solution
> >> discussed?

Actually, this wouldn't work, since config true leafrefs/xpaths can't
refer to this "config false" list inside the mount jail.

Besides, even a symlink approach would in fact allow for "such a
reference to point to a node in the parent schema tree".

> > Do you mean something like having "symlinks" to interfaces inside the
> > mount jail? Yes, this was discussed and rejected. According to Martin,
> > tail-f had made a very bad experience with this approach.
> 
> Yes, a little bit like a symlink inside the mount jail.  Good to hear
> that it was discussed.  I still think the above "impossible" word is
> overstating things.  Perhaps s/impossible such/possible when/?

See above; I think the current text is correct.

The point is that *somehow* the solution needs to allow for these
kinds of references; symlinks could be one solution, the
"parent-reference" that we use is another solution.

> >> 3. Also from Section 4 (same paragraph):
> >>
> >>For the purposes of
> >>evaluating XPath expressions within the mounted data tree, the union
> >>of all such nodesets is added to the accessible data tree.
> >>
> >> Could this ever result in name collision?
> >
> > Potentially yes, but sibling nodes with the same name are not an issue
> > for XPath evaluation. 
> 
> I don't know if I agree that it can't be an issue.  What if the module
> has a top-level /widgets container, and there is a parent-reference to
> a /widgets container

The nodes exist in a namespace.  So if you have /widgets in two
different modules there is no issue.  However, if you mount a module A
and at the same time provide A's toplevel nodes as parent references
then you might have a problem - or not!  The document defines what
happens in this case (the result is the union).   Also note that
constructing the set of mounted modules and corresponding
parent-references is up to the implementation.

> >> Also, should how NACM interacts with mounted instance data be
> >> specified?
> >
> > This is a good question because, in principle, top-level NACM rules
> > can address instances of mounted schemas. On the other hand,
> > ietf-netconf-acm can also be a part of the mounted schema - and if
> > so, can its rules also address instances in the parent schema via
> > the parent-reference mechanism?
> >
> > But I would say it is up to rfc6536bis to deal with these questions.
> 
> I don't know, but it seems that this draft is introducing the concept.
> Not to mention, rfc6536bis is already with the IESG.  In either case,
> let's work out what it means and then decide which draft it needs to
> go into.

I think NACM in the parent node should cover access to the mounted
data.  For example, it should be possible to have a rule for:

 /network-instances/network-instance[name='foo']/vrf-root/rt:routing


> >> 5. This document does not say anything about how it relates to NMDA.
> >> Clearly all this is targeted to the conventional datastores

No, or maybe I don't understand what you mean.  Schema mount allows
for mounting config false nodes, or even doing a "read-only" mount.
Such a mount is clearly not available in the conventional datastores.

>, but how
> >> is it reflected in e.g., ?  Does anything need to be said
> >> here?
> >
> > The "use-schema" case shouldn't pose big problems because it is
> > essentially an externally specified augment. The "inline" case is
> > somewhat disturbing though: could the embedded YANG library instances
> > be different in different datastores?
> 
> YANG Library is only available in  (it's all config false).
> I think you mean the embedded YANG Library instances under the mount 
> points.  Yes, you may have a problem here.  Still, this isn't my question,
> is more about schema-mounting requirements across datastores.  E.g., if
> a schema-mount exists in , must it existing in  and
>  as well?  Conversely, if a schema-mount exists in
> , must it exist in ?  I think this draft should
> clarify such things.

I agree that this needs to be clarified.  This issue partly comes from
the fact that schema mount uses the groupings in the old yang
library.  I think we need to use the new groupings from rfc7895bis.


> >> What if the mounted schema has deviations in .
> >
> > I don't understand why this could be an issue.
> 
> I'm not saying 

Re: [netmod] draft agenda posted

[wangzitao]

Presenters, 

Please prepare to send your slides to me and CC the chairs. The deadline for 
slides is 24 hours prior to the session (note we are on WEDNESDAY, November 15, 
2017) , though earlier is better. 

And please take a look at the list for presenting at Netmod: 
https://datatracker.ietf.org/meeting/100/materials/agenda-100-netmod/

Best regards!
-Michael

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
发送时间: 2017年11月2日 6:19
收件人: netmod@ietf.org
主题: [netmod] draft agenda posted


The draft agenda for the NETMOD sessions has been posted:

  https://datatracker.ietf.org/meeting/100/materials/agenda-100-netmod/

There are no sessions listed for the three NMDA-update model drafts 
(rfc7223bis, rfc7277bis, rfc8022bis).  They will be covered together by the 
chairs in the beginning of Session 1.

Cheers,
Kent (and Lou)



___
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