Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06

[Juergen Schoenwaelder]

On Wed, Jan 06, 2016 at 06:28:41PM +0100, Dean Bogdanovic wrote:
> 
> > On Jan 6, 2016, at 10:30 AM, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Mon, Jan 04, 2016 at 07:23:38PM +0100, Eliot Lear wrote:
> >> Hi Juergen,
> >> 
> >> On this point:
> >> 
> >> On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote:
> >> 
> >>> And
> >>> should the interface reference not use a more specific type than
> >>> 'string’?
>  Interface references can be many things, from standard naming we are 
>  familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as 
>  string gives us most flexibility in that regards.
> >>> I disagree that the goal here is most flexibility. We do have an
> >>> interfaces data model in the IETF. Why are we avoiding to refer to it
> >>> here?
> >>> 
> >> 
> >> I think it would be helpful if you could be specific as to your
> >> concern.  It is absolutely the case that the SNMP folk did an awful lot
> >> of work on managing interfaces.  While I am not concerned about the form
> >> of the name, I wonder if your concern is around some of the semantics,
> >> but I can't tell.
> >> 
> > 
> > My question is why the model does not use interface-ref or
> > interface-state-ref defined in RFC 7223 but instead an opaque string
> > to refer to an interface. Have we thought about the design tradeoffs?
> > 
> > My question is _not_ about how we deal with interface naming schemes,
> > that discussion took place when RFC 7223 was created.
> 
> In the example where the ACL is attached to the interface, we are using 
> interface-ref, so replacing interface in the metadata, can be easily done.
>

This does not answer why input-interface is of type string... I do not
understand what 'replacing interface in the metadata, can be easily
done' tells me.

/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

Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Ladislav Lhotka]

> On 07 Jan 2016, at 10:07, Juergen Schoenwaelder 
>  wrote:
> 
> On Thu, Jan 07, 2016 at 09:59:01AM +0100, Eliot Lear wrote:
>> 
>> 
>> On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote:
>>> This does not answer why input-interface is of type string...
>> 
>> To be perfectly clear you seek that type string be replaced with
>> interface-ref?
>> 
> 
> I think for this leaf the type of choice would be interface-state-ref
> unless there are strong reasons to use something opaque.

Unfortunately, this is impossible because configuration leafrefs cannot refer 
to leafs in state data.

Should this CLR be removed? IMO, yes.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

[netmod] applied configuration and system-controlled entries

[Ladislav Lhotka]

Hi,

a good use of applied configuration could be to formalize the concept of 
system-controlled entries as defined in RFC 7223, routing-cfg, and probably 
elsewhere, too.

My idea is that system-controlled interfaces or other entries would appear in 
applied configuration, but not in intended configuration until something needs 
to be really configured. We could then permit leafrefs from intended 
configuration to refer to leafs in applied configuration. One case where this 
would be useful is the ACL module, where match conditions refering to 
interfaces currently have to use plain strings as references to interface names.

However, the above idea seems to be at odds with requirement 1D in 
opstate-reqs-02. I wonder: could that requirement be relaxed or removed so that 
the above use case can be supported?

Thanks, Lada
  
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Juergen Schoenwaelder]

On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:
> 
> With YANG 1.1, a leafref can be marked as "require-instance false",
> which allows a interface-state-ref to be used in config:
> 
>type if:interface-state-ref {
>  require-instance false;
>}
>// + add description that explains what happens if there is no such
>//   instance
> 
> 
> (NOTE: this doesn't work w/ pyang at the momement, I am working on a
> fix)
> 

And it would have to be if:interface-ref instead if:interface-state-ref
I think.

/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

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

[Robert Wilton]

Hi Juergen,

On 07/01/2016 16:05, Juergen Schoenwaelder wrote:

On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:

It’s true that the draft is largely centered around the intended/applied config notion, 
but not exclusively.  Specifically, 4-B has "Ability to map intended config nodes to 
associated derived state nodes".  I think that this might be the only exclusion 
though and, if it weren’t for it I would’ve used your title suggestion from the LC 
review.   Should one requirement have such influence over the title is the question.  I 
was trying to be fair to it, but maybe it's going too far.

Regarding visibility and control, I was attempting to use common words (not 
normative terms) here.  My intent for them is something along the lines of:

visibility: read/understand
control: write/orchestrate


We do not write operational state. I have no clue how 'orchestrate'
helps me either. What is wrong with using defined terminology in
a title?
I don't think that using defined terminology is a problem.  But I also 
think that the title that you have suggested seems to suggest a narrower 
scope that what the requirements articulate.


In particular, the draft places requirements relating the configuration 
to the derived state (I.e. Req 4B).


It also places further requirements on how management protocols are 
expected to handle synchronous and asynchronous config edit requests. 
(E.g. Req 2 A, B, C and associated definitions).


I don't have a particular problem with the current title, but if you 
don't like visibility/control, then perhaps "Terminology and 
Requirements for Enhanced Handling of Operational State"?


Thanks,
Rob




/js



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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Martin Bjorklund]

Hi,

"Acee Lindem (acee)"  wrote:
> 
> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
> 
> >
> >> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
> >> wrote:
> >> 
> >>> 
>  On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>  wrote:
>  
>  On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>  
> > I hope that nobody disagrees that the operational state design and
> >how 
> > to structure the models are the two blocking factors to publish YANG
> > models. If you disagree or don't see this, let me know, I should
> > communicate better.
>  
>  Even if it may spoil your day, I disagree that there is a blocking
>  factor that should stop us from publishing models. There seem to be
>  ways to address the requirements without having to block all work or
>  to redo what that we have published. But sure, if you make it a
>  blocking factor, it will be one.
> >>> 
> >>> I agree with Juergen. It is not clear to me how the proposed split
> >>>between intended and applied configuration is supposed to affect the
> >>>data models we are working on.
> >> 
> >> 
> >> As I understand it, solution #1 affects the models themselves, whereas
> >>solutions #2 and #3 are transparent to the models.
> >
> >Then #1 looks like a non-starter to me.
> 
> I’d like to point out that we also have the requirement to allow retrieval
> of derived-state along with intended-config and applied-config. This will
> require modification to most of the existing YANG drafts as most now have
> separate trees for config and operational state.

I don't agree with the conclusion that changes are needed due to this
requirement.

Solution #1 ("openconfig") requires changes to handle applied config.
Solution #2 ("kent's") does not.

Both solutions #1 and #2 use separate nodes for derived state.

It might appear as #1 and #2 are very different in their handling of
derived state, since #1 put all config false nodes directly under the
config true nodes, whereas #2 in some cases have a top-level
"xxx-state" config false node.

But in fact #2 allows the solution in #1 as one special case.  The
reason that RFC 7223 has a separate list for derived state interfaces
is to allow for non-configured interfaces to be monitored.  If this
was not a requirement, all config false nodes could (would) have been
defined in the config true interface list.


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

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

[Kent Watsen]

On 1/7/16, 12:24 PM, "Robert Wilton"  wrote:

>I don't have a particular problem with the current title, but if you 
>don't like visibility/control, then perhaps "Terminology and 
>Requirements for Enhanced Handling of Operational State"?


This looks good to me.  If no objections are raised by tomorrow, I’ll post -03 
using this title.

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

Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Martin Bjorklund]

Hi,

Martin Bjorklund  wrote:
> With YANG 1.1, a leafref can be marked as "require-instance false",
> which allows a interface-state-ref to be used in config:
> 
>type if:interface-state-ref {
>  require-instance false;
>}
>// + add description that explains what happens if there is no such
>//   instance
> 
> 
> (NOTE: this doesn't work w/ pyang at the momement, I am working on a
> fix)

FYI, I have fixed pyang now (branch yang-1.1) to allow
require-instance in derived leafrefs.


/martin

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