Re: [netmod] Fwd: Re: Leafref and require-instance=false
On Mon, Jun 8, 2015 at 11:49 AM, Ladislav Lhotka lho...@nic.cz wrote:
Andy Bierman a...@yumaworks.com writes:
On Mon, Jun 8, 2015 at 8:39 AM, Kent Watsen kwat...@juniper.net wrote:
I think the two leafs are coupled through the path statement and so the
values of both should conform to the same type. If I extend Balazs¹
example with uint8 and 1..10 range:
1. Would a leafref value of 256 be acceptable?
2. How about foo?
I agree it doesn't makes sense, but is the configuration invalid?
The leafref is marked require-instance=false, it just means a matching
condition will never succeed.
If require-instance = false then the node must conform to
the data type for the leaf. This means the typedef used
in the implemented version.
Would a configuration be invalid if a when expression could never
evaluate to true?
The node would never appear in a configuration.
A must-stmt then is always false would make the config invalid.
What's actually relevant to the subject of this thread (and supports
Kent's point somewhat) is this example:
leaf foo {
type uint8;
must . = 10;
}
leaf bar {
type leafref {
require-instance false;
path ../foo;
}
}
Should bar20/bar be flagged as invalid? IMO no. At first sight it
looks exactly like Balazs' example but in fact it is different - if
there is no foo, the must expression doesn't apply.
I don't see where a range 1..20 is introduced.
The leaf bar has the same type as /foo,
so that is uint8.
I see your point... does require-instance false
mean it could be a valid value for the leaf, but
no instances happen to exist with that value?
Or does it mean valid for the same data-type but the instance
may never exist?
I think valid for the data type is correct.
The must-stmt says valid for the leaf to exist.
That is a separate test.
Lada
Andy
Kent
Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Fwd: Re: Leafref and require-instance=false
Ladislav Lhotka lho...@nic.cz wrote:
Andy Bierman a...@yumaworks.com writes:
On Mon, Jun 8, 2015 at 8:39 AM, Kent Watsen kwat...@juniper.net wrote:
I think the two leafs are coupled through the path statement and so the
values of both should conform to the same type. If I extend Balazs¹
example with uint8 and 1..10 range:
1. Would a leafref value of 256 be acceptable?
2. How about foo?
I agree it doesn't makes sense, but is the configuration invalid?
The leafref is marked require-instance=false, it just means a matching
condition will never succeed.
If require-instance = false then the node must conform to
the data type for the leaf. This means the typedef used
in the implemented version.
Would a configuration be invalid if a when expression could never
evaluate to true?
The node would never appear in a configuration.
A must-stmt then is always false would make the config invalid.
What's actually relevant to the subject of this thread (and supports
Kent's point somewhat) is this example:
leaf foo {
type uint8;
must . = 10;
}
leaf bar {
type leafref {
require-instance false;
path ../foo;
}
}
Should bar20/bar be flagged as invalid? IMO no.
No! flagged as invalid is not precise enough - note that
foo20/foo is ok in some circumstances, e.g., it is ok to have
foo20/foo in the candidate. However foo20/foo can never be
part of a valid configuration.
bar20/bar is always ok.
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Fwd: Re: Leafref and require-instance=false
Andy Bierman a...@yumaworks.com writes:
On Mon, Jun 8, 2015 at 8:39 AM, Kent Watsen kwat...@juniper.net wrote:
I think the two leafs are coupled through the path statement and so the
values of both should conform to the same type. If I extend Balazs¹
example with uint8 and 1..10 range:
1. Would a leafref value of 256 be acceptable?
2. How about foo?
I agree it doesn't makes sense, but is the configuration invalid?
The leafref is marked require-instance=false, it just means a matching
condition will never succeed.
If require-instance = false then the node must conform to
the data type for the leaf. This means the typedef used
in the implemented version.
Would a configuration be invalid if a when expression could never
evaluate to true?
The node would never appear in a configuration.
A must-stmt then is always false would make the config invalid.
What's actually relevant to the subject of this thread (and supports
Kent's point somewhat) is this example:
leaf foo {
type uint8;
must . = 10;
}
leaf bar {
type leafref {
require-instance false;
path ../foo;
}
}
Should bar20/bar be flagged as invalid? IMO no. At first sight it
looks exactly like Balazs' example but in fact it is different - if
there is no foo, the must expression doesn't apply.
Lada
Kent
Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Comments on draft-bogdanovic-netmod-yang-model-classification-03
Eric, Thanks for the feedback, comments inline below. On Jun 5, 2015, at 8:17 AM, Osborne, Eric eric.osbo...@level3.com wrote: General comments: the doc is pretty straightforward in many of its aims but parts of it are confusing. Certain sections need some copyediting and an infusion of 'the'. It also barely touches on the idea of config models vs state data and ops, and this distinction is (I think) pretty lost at some points. Do Standard models include config, state and ops? Or are Standard models just some subset? Do they *have* to be a subset? Adding more discussion around the interplay of [standard, standard extension, proprietary, vendor] * [config, state, ops] would be interesting. Specific comments: 1) --- o Based on the level of abstraction in the model o Based on the applicability of the model The two categories are covered in the next two sections. 2. First Dimension: YANG Data Model Layering . 3. Second Dimension: Model Type - The section titles should match the bulleted list. Maybe the first dimension should be 'Model Abstraction Levels' and the second should be 'Model Applicability’? Since the content of section 2 is all around “layering”, I did the following: tThis document presents a set of concepts and terms to form a useful taxonomy for consistent classification of YANG models in two dimensions: list style=symbols tThe layering of models based on their abstraction levels/t tThe type of model based on the nature and intent of the content/t 2) Figure 1 lists both 'BGP' and 'Routing'. I'm guessing from context that 'Routing' really means 'RIB' or something, and I know there's been a lot of discussion I've been very vigorously disregarding, but maybe 'Routing' in this doc should read 'RIB' so as to not let the reader think it's shorthand for 'Routing Protocol'? Or if you intend for 'Routing' to mean 'Routing Protocol', then shouldn't BGP be subordinate to it? Good catch, switched the labels to MPLS, BGP, IPv4 IPv6 and “Ethernet 3) -- As an example, the Network Service model included in http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/ provides an --- Fix the reference to [I-D-l3vpn-service-yang] or whatever the right format is. Fixed, thanks. Will submit a pull-request based on the above. Again; thanks! 4) Section 3 gets a little tricky. It seems to imply that the service models are built after the vendor models are built, and that the service models can only be built out of the pieces provided by vendor models. While this makes sense on its face (you can't use a component to build a service if that component doesn't exist), it reads like SDOs are beholden to the vendors exposing the right bits before the SDOs can do anything. Surely there's going to be some give and take here, where SDOs (or customers! ahem..) isssue standard service models and the vendors need to come up with config models to support them? It's also not clear exactly what turf 'vendor config models' is grabbing. If we have a standard ACL model, for example, do I also need a vendor ACL config model? 5) I'm not sure what value the discussion around routing protocol config (p. 8+) provides. Does this schism of protocol vs vrf centricity apply to state and ops too? Is it specific to config? It's called out here but there's no conclusion, it just says here's a thing. Why is this thing more important than all the other things that could be mentioned? Also, you may want to remove CLI from the discussion of centricity; it's clear that this is an IOS-vs-JunOS section. If you're going to show both models, use YANG or pseudo-YANG to describe both. 6) I don't get section 3.5. Why is it there? Just as a placeholder to say this might happen? Shouldn't any discussion of vendor models either a) stay away from telling vendors what to do, or b) encourage vendors to get off of proprietary models ASAP once there's a standard one? That's sort of what while waiting... means, but I think this section either should be much bigger or not be there. 7) I don't like the last paragraph of section 5. What is it saying? That the IETF can take the Linux kernel and write a standard model for it? I guess maybe it's trying to say IETF must be the place where all models are blessed if they're about IETF technology? Is the RIB IETF technology? What about an ACL? Does the IETF not recognize other sources of models for IP-and-SDN stuff? eric ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Fwd: Re: Leafref and require-instance=false
I think the two leafs are coupled through the path statement and so the values of both should conform to the same type. If I extend Balazs¹ example with uint8 and 1..10 range: 1. Would a leafref value of 256 be acceptable? 2. How about foo? I agree it doesn't makes sense, but is the configuration invalid? The leafref is marked require-instance=false, it just means a matching condition will never succeed. Would a configuration be invalid if a when expression could never evaluate to true? Kent ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Fwd: Re: Leafref and require-instance=false
Andy Bierman a...@yumaworks.com wrote: On Mon, Jun 8, 2015 at 8:39 AM, Kent Watsen kwat...@juniper.net wrote: I think the two leafs are coupled through the path statement and so the values of both should conform to the same type. If I extend Balazs¹ example with uint8 and 1..10 range: 1. Would a leafref value of 256 be acceptable? 2. How about foo? I agree it doesn't makes sense, but is the configuration invalid? The leafref is marked require-instance=false, it just means a matching condition will never succeed. If require-instance = false then the node must conform to the data type for the leaf. This means the typedef used in the implemented version. +1 /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
