Subject: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt

From: [email-masked]
Date: Fri, 08 Jan 2016 16:58:30 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : Terminology and Requirements for Enhanced Handling of Operational State
        Authors         : Kent Watsen
                          Thomas Nadeau
	Filename        : draft-ietf-netmod-opstate-reqs-03.txt
	Pages           : 7
	Date            : 2016-01-08

Abstract:
   This document primarily regards the difference between the intended
   configuration and the applied configuration of a device and how
   intended and applied configuration relate to the operational state of
   a device.  This document defines requirements for the applied
   configuration's data model and its values, as well as for enabling a
   client to know when a configuration has been fully applied or not,
   how to access operational state, and how to relate intended
   configuration nodes to applied configuration and derived state nodes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kent Watsen <[email-masked]>
Date: Sat, 9 Jan 2016 01:00:34 +0000

In addition to the title update, I also updated the abstract/introduction and fixed a couple editorial items.

Kent

On 1/8/16, 7:58 PM, "netmod on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 10 Jan 2016 12:26:05 +0100

> In addition to the title update, I also updated the abstract/introduction and fixed a couple editorial items.

I do not like the changes of the abstract/introduction, in particular
the phrase "requirements for the applied configuration's data model
and its values".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 11 Jan 2016 18:20:45 +0100

Hi Kent,

You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine.
However, it might be beneficial to say something such as in RFC 7698

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].

    While [RFC2119] describes interpretations of these key words in terms
    of protocol specifications and implementations, they are used in this
    document to describe design requirements for protocol extensions.

Btw, I never quite understood what a MAY means for a requirement.
See requirement 2B and 2C

Regards, Benoit

> .

---

From: Kent Watsen <[email-masked]>
Date: Mon, 11 Jan 2016 20:59:40 +0000

Hi Benoit,

>    document to describe design requirements for protocol extensions.

Is this needed?  Looking at RFC2119, I don’t read it as being very particular about the context it’s terms are used in.

Additionally, other requirements docs use RFC2119 without any such a paragraph (e.g., RFC7698, RFC7497, RFC7449, etc.)...

>See requirement 2B and 2C

For 2B, would you rather is be a SHOULD?
For 2C, would you rather this be a “may”?

FWIW, the other requirements docs listed above also use "MAY" in some of their “requirements"

Kent

---

From: Benoit Claise <[email-masked]>
Date: Tue, 12 Jan 2016 13:06:14 +0100

Hi Kent,

[btw, speaking as a contributor]
> Additionally, other requirements docs use RFC2119 without any such a paragraph (e.g., RFC7698, RFC7497, RFC7449, etc.)...
Yes, I've seen those RFCs. The IETF is not really consistent regarding 
RFC 2119 and requirement documents.
So I wanted to put the issue on the table. No strong view on way or the 
other.
> FWIW, the other requirements docs listed above also use "MAY" in some of their “requirements"
I saw that.
Changing the MAY keywords the way you proposed is one solution, but more 
importantly, you should tell us what is intent behind a MAY sentence is.
 From 2119:

    5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
        truly optional.  One vendor may choose to include the item because a
        particular marketplace requires it or because the vendor feels that
        it enhances the product while another vendor may omit the same item.
        An implementation which does not include a particular option MUST be
        prepared to interoperate with another implementation which does
        include the option, though perhaps with reduced functionality.
    In the
        same vein an implementation which does include a particular option
        MUST be prepared to interoperate with another implementation which
        does not include the option (except, of course, for the feature the
        option provides.)

So it means that the specified solution MAY or MAY not have this 
functionality, right?
So what is the requirement? Maybe it's not a requirement, but just 
something to think about.

Regards, Benoit

---

From: Kent Watsen <[email-masked]>
Date: Tue, 12 Jan 2016 21:04:49 +0000

[As a contributor]

From Benoit:

Yes, I've seen those RFCs. The IETF is not really consistent regarding RFC 2119 and requirement documents.
So I wanted to put the issue on the table. No strong view on way or the other.

[Kent] thanks.

Changing the MAY keywords the way you proposed is one solution,

[Kent] okay, I will do that.

but more importantly, you should tell us what is intent behind a MAY sentence is.
So it means that the specified solution MAY or MAY not have this functionality, right?

[Kent] yes, that is how I am interpreting it

So what is the requirement? Maybe it's not a requirement, but just something to think about.

[Kent] just something to think about I guess.  But I will change the two MAY instances in the draft, so we don’t need to worry about it anymore  ;)

Thanks,
Kent

---

From: Nadeau Thomas <[email-masked]>
Date: Tue, 12 Jan 2016 16:23:36 -0500

> On Jan 12, 2016:4:04 PM, at 4:04 PM, Kent Watsen <[email-masked]> wrote:
> 
> [As a contributor]
> 
> From Benoit:
> 

	I’ve also used lower-case “may” as well, to mean something less stricter. But Benoit is right in that
in a requirements document we should really use MUST and SHOULD but not MAY. A quick 
perusal of a few random RFCs containing WG requirements confirms this - at least with the
sample I used.

> [Kent] yes, that is how I am interpreting it

	It might be clearer to use SHOULD (or SHOULD NOT) instead of MAY or MAY NOT.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Jan 2016 08:32:17 +0100

> 	It might be clearer to use SHOULD (or SHOULD NOT) instead of MAY or MAY NOT.

In RFC 2119, MAY and SHOULD mean two very different things so you
can't simply change MAY to SHOULD without likely going through another
round of discussion.

/js

PS: Noting that something is "truly optional" (MAY) in a requirements
    is a way of making it explicit that something is not a requirement.
    Having documented agreement on non-requirements is almost as
    useful as agreement on requirements so I do not follow the logic a
    requirements document should not have MAYs.

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Jan 2016 17:24:22 +0000

Hi Kent,

> For 2C, would you rather this be a “may”?

I think that the text for 2A would be more clear using MUST rather than 
may (in the sense that a compliant server must choose one of the three 
options listed).

Before:

        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.

After:

        A.  A server MUST support only synchronous configuration
            operations, or only asynchronous configuration operations, or
            both synchronous and asynchronous configuration operations on
            a client-specified per-operation basis.

For 2B, I agree changing MAY to SHOULD but we should broaden this to 
apply to synchronous servers as well.  Even though a config edit 
operation is synchronous it could still fail to be applied for some 
leaves, and hence the intended and applied leaves could be out of step.  
Hence I propose the following change:

Before:

        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.

After:

        B.  Servers SHOULD 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.

For 2C, I think that the "may" should change to "SHOULD", otherwise the 
requirement that "rollback on error" semantics SHOULD be provided 
doesn't seem well grounded.

So, before:

        C.  The configuration protocol MUST specify how configuration
            errors are handled.  Errors MAY be handled by semantics
            similar to NETCONF's error-options for the <edit-config>
            operation (stop-on-error, continue-on-error, rollback-on-
            error), as described in Section 7.2 in [RFC6241], but
            extended to incorporate both the intended and applied
            configurations.  Support for "rollback on error" semantics
            SHOULD be provided.

After:

        C.  The configuration protocol MUST specify how configuration
            errors are handled.  Errors SHOULD be handled by semantics
            similar to NETCONF's error-options for the <edit-config>
            operation (stop-on-error, continue-on-error, rollback-on-
            error), as described in Section 7.2 in [RFC6241], but
            extended to incorporate both the intended and applied
            configurations.  Support for "rollback on error" semantics
            SHOULD be provided.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jan 2016 10:02:18 -0800

On Fri, Jan 15, 2016 at 9:24 AM, Robert Wilton <[email-masked]> wrote:

>> Is this needed?  Looking at RFC2119, I don’t read it as being very
>> particular about the context it’s terms are used in.
>>
>> Additionally, other requirements docs use RFC2119 without any such a
>> paragraph (e.g., RFC7698, RFC7497, RFC7449, etc.)...
>>
>>

IMO it would be a mistake to assume that the server implementation is
uniform
in its ability to provide this feature to a client.  This requires all
instrumentation
to be updated at once, which is just not realistic.  It would be much more
robust
to allow for the possibility that some subtrees cannot report "applied
yet?",
rather than force the server to lie about the applied status, or even
worse, not be able to provide this feature at all because the standard
insists on all-or-none.

Since updating instrumentation is time-consuming and labor-intensive,
a vendor might start with routing instrumentation or whatever subtrees
customers have experienced long convergence times.

Andy

> For 2B, I agree changing MAY to SHOULD but we should broaden this to apply
> to synchronous servers as well.  Even though a config edit operation is
> synchronous it could still fail to be applied for some leaves, and hence
> the intended and applied leaves could be out of step.  Hence I propose the
> following change:
>
> Before:
>
> requirement that "rollback on error" semantics SHOULD be provided doesn't
> seem well grounded.
>
> So, before:
>

---

From: Gert Grammel <[email-masked]>
Date: Fri, 15 Jan 2016 20:50:05 +0000

See below ..

On 2016-15-01 18:24, "netmod on behalf of Robert Wilton"
<[email-masked] on behalf of [email-masked]> wrote:

>> Is this needed?  Looking at RFC2119, I don¹t read it as being very
>>particular about the context it¹s terms are used in.
>>
>> For 2C, would you rather this be a ³may²?
>
Gert> support

>            difference between the intended and applied configurations.
Gert> as per definition of synchronous, the confirmation has to indicate
that the intended config has been applied or has been failed. I therefore
like to keep the current text suggesting to change the existing text
slightly (SHOULD instead of MAY):

B.  Servers that support asynchronous configuration operations
SHOULD 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.

>            configurations.  Support for "rollback on error" semantics
Gert> support
>
>
>Thanks,
>Rob
>
>
>> FWIW, the other requirements docs listed above also use "MAY" in some
>>of their ³requirements"
>>
>>
>> Kent
>>
>>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 15 Jan 2016 22:40:53 +0000

[As a contributor]

And just when I thought we were done with this draft  ;)

>>            a client-specified per-operation basis.

This does seem better, thanks for the suggestion.  I view this as an editorial fix.

>>            difference between the intended and applied configurations.

I agree with Gert on this one - and it is what I told Benoit I would do...

My observation that the “difference” could be as simple as a flag or as complex as an actual diff.   When considering the former, there is no need for an addition verify option when a synchronous call is made, whereas a verify option *would* be useful when an asynchronous call is made.   That said, when considering the latter, it seems that a verify option would always be useful.

Being conservative, I choose to believe that “difference" has the simplest meaning and hence conclude that the SHOULD only applies to servers that support asynchronous configuration operations.  This doesn’t mean that a solution can always provide a verify operation, of course, and if the result includes an actual diff, it’s value will be understood as being generally useful.  Makes sense?

>>            configurations.  Support for "rollback on error" semantics

This does seem better than the s/MAY/may/ I proposed to Benoit.  

The important thing to me is that there is still a lot of leeway in the "handled by semantics similar to” clause.  It’s just saying that the client SHOULD have some control over error handling, which I think is still in keeping with the original phrasing of the requirement.   So I view this as another editorial fix.

Thanks,

Kent

---

From: Nadeau Thomas <[email-masked]>
Date: Fri, 15 Jan 2016 17:52:20 -0500

> On Jan 15, 2016:5:40 PM, at 5:40 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> [As a contributor]
> 
> 

	That seems reasonable. I agree its editorial.

	—Tom

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Jan 2016 23:36:55 +0000

> slightly (SHOULD instead of MAY):
As well as rollback-on-error, synchronous operations can still be 
continue-on-error or stop-on-error.

Under both of these semantics it is possible for the system to be left 
in a state where some of the applied config leaves do not match the 
intended config leaves. The "verify operation" is useful in this 
scenario, hence why I still think that it would be better to remove the 
condition tying the requirement to only asynchronous operations.  It is 
just a generally useful operation for opstate compliant devices.

Rob