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

[Kristian Larsson]

On Sat, Nov 04, 2017 at 10:38:45AM -0700, Sonal Agarwal wrote:
> Kristian,
> 
> In response to one of your previous comments:
> 
> "I'm really bothered by the compound key consisting of acl-type
> and the acl-name since attachment points then need to reference
> both.  It's also weird because I don't think choosing the
> acl-type is really a choice of the user but more of a limitation
> of the platform.
> 
> One approach would be to change the key to only be the acl-name
> but let the acl-type leaf remain, perhaps make it mandatory or
> default to some unified acl-type. I think it's still possible to
> implement a constraint on this, right? Like if a platform only
> supports a specific type at some attachment point it can add a
> constraint on the acl-type by doing deref() on the leafref."
> 
> The key for an ACL needs to remain as the name and type. They
> both uniquely define the presence of the ACL in config. 

You can't argue for a design choice by saying "this is how it
is". If we change the key to be acl-name only then it is the name
that "uniquely define the presence of the ACL in config".

What do you perceive as the benefit of having acl-type in the
key? Why can't it be an attribute? We can still check, from the
attachment point, what the acl-type is.

   kll

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

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

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

[Kent Watsen]

> 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?
>
> 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/?


>> 2. Also from Section 4:
>>
>>For every schema mounted using the "use-schema" method, it is possible 
>>to specify a leaf-list named "parent-reference" that contains zero or more
>>XPath 1.0 expressions.  Each expression is evaluated with the node in the
>>parent data tree where the mount point is defined as the context node.  
>>
>> If you can nested-mounts, can you also have nested parent-references?
>
> Yes, but you can only refer to the level directly above.

Okay.



>> 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, and there is an Xpath to /widgets - seems like
you could have both false-positives and false-negatives...




>> 4. Regarding Security Considerations, what about
>> /yangmnt:schema-mounts?
>
> You are right, the security considerations should be similar
> to those in RFC 7895. It is the same type of risk.

ok


>> 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.



>> 5. This document does not say anything about how it relates to NMDA.
>> Clearly all this is targeted to 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.



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

I'm not saying it's a problem yet.  I'm just stating that such things
can occur and it's unclear that, if they do, could it cause problems.
For instance, a mounted schema may be looking for a parent reference
that doesn't exist because of a deviation.




>> Nits (line-break separated):
>>
>> Is "other optional choices" being vague on purpose?  Should it just
>> call out features and deviations?
>
>Yes, it should.
>
>>
>> "the YANG library data" seems odd.  Maybe "the instance of the YANG
>> Library module"?
>
> It is the same but I prefer the former. Note that the term "instance"
> is not defined in RFC 7950.

okay


>> - document, and could be possibly dealt with in a future revision of the 
>> YANG data modeling language
>> + document, as it needs to be dealt with as an update to the YANG data 
>> modeling language
>
> I am not sure that it *needs* to be done, because it could have
> far-reaching consequences.

Here I'm using "needs" 

Re: [netmod] review of draft-acee-netmod-rfc8022bis-05

[Ladislav Lhotka]

Vladimir Vassilev  writes:

> Hello,
>
> I have reviewed draft-acee-netmod-rfc8022bis-05. My conclusion is that 
> the YANG modules part of the draft have been successfully modified in 
> accordance with sec. '4.23.3 NMDA Transition Guidelines' of 
> draft-ietf-netmod-rfc6087bis-14. The modifications are coherent with the 
> ietf-interfa...@2017-08-17.yang module in 
> draft-ietf-netmod-rfc7277bis-00 and ietf...@2017-08-21.yang module in 
> draft-ietf-netmod-rfc7277bis-00.
>
> Vladimir
>
>
> Review of draft-acee-netmod-rfc8022bis-05.
> Vladimir Vassilev
> 2017-10-30
>
> 'Abstract':
> 'Introduction 1':
>   - Both Abstract and Sec 1. contain duplicated text which can be removed
> from Abstract. The text in Sec 1. can be simplified:
>
> OLD:
> This version of these YANG modules uses new names for these YANG
> models.  The main difference from the first version is that this
> version fully conforms to the Network Management Datastore
> Architecture (NMDA).  Consequently, this document obsoletes RFC 8022.
> NEW:
> This version of the Routing Management data model supports the Network
> Management Datastore Architecture (NMDA) 
> [I-D.ietf-netmod-revised-datastores].
>
>
> '7.  Routing Management YANG Module':
>
>   - Why should address-family identity be different e.g. mandatory 
> "false"; for system created RIBs? I think this needs some explanation 
> (Page 21):
> ...
> uses address-family {
>   description
> "Address family of the RIB.
>
>  It is mandatory for user-controlled RIBs.  For
>  system-controlled RIBs it can be omitted; otherwise, it
>  must match the address family of the corresponding state
>  entry.";
>   refine "address-family" {
> mandatory "false";
>   }
> }
> ...
>

Following the logic of RFC 8022, address-family has to be a mandatory
parameter for all RIB entries in , so there seems to be no
other choice than make it "mandatory true" in the schema, as NMDA only
has one schema for all datastores.

Lada

>   - Suggested change of 'base address-family;' -> 'base 
> rt:address-family;' for identity ipv4 and ipv6 (ref. 
> draft-ietf-netmod-rfc6087bis-14#section-4.2):
>
>  o The local module prefix MUST be used instead of no prefix in
>  all "default" statements for an "identityref" or "instance-identifier"
>  data type
>
> '8.  IPv4 Unicast Routing Management YANG Module' 
> (ietf-ipv4-unicast-rout...@2017-10-14.yang):
> '9.  IPv6 Unicast Routing Management YANG Module' 
> (ietf-ipv6-unicast-rout...@2017-10-14.yang):
>
>
>   - The ietf-ipv4-unicast-routing and ietf-ipv6-unicast-routing modules 
> import the ietf-routing without revision (ref. rfc6087#section-4.6):
>
>
>  o The revision-date substatement within the imports statement SHOULD be
>  present if any groupings are used from the external module."
>
>
> 'Appendix D. Data Tree Example':
>
>   - The example in the Appendix D. has not been updated and it must be 
> extended in order to demonstrate a usecase of operational datastore of 
> configuration data with different origin (intended, system, etc.) 
> similar to the 'Appendix C. Example Data' of 
> draft-ietf-netmod-revised-datastores-05.
>
>
> Nits:
>   - s/Figures 1/Figure 1/
>   - s/systemindependently/system independently/
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] 答复: (no subject)

[Martin Bjorklund]

Zhuzhiguo  wrote:
> Hi Martin,
> Thank you for your reply.
> 
> If module-A and modul-B are 1.0 modules, are they should be presented
> in ?

Yes, but note that if B is present in , a client will think
that all nodes in B are implemented.  This is why yang-library has the
'conformance' leaf.


/martin

> -邮件原件-
> 发件人: Martin Bjorklund [mailto:m...@tail-f.com] 
> 发送时间: 2017年11月7日 20:08
> 收件人: Zhuzhiguo 
> 抄送: netmod@ietf.org; Liquan (Liquan, NOS CSD) 
> 主题: Re: [netmod] (no subject)
> 
> Zhuzhiguo  wrote:
> > Hi,
> > 
> > I have one question about how to implement YANG module that import 
> > other-module which is NOT be implemented?
> > 
> > For example, module-A import module-B, but any nodes that depend on B 
> > are not-supported
> > 
> > Module A {
> >import module-B;
> > }
> > 
> > There are two way to mark module-B is not really in use:
> > 
> > Option-1: refer conformance-type in RFC 7895 (ietf-yang-library), mark
> > module-A as "implement", module-B is "import"
> 
> This is correct.  But if A augments some node in B, you have to
> implement B as well.
> -all these augments are deviated
> 
> > This way seems work, but some teammates think it may not comply with 
> > RFC.
> 
> Why wouldn't it?
> --client can get module-B, but can't do any operation on module-B
> 
> > And we also argue about what module-B should be presented in 
> > 
> > 
> >module-A
> >module-B ===>should any "import" module MUST
> >be sent by server to client also?
> > 
> 
> Assuming A and B are YANG 1.1 modules, they should NOT be listed in
>  - yang-library is used instead.
> > Option-2: mark module-B as "implement" also, but mark all-nodes as 
> > deviated This way seems work also, but it will cause NETCONF-client 
> > and NETCONF-server load module that have NO node that can be accessed
> 
> There's no reason to do this.
> 
> 
> 
> /martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] 答复: (no subject)

[Zhuzhiguo]

Hi Martin,
Thank you for your reply.

If module-A and modul-B are 1.0 modules, are they should be presented in 
?


-邮件原件-
发件人: Martin Bjorklund [mailto:m...@tail-f.com] 
发送时间: 2017年11月7日 20:08
收件人: Zhuzhiguo 
抄送: netmod@ietf.org; Liquan (Liquan, NOS CSD) 
主题: Re: [netmod] (no subject)

Zhuzhiguo  wrote:
> Hi,
> 
> I have one question about how to implement YANG module that import 
> other-module which is NOT be implemented?
> 
> For example, module-A import module-B, but any nodes that depend on B 
> are not-supported
> 
> Module A {
>import module-B;
> }
> 
> There are two way to mark module-B is not really in use:
> 
> Option-1: refer conformance-type in RFC 7895 (ietf-yang-library), mark 
> module-A as "implement", module-B is "import"

This is correct.  But if A augments some node in B, you have to implement B as 
well.
-all these augments are deviated

> This way seems work, but some teammates think it may not comply with 
> RFC.

Why wouldn't it?
--client can get module-B, but can't do any operation on module-B

> And we also argue about what module-B should be presented in 
> 
> 
>module-A
>module-B ===>should any "import" module MUST
>be sent by server to client also?
> 

Assuming A and B are YANG 1.1 modules, they should NOT be listed in  - 
yang-library is used instead.
> Option-2: mark module-B as "implement" also, but mark all-nodes as 
> deviated This way seems work also, but it will cause NETCONF-client 
> and NETCONF-server load module that have NO node that can be accessed

There's no reason to do this.



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

Re: [netmod] Action and RPC statements

[t.petch]

 Original Message -
From: "Juergen Schoenwaelder" 
To: "Martin Bjorklund" 
Cc: 
Sent: Monday, November 06, 2017 2:01 PM
> On Mon, Nov 06, 2017 at 02:19:24PM +0100, Martin Bjorklund wrote:
> >
> > Trying to summarize this issue.
> >
> > The problem is which datastore is used to:
> >
> > 1a. evaluate action ancestor nodes
> > 1b. evaluate action input/output parameter leafref,
> > instance-identifier, must, when
> > 2.  evaluate rpc input/output parameter leafref,
> > instance-identifier, must, when
> >
> > (Note that the side effects of an action/rpc is not part of this
> > issue)
> >
> > I think it would be very weird if 1a and 1b were treated
differently,
> > so I just label them as 1 below.
> >
> > Possible solutions:
> >
> > A.  Always use  for 1 and 2.
> >
> > (This is what the current nmda draft says).
> >
> > B.  Let the client specify the datastore for 1, and use

> > for 2.
> >
> > (Note that this is trivial in RESTCONF (since the datastore is
> > part of the URL), but would require a new parameter for NETCONF
> > (or a new ).
> >
> > C.  Let the client specify the datastore for 1 and 2.
> >
> > This would require a new generic parameter for how RPCs are
> > invoked in both NETCONF and RESTCONF.
> >
> > D.  Like B, but let the description of the "rpc" statement
optionally
> > override this.
> >
> >
> > I prefer B and then D.
>
> I prefer A for now and I believe any of the other options may be
> considered in the future (when we can provide proper support of YANG
> and the protocols). I also believe that A covers a large number of
> real-world use cases.

I prefer A.  I think it is the simplest and the one least likely to have
consequences that were not anticipated.  You could see this discussion
as being one of unanticipated consequences so I want the least change to
solve the problem, while thinking about what B (or C or D, roughly the
order of increasing uncertainty) really involves.

Tom Petch

> /js
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

[Eliot Lear]

Kent,

Can you or the chairs please summarize what issues need to be
addressed?  We are in a place where we end up in endless last calls, and
that is bad.

Eliot


On 11/7/17 12:46 AM, 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.
>
> Thanks,
> Kent // shepherd
>
>
> --
>
> All,
>
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-14.
>
> 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 at this time that they are unaware of any 
> IPR related to this draft.
>
> Thank you,
> Netmod Chairs
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HCp9pNO1eASC7fBxrsD4hOUjTXHbKMuWC5C2h7-ym68&s=k7uRdiuP0Z8vvDa1hOLxdQJQt3MBpHv8gcuHg9hy-Lw&e=
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] (no subject)

[Martin Bjorklund]

Zhuzhiguo  wrote:
> Hi,
> 
> I have one question about how to implement YANG module that import
> other-module which is NOT be implemented?
> 
> For example, module-A import module-B, but any nodes that depend on B
> are not-supported
> 
> Module A {
>import module-B;
> }
> 
> There are two way to mark module-B is not really in use:
> 
> Option-1: refer conformance-type in RFC 7895 (ietf-yang-library), mark
> module-A as "implement", module-B is "import"

This is correct.  But if A augments some node in B, you have to
implement B as well.

> This way seems work, but some teammates think it may not comply with
> RFC.

Why wouldn't it?

> And we also argue about what module-B should be presented in
> 
> 
> 
>module-A
>module-B ===>should any "import" module MUST
>be sent by server to client also?
> 

Assuming A and B are YANG 1.1 modules, they should NOT be listed in
 - yang-library is used instead.

> Option-2: mark module-B as "implement" also, but mark all-nodes as
> deviated
> This way seems work also, but it will cause NETCONF-client and
> NETCONF-server load module that have NO node that can be accessed

There's no reason to do this.



/martin

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

[netmod] (no subject)

[Zhuzhiguo]

Hi,

I have one question about how to implement YANG module that import other-module 
which is NOT be implemented?

For example, module-A import module-B, but any nodes that depend on B are 
not-supported

Module A {
   import module-B;
}

There are two way to mark module-B is not really in use:

Option-1: refer conformance-type in RFC 7895 (ietf-yang-library), mark module-A 
as "implement", module-B is "import"
This way seems work, but some teammates think it may not comply with RFC. And 
we also argue about what module-B should be presented in 


   module-A
   module-B===>should any "import" module 
MUST be sent by server to client also?


Option-2: mark module-B as "implement" also, but mark all-nodes as deviated
This way seems work also, but it will cause NETCONF-client and NETCONF-server 
load module that have NO node that can be accessed

Thanks.

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