On Tue, Oct 6, 2015 at 1:42 PM, Robert Wilton <rwil...@cisco.com> wrote:
> Hi Juergen, > > On 06/10/2015 17:16, Juergen Schoenwaelder wrote: > >> On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: >> >>> Hi Kent, >>> >>> Feeding in the various input, I think that this is the best refinement >>> that I've come up with: >>> >>> Synchronous configuration operation - A configuration request to update >>> the running configuration of a server that is applied synchronously with >>> respect to the client request. The server SHOULD ensure that the >>> request is valid, and MUST fully effect the configuration change to all >>> impacted components in the server, updating both the server's intended >>> and applied configuration (see terms), before replying to the client. >>> The reply to the client indicates whether there are any errors in the >>> request or errors from applying the configuration change. >>> >> What does "SHOULD ensure that the request is valid" mean? RFC 6020 >> says: >> >> 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. >> >> Are we talking about datastore validation or validation of a request? >> If the former, are we watering down a MUST to a SHOULD? >> > Really it is datastore validation, particularly for an async request where > the intended config nodes are updated before replying. I'm not > intentionally trying to water down a MUST to a SHOULD, but Kent had > concerns that my previous description using "semantically validate" would > exclude an ephemeral datastore, so I was trying to water down the > description and also describe the behaviour in a way that isn't specific to > either RESTCONF/NETCONF or datastores. > > I have been thinking about I2RS validation, and it there might be good reasons to say SHOULD instead of MUST (wrt/ ephemeral datastore anyway). The server instrumentation can do a better job than the server at deciding how to prune bad config. It may be much faster to have the server do syntax validation but not YANG constraint validation. The instrumentation examines the ephemeral datastore to apply what it can. The rest gets ignored. This may be too sloppy for standards, but I2RS is supposed to be fast. Andy Perhaps, the start of sentence could simply be changed to: > > The server MUST fully effect the configuration change to all > impacted components in the server ... > > > And equivalently for the asynchronous case below: > > The server MUST update the server's intended configuration ... > > > > >> Asynchronous configuration operation - A configuration request to update >>> the running configuration of a server that is applied asynchronously >>> with respect to the client request. The server SHOULD ensure that the >>> request is valid, and MUST update the server's intended configuration >>> (see term) before replying to the client indicating whether the request >>> will be processed. The server's applied configuration state (see term) >>> is updated after the configuration change has been fully effected to all >>> impacted components in the server. The reply to the client only >>> indicates whether there are any errors in the original request. >>> Synchronous system - Client/server interactions that process all >>> configuration requests as synchronous configuration operations (see >>> term). >>> >> I think "synchronous system" is misleading, perhaps "synchronous >> configuration server". The definitions talk about how a server >> processes requests, they are silent about clients: >> > I agree. Some of the requirement text would probably need to be tweaked > to accommodate this. > > >> Synchronous configuration server - a configuration server that >> processes all configuration operations as synchronous configuration >> operations. >> >> Asynchronous system - Client/server interactions that process all >>> configuration requests as asynchronous configuration operations (see >>> term). >>> >> Asynchronous configuration server - a configuration server that >> processes all configuration operations as asynchronous configuration >> operations. >> >> And I would not be surprised if we also need this sooner or later: >> >> Mixed configuration server - a configuration server that processes >> some configuration operations as synchronous configuration >> operations and some configuration operations as asynchronous >> configuration operations. >> > Yes, I would expect that clients may want to define the expected > behaviour, potentially on a per request basis. > > >> Any further comments? >>> >>> Based on the feedback from Andy and others, it seems that the prevailing >>> view is that existing NETCONF and RESTCONF should be regarded as being >>> asynchronous in their behaviour in that the config nodes in the running >>> datastore only represent the intended configuration and not the applied >>> configuration. >>> >> Depends on the definition of applied configuration - where is the latest >> version of it? >> > The last proposed text for intended/applied is as below: > > intended configuration - this data represents the configuration > state that the network operator intends the system to be in, and that > has been accepted by the system as valid configuration. This data is > colloquially referred to as the 'configuration' of the system. > > applied configuration - this data represents the configuration > state that the network element is actually in, i.e., the > configuration state which is currently being being used by system > components (e.g., control plane daemons, operating system > kernels, line cards). > > From Thursday's interim meeting, Rob Shakir clarified that the desired > intention is that applied configuration should mean that the configuration > is fully applied everywhere. I don't know if that means that the > definition of applied configuration should be strengthened, or if it is > sufficient? > > Thanks, > Rob > > >> /js >> >> > _______________________________________________ > 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
