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

[Andy Bierman]

On Fri, Jan 15, 2016 at 9:24 AM, Robert Wilton  wrote:

> Hi Kent,
>
> On 11/01/2016 20:59, Kent Watsen wrote:
>
>> Hi Benoit,
>>
>>
>> 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.
>>>
>> 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.)...
>>
>>
>> Btw, I never quite understood what a MAY means for a requirement.
>>> See requirement 2B and 2C
>>>
>> For 2B, would you rather is be a SHOULD?
>> 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.
>
>


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:
>
>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 
>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 
>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
>
>
> FWIW, the other requirements docs listed above also use "MAY" in some of
>> their “requirements"
>>
>>
>> Kent
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> 

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

[Robert Wilton]

Hi Kent,

On 11/01/2016 20:59, Kent Watsen wrote:

Hi Benoit,



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.

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.)...



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

For 2B, would you rather is be a SHOULD?
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 
   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 
   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



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


Kent


___
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

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

[Gert Grammel]

See below ..

On 2016-15-01 18:24, "netmod on behalf of Robert Wilton"
 wrote:

>Hi Kent,
>
>On 11/01/2016 20:59, Kent Watsen wrote:
>> Hi Benoit,
>>
>>
>>> 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.
>> 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.)...
>>
>>
>>> Btw, I never quite understood what a MAY means for a requirement.
>>> See requirement 2B and 2C
>> For 2B, would you rather is be a SHOULD?
>> 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.
Gert> support
>
>
>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.
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.


>
>
>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 
>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 
>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.
Gert> support
>
>
>Thanks,
>Rob
>
>
>> FWIW, the other requirements docs listed above also use "MAY" in some
>>of their ³requirements"
>>
>>
>> Kent
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>___
>netmod mailing list
>netmod@ietf.org

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

[Kent Watsen]

[As a contributor]


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







>>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.
>Gert> support

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




>>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.
>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.
>>
>>
>>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.


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?


>>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 
>>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 
>>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.
>Gert> support

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

On 15/01/2016 20:50, Gert Grammel wrote:




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.

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):
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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Nadeau Thomas]

> On Jan 15, 2016:5:40 PM, at 5:40 PM, Kent Watsen  wrote:
> 
> 
> [As a contributor]
> 
> 
> And just when I thought we were done with this draft  ;)
> 
> 
> 
> 
> 
> 
> 
>>> 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.
>> Gert> support
> 
> This does seem better, thanks for the suggestion.  I view this as an 
> editorial fix.

That seems reasonable. I agree its editorial.

—Tom


> 
> 
> 
> 
>>> 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.
>> 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.
>>> 
>>> 
>>> 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.
> 
> 
> 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?
> 
> 
>>> 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 
>>>   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 
>>>   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.
>> Gert> support
> 
> 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 
> 

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

[Juergen Schoenwaelder]

On Tue, Jan 12, 2016 at 04:23:36PM -0500, Nadeau Thomas wrote:
> 
> 
>   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.

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

[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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

Hi Benoit,


>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.

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.)...


>Btw, I never quite understood what a MAY means for a requirement.
>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


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Sat, Jan 09, 2016 at 01:00:34AM +, Kent Watsen wrote:
> 
> 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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

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 internet-dra...@ietf.org" 
 wrote:

>
>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/
>
>___
>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