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"? 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.
Thanks,
Kent
On 1/21/18, 12:32 AM, "Mahesh Jethanandani"
<[email protected]<mailto:[email protected]>> wrote:
On Jan 20, 2018, at 7:21 AM, Kent Watsen
<[email protected]<mailto:[email protected]>> wrote:
Hi Mahesh,
I'm okay not adding the ability to reference an external rulebase now, or are
you saying that you'd also like to defer priming the YANG model now so that it
can be added later in a backwards compatible manner?
If you plan to prime the YANG model so that the ability to reference an
external rulebase can added later in a backwards compatible manner, can you
please send a concrete proposal to the list so that we can better understand
the impact?
My expectation is that it merely adds a 'choice' statement around the existing
rulebase container, thereby enabling something other than a rulebase container
to exist some day in the future.
That is correct. The proposal is to add a ‘choice’ statement in parts of the
model that will allow an external rulebase to be added in the future as another
case statement.
Here is the concrete proposal of what those changes will look like:
https://github.com/netmod-wg/acl-model/pull/23<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_acl-2Dmodel_pull_23&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=TTcVNmD-pP5Jg3P0iLLmNN-oThtmLiDD-i-cfmml-d4&s=9amd15fEoT406blmduaLuqGo7l1Mi0jt86nidbOJ2fU&e=>
Thanks
If the addition is indeed just this, then I don't believe that it materially
changes the ACL model and therefore can be added as a LC comment. Of course,
the WG will want to review the addition for correctness, but otherwise should
be alright.
Thanks,
Kent // co-chair and shepherd
===== original message =====
Kent,
I have not heard a strong requirement to have the open issue fixed in this
version of the RFC. We would therefore like to defer it to a bis document.
I will wait for the LC to complete, and update the draft to address all the
comments received during the LC.
Thanks.
On Jan 17, 2018, at 3:33 PM, Kent Watsen
<[email protected]<mailto:[email protected]>> wrote:
H Mahesh,
- There is an open issue in the document (section 8) - are we going
to resolve that during WG last call or is this a leftover?
This will be resolved in the next version of the module. It is
documented under Issues tab in GitHub. Should we remove it from
the draft?
Most of Juergen's comments are editorial in nature and can truly be handled as
part of the LC process, but this open issue has me worried, as it may result in
a significant technical change.
What will it take to close this open issue? Is it just a matter of the getting
the WG to agree that it's not an issue, or do we already know that it is a real
issue and only the solution is pending?
Thanks,
Kent
Mahesh Jethanandani
[email protected]<mailto:[email protected]>
Mahesh Jethanandani
[email protected]<mailto:[email protected]>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
