OK, it looks like we converged. Thank you all.
I will use the text below for the draft.
Kent // with editor hat on ;)
On 10/19/15, 9:52 AM, "Robert Wilton" <rwil...@cisco.com> wrote:
>Hi Kent, Gert,
>
>For clarity, the text that I had reached for 3 (folding in the comments
>so far) is this:
>
> 3. Support for both synchronous and asynchronous configuration
> operations (see terms)
>
> A. A server may support only synchronous configuration
> operations, or only asynchronous configuration operations, or
> both synchronous and asynchronous configuration operations on
> a client-specified per-operation basis.
>
> B. Servers that support asynchronous configuration operations MAY
> also provide a verify operation that a client can request from
> the server to return information regarding the difference
> between the intended and applied configurations.
>
> C. The configuration protocol MUST specify how configuration
> errors are handled. Errors may be handled by "stop on error",
> "continue on error" or "rollback on error" semantics (see
> terms). Support for "rollback on error" SHOULD be provided.
>
>
> Extra terms to add the definitions section (based on the definitions
>for NETCONF RFC):
>
> stop-on-error: The configuration operation is aborted on the
>first
> error.
>
> continue-on-error: Continue to process configuration data on
> error; error is recorded, and negative response is generated
> if any errors occur.
>
> rollback-on-error: If an error condition occurs such that part
> of applying the configuration fails, the server will stop
> processing the configuration operation and restore the
> specified configuration to its complete state at the start
> of this configuration operation.
>
>
>Gert has provided some definitions that are closer to Kent's original
>text, how do we resolve?
>
>Thanks,
>Rob
>
>
>On 19/10/2015 14:22, Kent Watsen wrote:
>> I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
>> change the 1.D text to..."
>>
>> Sorry for the confusion.
>>
>> Kent
>>
>>
>> On 10/19/15, 9:14 AM, "Kent Watsen" <kwat...@juniper.net> wrote:
>>
>>> Hi Rob,
>>>
>>> I know there is an on-going discussion about the time-line of things,
>>>but
>>> the draft needs to be posted today... Can you help finalize the text?
>>>
>>> Randy offers some good editorial suggestions below, and I believe you
>>>and
>>> Gert had some ideas in wordsmithing 1.D. and bringing in error modes.
>>>
>>> Thanks,
>>> Kent
>>>
>>>
>>> On 10/16/15, 11:29 PM, "Randy Presuhn" <randy_pres...@mindspring.com>
>>> wrote:
>>>
>>>> Hi -
>>>>
>>>>> From: Robert Wilton
>>>>> Sent: Oct 16, 2015 5:12 AM
>>>>> To: Kent Watsen , Nadeau Thomas
>>>>> Cc: "netmod@ietf.org"
>>>>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
>>>>> asynchronous systems to provide a blocking config update?
>>>> ...
>>>>> Here is my attempt at word smithing section 3:
>>>> ...
>>>>> A. A server may choose to support only synchronous
>>>>> configuration
>>>>> operations, or only asynchronous configuration
>>>>> operations, or
>>>>> both synchronous and asynchronous configuration
>>>>> operations in
>>>>> a client specified per-operation basis.
>>>> Editorial comments:
>>>> - is the "may" intended as a RFC 2119 MAY? If so, this seems
>>>> a semantically inappropriate use of the keyword.
>>>> - please avoid unnecessary anthropomorphisms; the server doesn't
>>>> "choose" anything here.
>>>> - s/ in/ on/
>>>> - s/client specified/client-specified/
>>>>
>>>> ...
>>>>> failed. A configuration protocol, or server, SHOULD
>>>>>provide
>>>>> support for rollback-on-error behavior and MAY choose to
>>>>> provide support for best effort semantics as well.
>>>> Editorial comments:
>>>>
>>>> - The implications of the RFC 2119 SHOULD and MAY are quite
>>>>different
>>>> depending on which of the two subjects ("protocol" or "server")
>>>>one
>>>> chooses to think about. The server's observable behaviour is
>>>> presumably
>>>> circumscribed by the protocol, so I suggest removing ", or
>>>>server,".
>>>>
>>>> - Please suppress anthropomorphisms.
>>>>
>>>> - s/best effort/best-effort/
>>>>
>>>> Randy
>>>>
>>>> _______________________________________________
>>>> 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
>> .
>>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
