I think that works for me.
What I read you as saying is that we could simply define that any and
all validation of I2RS operations is a local matter and up to the server.
This would remove any need for flags or marking, and also remove any
need for indicating a mode of operation.
If that is what you meant, it works for me.
Yours,
Joel
On 6/6/16 9:01 PM, Andy Bierman wrote:
On Mon, Jun 6, 2016 at 5:46 PM, Joel M. Halpern <[email protected]
<mailto:[email protected]>> wrote:
When we started on the I2RS work, the explicit request from the
operators was to make this as simple as practical and as efficient
as practical.
In regard to constraints on what they could do, the specific request
was "let us shoot ourselves in the foot." That is, if some change
will break the network, so be it. it is the operators problem. If
the change only causes the box to reboot, that is less dangerous.
So it seems to fall within "let me shoot my foot."
I expect that there are some forms of validation that need to take
place just to attempt to apply the RPC. But everything beyond that
was requested to be not performed. Whether we can actually achieve
that is a different question.
It does strike me that we can also go back and ask the operators
again what they meant, if you think it is likely we misunderstood.
In my example "when IPv4" is ignored so IPv6 parameters are
accepted as valid.
Does this mean the server faithfully applies the wrong parameters that
make no sense whatsoever? Probably not. It means the client developer
and operator have no idea what a server implementation is SUPPOSED to
accept as a valid edit. (Which diminishes the standards value of I2RS)
My original point was that extra flags for I2RS like "I ignore all leafrefs"
are worthless. It is better to declare that validation is not part of
the ephemeral datastore. It is an implementation detail whether accepted
data in that datastore ever gets used.
Yours,
Joel
Andy
On 6/6/16 8:26 PM, Andy Bierman wrote:
Hi,
I am still a little confused on the intent of the partial YANG
validation.
It seems trivial to adapt the NETCONF or RESTCONF validation
points to I2RS.
The only difference is that I2RS data can have constraints
pointing at
config=false
nodes, so this is more complicated and expensive to implement
than NETCONF
or RESTCONF.
The argument for partial validation I have heard is "We only
support 1
client and
we know the client already checks the data, so we know the data
is valid."
This is not arguing that there will be invalid data in the
datastore.
It is arguing
that the client can be trusted to be correct and bug-free so why
bother
spending
server resources duplicating the validation.
Typically in NM standards we assume more than 1 client is
allowed in the
design
and a client cannot be trusted. A client could be malicious or
buggy.
Either way, if the server crashes or allows a security breach
it's still the server vendor's fault.
I2RS seems like an implementation detail (not a standard) if
vendors plan on
writing both client and server code and not intending to support
any 3rd party implementations.
Andy
On Mon, Jun 6, 2016 at 4:25 PM, Susan Hares <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Andy: ____
__ __
I’m not sure the context you are referring to as “I2RS agent
pick
which Yang statements they will implement”. ____
__ __
From the context, I guess you are investigating Ephemeral
Configuration State. If “the server MAY do YANG validation____
on the ephemeral datastore”, and then check it in
operational state
– this clearly works. However, I’m struggling to fit the normal
Ephemeral Configuration State validation into section 8.3 of
RFC6020bis. There are three steps in constraint enforcement
(section 8.3 of RFC6020bis). ____
o during parsing of RPC payloads - ____
o during processing of the <edit-config> operation____
o during validation____
__ __
Currently section 8.3.3 says: ____
__ __
“8.3.3. Validation____
__ __
When datastore processing is complete, the final contents
MUST
obey all validation constraints. This validation processing is
performed at differing times according to the datastore. ____
__ __
If the datastore is "running" or "startup", these
constraints MUST
be enforced at the end of the <edit-config> or <copy-config>
operation. If the datastore is "candidate", the constraint
enforcement is delayed until a <commit>____
or <validate> operation.”____
__ __
My understanding is we are discussing how constraint enforcement
works in Ephemeral Configuration State. ____
You need to define where the ephemeral constraints MUST Be
enforced. It would seem reasonable to enforces at the end of
<edit-config> or <copy-config>, or by the end of an rpc
operation
defined in a data model. ____
__ __
Since RESTCONF uses PUTS/PATCH within a HTTP exchange, then the
constraint enforcement must be at the end of that http
operation. ____
__ __
Sue ____
__ __
____
__ __
__ __
*From:*i2rs [mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>] *On Behalf Of *Andy Bierman
*Sent:* Sunday, June 05, 2016 5:43 PM
*To:* [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
*Subject:* [i2rs] YANG validation and opstate____
__ __
Hi,____
__ __
I don't really agree with idea that I2RS agents pick which____
YANG statements they will implement, but I think there is____
a way to handle this correctly in the datastore framework.____
__ __
The proposed enumeration for server validation____
capabilities (e.g., full, XPath, leafref) is not really
needed.____
This enum is too course-grained to be useful.____
__ __
IMO it is better to say the server MAY do YANG validation____
on the ephemeral datastore. Whether or not the server uses____
data from the ephemeral datastore is left as an implementation
detail.____
The server could use invalid input parameters or ignore them____
or reject them in the first place.____
____
The client needs to check operational state to know if/when
the____
ephemeral data was applied to the system.____
__ __
__ __
__ __
Andy____
__ __
_______________________________________________
i2rs mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
