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

[Eliot Lear]

Hi Kristian,


On 02.02.18 08:44, Kristian Larsson wrote:
> Mahesh,
>
> I've reviewed this model, I think I largely caused the last couple of
> updates to it late last year. Overall I think it is a good model.
> Placement of feature-statements could be debated - no clear answers.
> object groupings is something I would like to see in the model but it
> was always deferred.
>
>
> On 2018-01-22 16:50, Kent Watsen wrote:
>> Hi Mahesh,
>>
>> Thanks, it doesn't get much more concrete then a pull request  ;)
>>
>> Okay, so from a chair/shepherd perspective, can folks please consider
>> this update to -15 as the LC solution to removing the open issue
>> Juergen found in the draft?
>>
>> As a contributor, I don't think the name of the groupings or their
>> description statements should allude to something that doesn't exist
>> yet.  Rather than e.g. "source-or-group", could it be instead
>> something like "source-type"?
>
> +1
>
>> Also, the update seems to be for both when specifying networks as
>> well as when specifying port-ranges, but the original issue (see
>> below) only mentioned addresses - is the pull-request actually what's
>> needed and the description of the issue in Section 8 is incomplete?
>>
>>  8.  Open Issues
>>
>>     o  The current model does not support the concept of
>> "containers"
>>
>>      used to contain multiple addresses per rule entry.
>
> Object groupings are useful whenever there are many of something.
> There are usually more address entries than ports, so perhaps more
> useful for addresses, but it can still be useful to say "NFS-PORTS"
> and mean all the ports that NFS use (god knows what they are).
>
> Other have mentioned scale ACL and that it can be solved in other
> ways. To me, this sort of object-groupings is not about optimising
> things for the hardware but rather making it easy for me to write
> rules. I think it is paramount for security that ACLs can be easily
> read and understood. If we do not understand them, then we cannot say
> they are effective and secure. Object groupings greatly improves the
> readability of ACLs and thus makes it easier to write secure ACLs.
>
> I understand the authors wishes to get the first version out the door
> but I can't help but wonder if it isn't just easier to add in object
> groupings now. It's not that damn complicated (they are just lists).
> If not, I'm happy to work with them on the next version which could
> include object groupings.

Please let's aim for the next version.  This document just completed
what I think is its FIFTH last call, which to me is nothing short of insane.

Eliot

>
> As for the PR to add choices, there seems to be an extra container
> inserted. I also made a comment on GitHub.
> At the very least, I think it would be best if this PR is fixed and
> merged before we proceed.

>
>    kll
>
> ___
> 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] WG Last Call: draft-ietf-netmod-acl-model-15

[Kristian Larsson]

Mahesh,

I've reviewed this model, I think I largely caused the last couple of 
updates to it late last year. Overall I think it is a good model. 
Placement of feature-statements could be debated - no clear answers.
object groupings is something I would like to see in the model but it 
was always deferred.



On 2018-01-22 16:50, Kent Watsen wrote:

Hi Mahesh,

Thanks, it doesn't get much more concrete then a pull request  ;)

Okay, so from a chair/shepherd perspective, can folks please consider 
this update to -15 as the LC solution to removing the open issue Juergen 
found in the draft?


As a contributor, I don't think the name of the groupings or their 
description statements should allude to something that doesn't exist 
yet.  Rather than e.g. "source-or-group", could it be instead something 
like "source-type"?


+1

Also, the update seems to be for both when 
specifying networks as well as when specifying port-ranges, but the 
original issue (see below) only mentioned addresses - is the 
pull-request actually what's needed and the description of the issue in 
Section 8 is incomplete?


     8.  Open Issues

    o  The current model does not support the concept of "containers"

     used to contain multiple addresses per rule entry.


Object groupings are useful whenever there are many of something. There 
are usually more address entries than ports, so perhaps more useful for 
addresses, but it can still be useful to say "NFS-PORTS" and mean all 
the ports that NFS use (god knows what they are).


Other have mentioned scale ACL and that it can be solved in other ways. 
To me, this sort of object-groupings is not about optimising things for 
the hardware but rather making it easy for me to write rules. I think it 
is paramount for security that ACLs can be easily read and understood. 
If we do not understand them, then we cannot say they are effective and 
secure. Object groupings greatly improves the readability of ACLs and 
thus makes it easier to write secure ACLs.


I understand the authors wishes to get the first version out the door 
but I can't help but wonder if it isn't just easier to add in object 
groupings now. It's not that damn complicated (they are just lists).
If not, I'm happy to work with them on the next version which could 
include object groupings.


As for the PR to add choices, there seems to be an extra container 
inserted. I also made a comment on GitHub.
At the very least, I think it would be best if this PR is fixed and 
merged before we proceed.


   kll

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

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Andy Bierman]

On Thu, Feb 1, 2018 at 10:59 AM, Mahesh Jethanandani <
mjethanand...@gmail.com> wrote:

> WG,
>
> The authors of rfc7895bis have indicated that they believe the document is
> ready for LC[1].
>
> This starts a two week LC on the draft
> . The LC
> will end on February 15.
>
> Please send your comments on this thread. Reviews of the document, and
> statement of support are particularly helpful to the authors. If you have
> concerns about the document, please state those too.
>
> Authors please indicate if you are aware of any IPR on the document.
>
>
I am not aware of any IPR related to this document.



> Thanks.
>
> [1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>
> Mahesh & Kent
>
>

Andy


>
> ___
> Netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Martin Bjorklund]

Mahesh Jethanandani  wrote:
> WG,
> 
> The authors of rfc7895bis have indicated that they believe the
> document is ready for LC[1].
> 
> This starts a two week LC on the draft
> . The LC
> will end on February 15.
> 
> Please send your comments on this thread. Reviews of the document, and
> statement of support are particularly helpful to the authors. If you
> have concerns about the document, please state those too.
> 
> Authors please indicate if you are aware of any IPR on the document.

I am not aware of any IPR related to this document.


/martin

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

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Juergen Schoenwaelder]

On Thu, Feb 01, 2018 at 10:59:47AM -0800, Mahesh Jethanandani wrote:
> 
> Authors please indicate if you are aware of any IPR on the document.
> 

I am not.

/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] LC on YANG Library (bis)

[Mahesh Jethanandani]

WG,

The authors of rfc7895bis have indicated that they believe the document is 
ready for LC[1].

This starts a two week LC on the draft 
. The LC will end 
on February 15. 

Please send your comments on this thread. Reviews of the document, and 
statement of support are particularly helpful to the authors. If you have 
concerns about the document, please state those too.

Authors please indicate if you are aware of any IPR on the document.

Thanks.

[1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html 


Mahesh & Kent

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

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

[Eliot Lear]

Hi Kent,

In the Department of Moving Things Along, I think I counted two comments
that Mahesh addressed during WGLC.  What are next steps?

Eliot


On 17.01.18 22:55, Kent Watsen wrote:
> All,
>
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-15.
>
> This working group last call ends on January 31st.
> 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.
>
> Also, could the authors, explicitly CC-ed on this email,
> please 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://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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Mahesh Jethanandani]

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.
- 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.
- Andy had questions around datastore set to “conventional”, about origin 
filter limited to 1 source and the behavior of with-defaults. 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. 

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 
>> > >  >> 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 (regardless of whether the operational 
>> value matches a schema default value).
>> - it does not need to, and should not, return operational values for stuff 
>> that isn't actually in use, i.e. don't return needless and unwanted data.
>> 
>> In particular, if no value is returned from a particular data node in 
>>  then, barring mgmt protocol errors, a client can assume that 
>> any functionality associated with that data node is off (i.e. not in use).
>> 
>> Some examples to illustrate the behavio

Re: [netmod] RtgDir review: Review of draft-ietf-netmod-yang-tree-diagrams-05.txt

[Martin Bjorklund]

Hi Stig,

Thank you for your review!  Comments inline.


Stig Venaas  wrote:
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about
> the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
> 
> Document: draft-ietf-netmod-yang-tree-diagrams-05.txt
> Reviewer: Stig Venaas
> Review Date: 2018-01-29
> IETF LC End Date: 2018-02-07
> Intended Status: Best Current Practice
> 
> Summary:
> This document is basically ready for publication, but has nits that
> should be considered prior to publication.
> 
> Comments:
> The draft is well written and ready for publication except for perhaps
> two nits. My YANG skills are a bit limited though, so it is possible
> that I may have missed issues.
> 
> Major Issues:
> No major issues found.
> 
> Minor Issues:
> No minor issues found.
> 
> Nits:
> In the introduction it says:
>Today's common practice is to include the definition of the syntax
>used to represent a YANG module in every document that provides a
>tree diagram.  This practice has several disadvantages and the
>purpose of the document is to provide a single location for this
>   
>definition.  It is not the intent of this document to restrict future
>changes, but rather to ensure such changes are easily identified and
>suitably agreed upon.
> 
> It would be better to say "this document".

Thanks, fixed in the source!

> In section 2 it says:
>A module is identified by "module:" followed the module-name.
> 
> In the introduction [RFC7223] Section 3 is given as an example
> tree diagram, but this does not start with "module:". Would
> another example be better?

First of all, the example is legal since the text says:

Module trees may be included in a document as a whole, by one or
more sections, or even subsets of nodes.

I also think the example is fine, since it is in the introduction,
and, well, just an example of what current trees look like.

> It might also be good to have a
> richer example that makes use of most of the defined symbols.

I'm not sure what example we would use for this.  We believe that the
current examples in the document are "good enough".


/martin


> 
> Otherwise the document looks great to me.
> 
> Stig
> 
> ___
> 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