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

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

[internet-drafts]

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

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

[Kent Watsen]

[As a contributor]

As I count it, there are four in favor and two not in favor of the title 
proposed by Robert, so I’m going to post -03 with that one.

Kent



On 1/8/16, 9:26 AM, "netmod on behalf of Ladislav Lhotka" 
 wrote:

>
>> On 08 Jan 2016, at 14:46, Acee Lindem (acee)  wrote:
>> 
>> 
>> 
>> On 1/8/16, 7:47 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>> 
>>> Juergen Schoenwaelder  writes:
>>> 
 On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote:
> Hi Juergen,
> 
> On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
>> On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
>>> It’s true that the draft is largely centered around the
>>> intended/applied config notion, but not exclusively.  Specifically,
> 4-B 
>>> has "Ability to map intended config nodes to associated derived
> state 
>>> nodes".  I think that this might be the only exclusion though and,
> if it 
>>> weren’t for it I would’ve used your title suggestion from the LC
>>> review.   Should one requirement have such influence over the title
> is 
>>> the question.  I was trying to be fair to it, but maybe it's going
> too 
>>> far.
>>> 
>>> Regarding visibility and control, I was attempting to use common
> words 
>>> (not normative terms) here.  My intent for them is something along
> the 
>>> lines of:
>>> 
>>> visibility: read/understand
>>> control: write/orchestrate
>>> 
>> We do not write operational state. I have no clue how 'orchestrate'
>> helps me either. What is wrong with using defined terminology in
>> a title?
> I don't think that using defined terminology is a problem.  But I also
> think that the title that you have suggested seems to suggest a
> narrower 
> scope that what the requirements articulate.
> 
> In particular, the draft places requirements relating the
> configuration 
> to the derived state (I.e. Req 4B).
> 
> It also places further requirements on how management protocols are
> expected to handle synchronous and asynchronous config edit requests.
> (E.g. Req 2 A, B, C and associated definitions).
 
 Note that synchronous and asynchronous are defined in terms of
 intended / applied configuration.
 
> I don't have a particular problem with the current title, but if you
> don't like visibility/control, then perhaps "Terminology and
> Requirements for Enhanced Handling of Operational State"?
 
 Better but I still think this proposal is too broad given the content
 of the document. I still believe my proposal is right to the point.
>>> 
>>> +1
>>> 
>>> The draft talks about introducing applied configuration and its
>>> relationship to state data and intended configuration (which, I believe,
>>> is the good old "running"). I don't see any enhanced handling of
>>> operational state.
>> 
>> The draft is quite succinct and I’m not sure how you and Juergen do not
>> agree that there are requirements beyond intended/applied state. Perhaps
>> you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
>> For your convenience, I’ve excerpted them below:
>> 
>
>Well, opstate-reqs defines applied configuration and *proclaims* it to be a 
>part of operational state, whereas it is a new artefact that has to do with 
>how the server processes configuration.
>
>With two exceptions commented on below, the requirements really are directly 
>related to the introduction of applied configuration.
>
>In other words: for those who don't want to use applied configuration, there 
>is very little benefit in terms of enhanced handling of operational state.
> 
>> 
>>   3.  Separation of the applied configuration and derived state aspects
>>   of operational state; ability to retrieve them independently and
>>   together
>> 
>>   A.  Be able to retrieve only the applied configuration aspects of
>>   operational state
>> 
>>   B.  Be able to retrieve only the derived state aspects of
>>   operational state
>
>Yes, the inability to retrieve state data separately is a known shortcoming of 
>NETCONF, and Andy proposed a solution long ago. RESTCONF has this function out 
>of the box.
>
>> 
>>   C.  Be able to retrieve both the applied configuration and
>>   derived state aspects of operational state together
>> 
>>   4.  Ability to relate configuration with its corresponding
>>   operational state
>> 
>>   A.  Ability to map intended config nodes to corresponding applied
>>   config nodes
>> 
>>   B.  Ability to map intended config nodes to associated derived
>>   state nodes
>
>This might be useful but I think it will only have a limited value because it 
>can't capture all possible semantics of such associations. For example, we can 
>indicate in the data model that static routes are associated with RIBs, but

Re: [netmod] applied configuration and system-controlled entries

[Robert Wilton]

On 08/01/2016 15:42, Ladislav Lhotka wrote:

On 08 Jan 2016, at 16:20, Robert Wilton  wrote:

Hi Lada,

On 08/01/2016 12:30, Ladislav Lhotka wrote:

Robert Wilton  writes:


Hi Lada,

I think that requirement 1D is fairly key to what is being asked for
here to allow both the user and system to easily relate between what the
operator desires and what configuration the system is actually using,

In a way, system-controlled interfaces are default entries in the
interface list - and the system can certainly be using interfaces with
no configuration installed by NETCONF/RESTCONF clients.


so I wouldn't be particularly keen on loosening this requirement.

OK, but then IMO this intended-applied dualism is of limited
utility. For many systems or services, asynchronicity is not an option,
or isn't important.

I don't really agree.   I think that this is plausibly important to anyone who 
wants to manage network devices in an automated way.

I am currently working with my colleagues on two use cases:

1. RESTCONF interface to a DNS server that will cover the daemon configuration, 
policies for zone signing, and zone provisioning.

2. RESTCONF interface to an OpenWRT-based router.

For neither of them applied configuration seems to add any value.

OK.




Today, when a config request has been processed by NETCONF/YANG then it seems 
that the only thing the server actually promises is that it might apply the 
configuration at some point in the future.  It makes no guarantees as to 
whether that configuration has or ever

The server may simply send a reply only after the configuration has been 
completely applied.
Yes, the server may do this.  But the client cannot rely on that 
behaviour for a NETCONF server today.


When I first got involved in the opstate discussions, I mistakenly 
thought that when a NETCONF server replies to a request it mean that the 
configuration was applied (for some definition of applied). From my 
reading of draft-openconfig-netmod-opstate-01 section 4.2, I suspect 
that the authors were also under that impression.  However, several 
folks on the WG alias have made it clear that this behaviour is not 
specified by the NETCONF draft.


But the nice thing is, if the server complies with the opstate 
requirements draft, then when the client receives a successful reply to 
the synchronous configuration request it knows that configuration has 
actually been applied successfully.  It seems to me that these are the 
semantics that your client code probably desires.


Alternatively, perhaps the client code doesn't directly care whether or 
not the configuration has been successfully applied because it will 
infer it from the operational state.  In this case it can make async 
requests, with the knowledge that any server should reply to the config 
request reasonably expediently.


From a client perspective, either of these two requests seem to be 
better than the status quo, where it can infer very little from the 
result of a request.  Two different server implementations may have very 
different behaviour and hence a robust client has to be coded to assume 
the least desirable behaviour.



  I understand that with complex devices it is not possible or practical to 
wait, but in my use cases it is probably just the right thing to do.
For me, it is about what a client can reasonably assume about the 
servers behaviour, and I think that the tighter behaviour specified in 
the opstate requirements means that servers should behave how clients 
expect them to.





  will be successfully applied!  The expectation is that the operator can infer 
from the operational state of the system whether the configuration has been 
applied (which may not always be possible).

Personally, if I was an operator coding to NETCONF/YANG then I would prefer a 
device that supported the opstate semantics because compliant devices will tell 
you what configuration that are actually running.  This makes it easier to 
control/manage.  I.e. I can easily find out if/when my configuration is 
applied, and I can easily retrieve any associated operational state.  In some 
cases this may mean that I don't need to check the derived state at all, in 
other cases it may simplify the checking of the derived state that I need to 
perform.

Again, regarding sync/async, I would also most likely choose async because I 
perceive that it is simpler to code in a robust fashion.


For the ACL example:
Would it be feasible to change the ACL module to use a leafref to the
interface name, with the added constraint that you have to at least
configure the existence of an interface before you can have any
configuration referring to it?

Well, yes, that's how it is supposed to be done now - also, for example,
for stacking interfaces as in Appendix B of RFC 7223.

It is not only extra work: the interface list can be locked, so it may
not be possible to immediately create a dummy interface entry and,
consequently, an ACL rule with that interface c

Re: [netmod] applied configuration and system-controlled entries

[Ladislav Lhotka]

> On 08 Jan 2016, at 16:20, Robert Wilton  wrote:
> 
> Hi Lada,
> 
> On 08/01/2016 12:30, Ladislav Lhotka wrote:
>> Robert Wilton  writes:
>> 
>>> Hi Lada,
>>> 
>>> I think that requirement 1D is fairly key to what is being asked for
>>> here to allow both the user and system to easily relate between what the
>>> operator desires and what configuration the system is actually using,
>> In a way, system-controlled interfaces are default entries in the
>> interface list - and the system can certainly be using interfaces with
>> no configuration installed by NETCONF/RESTCONF clients.
>> 
>>> so I wouldn't be particularly keen on loosening this requirement.
>> OK, but then IMO this intended-applied dualism is of limited
>> utility. For many systems or services, asynchronicity is not an option,
>> or isn't important.
> I don't really agree.   I think that this is plausibly important to anyone 
> who wants to manage network devices in an automated way.

I am currently working with my colleagues on two use cases:

1. RESTCONF interface to a DNS server that will cover the daemon configuration, 
policies for zone signing, and zone provisioning.

2. RESTCONF interface to an OpenWRT-based router.

For neither of them applied configuration seems to add any value.

> 
> Today, when a config request has been processed by NETCONF/YANG then it seems 
> that the only thing the server actually promises is that it might apply the 
> configuration at some point in the future.  It makes no guarantees as to 
> whether that configuration has or ever

The server may simply send a reply only after the configuration has been 
completely applied. I understand that with complex devices it is not possible 
or practical to wait, but in my use cases it is probably just the right thing 
to do.

>  will be successfully applied!  The expectation is that the operator can 
> infer from the operational state of the system whether the configuration has 
> been applied (which may not always be possible).
> 
> Personally, if I was an operator coding to NETCONF/YANG then I would prefer a 
> device that supported the opstate semantics because compliant devices will 
> tell you what configuration that are actually running.  This makes it easier 
> to control/manage.  I.e. I can easily find out if/when my configuration is 
> applied, and I can easily retrieve any associated operational state.  In some 
> cases this may mean that I don't need to check the derived state at all, in 
> other cases it may simplify the checking of the derived state that I need to 
> perform.
> 
> Again, regarding sync/async, I would also most likely choose async because I 
> perceive that it is simpler to code in a robust fashion.
> 
>> 
>>> For the ACL example:
>>> Would it be feasible to change the ACL module to use a leafref to the
>>> interface name, with the added constraint that you have to at least
>>> configure the existence of an interface before you can have any
>>> configuration referring to it?
>> Well, yes, that's how it is supposed to be done now - also, for example,
>> for stacking interfaces as in Appendix B of RFC 7223.
>> 
>> It is not only extra work: the interface list can be locked, so it may
>> not be possible to immediately create a dummy interface entry and,
>> consequently, an ACL rule with that interface cannot be configured. In
>> this sense, using a string rather than a leafref looks like a reasonable
>> choice.
> Locking is presumably specifically related to the config protocol being used. 
>  As such I don't think that it should be used as a reason to compromise the 
> structure of data model.
> 
> But having looked at the ACL model a bit more closely, and noticing how 
> input_interface is used, then I agree with Martin, I think that it makes 
> sense for the reference to be an interface-state-ref.
> 
>> 
>> As Martin pointed out, with YANG 1.1 it would be possible to refer to an
>> interface entry in state data from configuration. On the other hand,
>> with "require-instance false" validation won't detect errors in ACL
>> configuration such as referring to a non-existent interface.
> True, but for this particular scenario, it wouldn't be any different from 
> matching on the wrong IP address (which also can't be validated by the device 
> in question).

Sure, but my point is that a leafref with require-instance=false isn't that 
much different from a plain string.

Lada

> 
> Presumably the ACL is still valid even if the input-interface for one ACE 
> doesn't exist. Wouldn't it just mean that one particular ACE entry wouldn't 
> match any packets?
> 
> Thanks,
> Rob
> 
> 
>> 
>> Lada
>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
>>> On 07/01/2016 10:20, Ladislav Lhotka wrote:
 Hi,
 
 a good use of applied configuration could be to formalize the concept of 
 system-controlled entries as defined in RFC 7223, routing-cfg, and 
 probably elsewhere, too.
 
 My idea is that system-controlled interfaces or other entries would appea

Re: [netmod] applied configuration and system-controlled entries

[Robert Wilton]

Hi Lada,

On 08/01/2016 12:30, Ladislav Lhotka wrote:

Robert Wilton  writes:


Hi Lada,

I think that requirement 1D is fairly key to what is being asked for
here to allow both the user and system to easily relate between what the
operator desires and what configuration the system is actually using,

In a way, system-controlled interfaces are default entries in the
interface list - and the system can certainly be using interfaces with
no configuration installed by NETCONF/RESTCONF clients.


so I wouldn't be particularly keen on loosening this requirement.

OK, but then IMO this intended-applied dualism is of limited
utility. For many systems or services, asynchronicity is not an option,
or isn't important.
I don't really agree.   I think that this is plausibly important to 
anyone who wants to manage network devices in an automated way.


Today, when a config request has been processed by NETCONF/YANG then it 
seems that the only thing the server actually promises is that it might 
apply the configuration at some point in the future.  It makes no 
guarantees as to whether that configuration has or ever will be 
successfully applied!  The expectation is that the operator can infer 
from the operational state of the system whether the configuration has 
been applied (which may not always be possible).


Personally, if I was an operator coding to NETCONF/YANG then I would 
prefer a device that supported the opstate semantics because compliant 
devices will tell you what configuration that are actually running.  
This makes it easier to control/manage.  I.e. I can easily find out 
if/when my configuration is applied, and I can easily retrieve any 
associated operational state.  In some cases this may mean that I don't 
need to check the derived state at all, in other cases it may simplify 
the checking of the derived state that I need to perform.


Again, regarding sync/async, I would also most likely choose async 
because I perceive that it is simpler to code in a robust fashion.





For the ACL example:
Would it be feasible to change the ACL module to use a leafref to the
interface name, with the added constraint that you have to at least
configure the existence of an interface before you can have any
configuration referring to it?

Well, yes, that's how it is supposed to be done now - also, for example,
for stacking interfaces as in Appendix B of RFC 7223.

It is not only extra work: the interface list can be locked, so it may
not be possible to immediately create a dummy interface entry and,
consequently, an ACL rule with that interface cannot be configured. In
this sense, using a string rather than a leafref looks like a reasonable
choice.
Locking is presumably specifically related to the config protocol being 
used.  As such I don't think that it should be used as a reason to 
compromise the structure of data model.


But having looked at the ACL model a bit more closely, and noticing how 
input_interface is used, then I agree with Martin, I think that it makes 
sense for the reference to be an interface-state-ref.




As Martin pointed out, with YANG 1.1 it would be possible to refer to an
interface entry in state data from configuration. On the other hand,
with "require-instance false" validation won't detect errors in ACL
configuration such as referring to a non-existent interface.
True, but for this particular scenario, it wouldn't be any different 
from matching on the wrong IP address (which also can't be validated by 
the device in question).


Presumably the ACL is still valid even if the input-interface for one 
ACE doesn't exist.  Wouldn't it just mean that one particular ACE entry 
wouldn't match any packets?


Thanks,
Rob




Lada


Thanks,
Rob


On 07/01/2016 10:20, Ladislav Lhotka wrote:

Hi,

a good use of applied configuration could be to formalize the concept of 
system-controlled entries as defined in RFC 7223, routing-cfg, and probably 
elsewhere, too.

My idea is that system-controlled interfaces or other entries would appear in 
applied configuration, but not in intended configuration until something needs 
to be really configured. We could then permit leafrefs from intended 
configuration to refer to leafs in applied configuration. One case where this 
would be useful is the ACL module, where match conditions refering to 
interfaces currently have to use plain strings as references to interface names.

However, the above idea seems to be at odds with requirement 1D in 
opstate-reqs-02. I wonder: could that requirement be relaxed or removed so that 
the above use case can be supported?

Thanks, Lada

--

Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
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] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Juergen Schoenwaelder]

On Fri, Jan 08, 2016 at 02:10:20PM +0100, Ladislav Lhotka wrote:
> 
> > On 08 Jan 2016, at 13:57, Acee Lindem (acee)  wrote:
> > 
> > Hi Martin, et al, 
> > 
> > On 1/8/16, 2:54 AM, "Martin Bjorklund"  wrote:
> > 
> >> Hi,
> >> 
> >> "Acee Lindem (acee)"  wrote:
> >>> 
> >>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
> >>>  wrote:
> >>> 
>  
> > On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
> > 
> > 
> > 
> > 
> > 
> > 
> > On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
> >  wrote:
> > 
> >> 
> >>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
> >>>  wrote:
> >>> 
> >>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
> >>> 
>  I hope that nobody disagrees that the operational state design and
>  how 
>  to structure the models are the two blocking factors to publish
> >>> YANG
>  models. If you disagree or don't see this, let me know, I should
>  communicate better.
> >>> 
> >>> Even if it may spoil your day, I disagree that there is a blocking
> >>> factor that should stop us from publishing models. There seem to be
> >>> ways to address the requirements without having to block all work
> >>> or
> >>> to redo what that we have published. But sure, if you make it a
> >>> blocking factor, it will be one.
> >> 
> >> I agree with Juergen. It is not clear to me how the proposed split
> >> between intended and applied configuration is supposed to affect the
> >> data models we are working on.
> > 
> > 
> > As I understand it, solution #1 affects the models themselves,
> >>> whereas
> > solutions #2 and #3 are transparent to the models.
>  
>  Then #1 looks like a non-starter to me.
> >>> 
> >>> I’d like to point out that we also have the requirement to allow
> >>> retrieval
> >>> of derived-state along with intended-config and applied-config. This
> >>> will
> >>> require modification to most of the existing YANG drafts as most now
> >>> have
> >>> separate trees for config and operational state.
> >> 
> >> I don't agree with the conclusion that changes are needed due to this
> >> requirement.
> >> 
> >> Solution #1 ("openconfig") requires changes to handle applied config.
> >> Solution #2 ("kent's") does not.
> >> 
> >> Both solutions #1 and #2 use separate nodes for derived state.
> >> 
> >> It might appear as #1 and #2 are very different in their handling of
> >> derived state, since #1 put all config false nodes directly under the
> >> config true nodes, whereas #2 in some cases have a top-level
> >> "xxx-state" config false node.
> >> 
> >> But in fact #2 allows the solution in #1 as one special case.  The
> >> reason that RFC 7223 has a separate list for derived state interfaces
> >> is to allow for non-configured interfaces to be monitored.  If this
> >> was not a requirement, all config false nodes could (would) have been
> >> defined in the config true interface list.
> > 
> > I see that this is discussed in the latest version of
> > draft-ietf-netmod-rfc6087bis-05.txt and that it is “appropriate" to put
> > the operational state in the same subtree as the config state if it would
> > not exist if not configured. Is “appropriate” a recommendation?
> > 
> >   Careful consideration needs to be given to the location of
> >   operational state data.  It can either be located within the
> >   configuration subtree for which it applies, or it can be located
> >   outside the particular configuration subtree.  Placing operation
> >   state within the configuration subtree is appropriate if the
> >   operational values can only exist if the configuration exists.
> > 
> > 
> > However, we currently have many YANG models in progress where the config
> > and state trees are separate subtrees. If we all agree with the opstate
> > requirement for derived state, perhaps it is time to get the word out and
> > modify these models.
> 
> I don't think that we all agree. :-)

+1

And in many cases, state can exist without config being present. It
would be truely backwards if systems would start to hide operational
state in order to comply to some new overarching rules to make work
with operational state 'easier'.

/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-02.txt

[Ladislav Lhotka]

> On 08 Jan 2016, at 14:46, Acee Lindem (acee)  wrote:
> 
> 
> 
> On 1/8/16, 7:47 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
> 
>> Juergen Schoenwaelder  writes:
>> 
>>> On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote:
 Hi Juergen,
 
 On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
> On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
>> It’s true that the draft is largely centered around the
>> intended/applied config notion, but not exclusively.  Specifically,
 4-B 
>> has "Ability to map intended config nodes to associated derived
 state 
>> nodes".  I think that this might be the only exclusion though and,
 if it 
>> weren’t for it I would’ve used your title suggestion from the LC
>> review.   Should one requirement have such influence over the title
 is 
>> the question.  I was trying to be fair to it, but maybe it's going
 too 
>> far.
>> 
>> Regarding visibility and control, I was attempting to use common
 words 
>> (not normative terms) here.  My intent for them is something along
 the 
>> lines of:
>> 
>>  visibility: read/understand
>>  control: write/orchestrate
>> 
> We do not write operational state. I have no clue how 'orchestrate'
> helps me either. What is wrong with using defined terminology in
> a title?
 I don't think that using defined terminology is a problem.  But I also
 think that the title that you have suggested seems to suggest a
 narrower 
 scope that what the requirements articulate.
 
 In particular, the draft places requirements relating the
 configuration 
 to the derived state (I.e. Req 4B).
 
 It also places further requirements on how management protocols are
 expected to handle synchronous and asynchronous config edit requests.
 (E.g. Req 2 A, B, C and associated definitions).
>>> 
>>> Note that synchronous and asynchronous are defined in terms of
>>> intended / applied configuration.
>>> 
 I don't have a particular problem with the current title, but if you
 don't like visibility/control, then perhaps "Terminology and
 Requirements for Enhanced Handling of Operational State"?
>>> 
>>> Better but I still think this proposal is too broad given the content
>>> of the document. I still believe my proposal is right to the point.
>> 
>> +1
>> 
>> The draft talks about introducing applied configuration and its
>> relationship to state data and intended configuration (which, I believe,
>> is the good old "running"). I don't see any enhanced handling of
>> operational state.
> 
> The draft is quite succinct and I’m not sure how you and Juergen do not
> agree that there are requirements beyond intended/applied state. Perhaps
> you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
> For your convenience, I’ve excerpted them below:
> 

Well, opstate-reqs defines applied configuration and *proclaims* it to be a 
part of operational state, whereas it is a new artefact that has to do with how 
the server processes configuration.

With two exceptions commented on below, the requirements really are directly 
related to the introduction of applied configuration.

In other words: for those who don't want to use applied configuration, there is 
very little benefit in terms of enhanced handling of operational state.
 
> 
>   3.  Separation of the applied configuration and derived state aspects
>   of operational state; ability to retrieve them independently and
>   together
> 
>   A.  Be able to retrieve only the applied configuration aspects of
>   operational state
> 
>   B.  Be able to retrieve only the derived state aspects of
>   operational state

Yes, the inability to retrieve state data separately is a known shortcoming of 
NETCONF, and Andy proposed a solution long ago. RESTCONF has this function out 
of the box.

> 
>   C.  Be able to retrieve both the applied configuration and
>   derived state aspects of operational state together
> 
>   4.  Ability to relate configuration with its corresponding
>   operational state
> 
>   A.  Ability to map intended config nodes to corresponding applied
>   config nodes
> 
>   B.  Ability to map intended config nodes to associated derived
>   state nodes

This might be useful but I think it will only have a limited value because it 
can't capture all possible semantics of such associations. For example, we can 
indicate in the data model that static routes are associated with RIBs, but it 
won't be possible to specify how (formally). 

Lada


> 
>   C.  The mappings needs to be programmatically consumable
> 
> 
> Thanks,
> Acee 
> 
> 
>> 
>> Lada
>> 
>>> 
>>> /js
>>> 
>>> -- 
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200

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

[Acee Lindem (acee)]

On 1/8/16, 7:47 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>Juergen Schoenwaelder  writes:
>
>> On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote:
>>> Hi Juergen,
>>> 
>>> On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
>>> >On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
>>> >>It’s true that the draft is largely centered around the
>>> >>intended/applied config notion, but not exclusively.  Specifically,
>>>4-B 
>>> >>has "Ability to map intended config nodes to associated derived
>>>state 
>>> >>nodes".  I think that this might be the only exclusion though and,
>>>if it 
>>> >>weren’t for it I would’ve used your title suggestion from the LC
>>> >>review.   Should one requirement have such influence over the title
>>>is 
>>> >>the question.  I was trying to be fair to it, but maybe it's going
>>>too 
>>> >>far.
>>> >>
>>> >>Regarding visibility and control, I was attempting to use common
>>>words 
>>> >>(not normative terms) here.  My intent for them is something along
>>>the 
>>> >>lines of:
>>> >>
>>> >>  visibility: read/understand
>>> >>  control: write/orchestrate
>>> >>
>>> >We do not write operational state. I have no clue how 'orchestrate'
>>> >helps me either. What is wrong with using defined terminology in
>>> >a title?
>>> I don't think that using defined terminology is a problem.  But I also
>>> think that the title that you have suggested seems to suggest a
>>>narrower 
>>> scope that what the requirements articulate.
>>> 
>>> In particular, the draft places requirements relating the
>>>configuration 
>>> to the derived state (I.e. Req 4B).
>>> 
>>> It also places further requirements on how management protocols are
>>> expected to handle synchronous and asynchronous config edit requests.
>>> (E.g. Req 2 A, B, C and associated definitions).
>>
>> Note that synchronous and asynchronous are defined in terms of
>> intended / applied configuration.
>>  
>>> I don't have a particular problem with the current title, but if you
>>> don't like visibility/control, then perhaps "Terminology and
>>> Requirements for Enhanced Handling of Operational State"?
>>
>> Better but I still think this proposal is too broad given the content
>> of the document. I still believe my proposal is right to the point.
>
>+1
>
>The draft talks about introducing applied configuration and its
>relationship to state data and intended configuration (which, I believe,
>is the good old "running"). I don't see any enhanced handling of
>operational state.

The draft is quite succinct and I’m not sure how you and Juergen do not
agree that there are requirements beyond intended/applied state. Perhaps
you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
For your convenience, I’ve excerpted them below:


   3.  Separation of the applied configuration and derived state aspects
   of operational state; ability to retrieve them independently and
   together

   A.  Be able to retrieve only the applied configuration aspects of
   operational state

   B.  Be able to retrieve only the derived state aspects of
   operational state

   C.  Be able to retrieve both the applied configuration and
   derived state aspects of operational state together

   4.  Ability to relate configuration with its corresponding
   operational state

   A.  Ability to map intended config nodes to corresponding applied
   config nodes

   B.  Ability to map intended config nodes to associated derived
   state nodes

   C.  The mappings needs to be programmatically consumable


Thanks,
Acee 


>
>Lada
>
>>
>> /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
>
>-- 
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>___
>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-02.txt

[Ladislav Lhotka]

> On 08 Jan 2016, at 14:17, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> 
>>> On 08 Jan 2016, at 13:53, Martin Bjorklund  wrote:
>>> 
>>> Ladislav Lhotka  wrote:
 Juergen Schoenwaelder  writes:
 
> On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote:
>> Hi Juergen,
>> 
>> On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
>>> On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
 It’s true that the draft is largely centered around the 
 intended/applied config notion, but not exclusively.  Specifically,
 4-B
 has "Ability to map intended config nodes to associated derived state 
 nodes".  I think that this might be the only exclusion though and, if
 it
 weren’t for it I would’ve used your title suggestion from the LC 
 review.  Should one requirement have such influence over the title is
 the question.  I was trying to be fair to it, but maybe it's going too
 far.
 
 Regarding visibility and control, I was attempting to use common words
 (not normative terms) here.  My intent for them is something along the
 lines of:
 
visibility: read/understand
control: write/orchestrate
 
>>> We do not write operational state. I have no clue how 'orchestrate'
>>> helps me either. What is wrong with using defined terminology in
>>> a title?
>> I don't think that using defined terminology is a problem.  But I also
>> think that the title that you have suggested seems to suggest a
>> narrower
>> scope that what the requirements articulate.
>> 
>> In particular, the draft places requirements relating the
>> configuration
>> to the derived state (I.e. Req 4B).
>> 
>> It also places further requirements on how management protocols are 
>> expected to handle synchronous and asynchronous config edit requests. 
>> (E.g. Req 2 A, B, C and associated definitions).
> 
> Note that synchronous and asynchronous are defined in terms of
> intended / applied configuration.
> 
>> I don't have a particular problem with the current title, but if you 
>> don't like visibility/control, then perhaps "Terminology and 
>> Requirements for Enhanced Handling of Operational State"?
> 
> Better but I still think this proposal is too broad given the content
> of the document. I still believe my proposal is right to the point.
 
 +1
 
 The draft talks about introducing applied configuration and its
 relationship to state data and intended configuration (which, I
 believe,
 is the good old "running"). I don't see any enhanced handling of
 operational state.
>>> 
>>> Well, the applied config is part of the operational state, and there
>> 
>> According to 6020bis, state data are tagged with "config false" in
>> YANG modules. I don't think it is going to be the case of applied
>> configuration.
> 
> Right; but this term "state data" is more like the new term "derived
> state" (which I think is a bit unfortunate - derived from what?)

For me, operational state exists independently of management interfaces, 
applied configuration doesn't - it is an artefact.

Lada

> 
> 
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

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

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 08 Jan 2016, at 13:53, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> Juergen Schoenwaelder  writes:
> >> 
> >>> On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote:
>  Hi Juergen,
>  
>  On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
> > On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
> >> It’s true that the draft is largely centered around the 
> >> intended/applied config notion, but not exclusively.  Specifically,
> >> 4-B
> >> has "Ability to map intended config nodes to associated derived state 
> >> nodes".  I think that this might be the only exclusion though and, if
> >> it
> >> weren’t for it I would’ve used your title suggestion from the LC 
> >> review.  Should one requirement have such influence over the title is
> >> the question.  I was trying to be fair to it, but maybe it's going too
> >> far.
> >> 
> >> Regarding visibility and control, I was attempting to use common words
> >> (not normative terms) here.  My intent for them is something along the
> >> lines of:
> >> 
> >>visibility: read/understand
> >>control: write/orchestrate
> >> 
> > We do not write operational state. I have no clue how 'orchestrate'
> > helps me either. What is wrong with using defined terminology in
> > a title?
>  I don't think that using defined terminology is a problem.  But I also
>  think that the title that you have suggested seems to suggest a
>  narrower
>  scope that what the requirements articulate.
>  
>  In particular, the draft places requirements relating the
>  configuration
>  to the derived state (I.e. Req 4B).
>  
>  It also places further requirements on how management protocols are 
>  expected to handle synchronous and asynchronous config edit requests. 
>  (E.g. Req 2 A, B, C and associated definitions).
> >>> 
> >>> Note that synchronous and asynchronous are defined in terms of
> >>> intended / applied configuration.
> >>> 
>  I don't have a particular problem with the current title, but if you 
>  don't like visibility/control, then perhaps "Terminology and 
>  Requirements for Enhanced Handling of Operational State"?
> >>> 
> >>> Better but I still think this proposal is too broad given the content
> >>> of the document. I still believe my proposal is right to the point.
> >> 
> >> +1
> >> 
> >> The draft talks about introducing applied configuration and its
> >> relationship to state data and intended configuration (which, I
> >> believe,
> >> is the good old "running"). I don't see any enhanced handling of
> >> operational state.
> > 
> > Well, the applied config is part of the operational state, and there
> 
> According to 6020bis, state data are tagged with "config false" in
> YANG modules. I don't think it is going to be the case of applied
> configuration.

Right; but this term "state data" is more like the new term "derived
state" (which I think is a bit unfortunate - derived from what?)


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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 08 Jan 2016, at 13:57, Acee Lindem (acee)  wrote:
> 
> Hi Martin, et al, 
> 
> On 1/8/16, 2:54 AM, "Martin Bjorklund"  wrote:
> 
>> Hi,
>> 
>> "Acee Lindem (acee)"  wrote:
>>> 
>>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>> 
 
> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
> 
> 
> 
> 
> 
> 
> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
> 
>> 
>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>  wrote:
>>> 
>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>> 
 I hope that nobody disagrees that the operational state design and
 how 
 to structure the models are the two blocking factors to publish
>>> YANG
 models. If you disagree or don't see this, let me know, I should
 communicate better.
>>> 
>>> Even if it may spoil your day, I disagree that there is a blocking
>>> factor that should stop us from publishing models. There seem to be
>>> ways to address the requirements without having to block all work
>>> or
>>> to redo what that we have published. But sure, if you make it a
>>> blocking factor, it will be one.
>> 
>> I agree with Juergen. It is not clear to me how the proposed split
>> between intended and applied configuration is supposed to affect the
>> data models we are working on.
> 
> 
> As I understand it, solution #1 affects the models themselves,
>>> whereas
> solutions #2 and #3 are transparent to the models.
 
 Then #1 looks like a non-starter to me.
>>> 
>>> I’d like to point out that we also have the requirement to allow
>>> retrieval
>>> of derived-state along with intended-config and applied-config. This
>>> will
>>> require modification to most of the existing YANG drafts as most now
>>> have
>>> separate trees for config and operational state.
>> 
>> I don't agree with the conclusion that changes are needed due to this
>> requirement.
>> 
>> Solution #1 ("openconfig") requires changes to handle applied config.
>> Solution #2 ("kent's") does not.
>> 
>> Both solutions #1 and #2 use separate nodes for derived state.
>> 
>> It might appear as #1 and #2 are very different in their handling of
>> derived state, since #1 put all config false nodes directly under the
>> config true nodes, whereas #2 in some cases have a top-level
>> "xxx-state" config false node.
>> 
>> But in fact #2 allows the solution in #1 as one special case.  The
>> reason that RFC 7223 has a separate list for derived state interfaces
>> is to allow for non-configured interfaces to be monitored.  If this
>> was not a requirement, all config false nodes could (would) have been
>> defined in the config true interface list.
> 
> I see that this is discussed in the latest version of
> draft-ietf-netmod-rfc6087bis-05.txt and that it is “appropriate" to put
> the operational state in the same subtree as the config state if it would
> not exist if not configured. Is “appropriate” a recommendation?
> 
>   Careful consideration needs to be given to the location of
>   operational state data.  It can either be located within the
>   configuration subtree for which it applies, or it can be located
>   outside the particular configuration subtree.  Placing operation
>   state within the configuration subtree is appropriate if the
>   operational values can only exist if the configuration exists.
> 
> 
> However, we currently have many YANG models in progress where the config
> and state trees are separate subtrees. If we all agree with the opstate
> requirement for derived state, perhaps it is time to get the word out and
> modify these models.

I don't think that we all agree. :-)

Lada

> 
> Thanks,
> Acee 
> 
> 
> 
>> 
>> 
>> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

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

[Ladislav Lhotka]

> On 08 Jan 2016, at 13:53, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> Juergen Schoenwaelder  writes:
>> 
>>> On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote:
 Hi Juergen,
 
 On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
> On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
>> It’s true that the draft is largely centered around the 
>> intended/applied config notion, but not exclusively.  Specifically, 4-B 
>> has "Ability to map intended config nodes to associated derived state 
>> nodes".  I think that this might be the only exclusion though and, if it 
>> weren’t for it I would’ve used your title suggestion from the LC 
>> review.   Should one requirement have such influence over the title is 
>> the question.  I was trying to be fair to it, but maybe it's going too 
>> far.
>> 
>> Regarding visibility and control, I was attempting to use common words 
>> (not normative terms) here.  My intent for them is something along the 
>> lines of:
>> 
>>  visibility: read/understand
>>  control: write/orchestrate
>> 
> We do not write operational state. I have no clue how 'orchestrate'
> helps me either. What is wrong with using defined terminology in
> a title?
 I don't think that using defined terminology is a problem.  But I also 
 think that the title that you have suggested seems to suggest a narrower 
 scope that what the requirements articulate.
 
 In particular, the draft places requirements relating the configuration 
 to the derived state (I.e. Req 4B).
 
 It also places further requirements on how management protocols are 
 expected to handle synchronous and asynchronous config edit requests. 
 (E.g. Req 2 A, B, C and associated definitions).
>>> 
>>> Note that synchronous and asynchronous are defined in terms of
>>> intended / applied configuration.
>>> 
 I don't have a particular problem with the current title, but if you 
 don't like visibility/control, then perhaps "Terminology and 
 Requirements for Enhanced Handling of Operational State"?
>>> 
>>> Better but I still think this proposal is too broad given the content
>>> of the document. I still believe my proposal is right to the point.
>> 
>> +1
>> 
>> The draft talks about introducing applied configuration and its
>> relationship to state data and intended configuration (which, I believe,
>> is the good old "running"). I don't see any enhanced handling of
>> operational state.
> 
> Well, the applied config is part of the operational state, and there

According to 6020bis, state data are tagged with "config false" in YANG 
modules. I don't think it is going to be the case of applied configuration.

Lada

> are requirements for retrieval of the operational state.  So it is
> related.   I think the current title is fine.
> 
> 
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

Hi Martin, et al, 

On 1/8/16, 2:54 AM, "Martin Bjorklund"  wrote:

>Hi,
>
>"Acee Lindem (acee)"  wrote:
>> 
>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>> 
>> >
>> >> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>> >> wrote:
>> >> 
>> >>> 
>>  On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>  wrote:
>>  
>>  On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>  
>> > I hope that nobody disagrees that the operational state design and
>> >how 
>> > to structure the models are the two blocking factors to publish
>>YANG
>> > models. If you disagree or don't see this, let me know, I should
>> > communicate better.
>>  
>>  Even if it may spoil your day, I disagree that there is a blocking
>>  factor that should stop us from publishing models. There seem to be
>>  ways to address the requirements without having to block all work
>>or
>>  to redo what that we have published. But sure, if you make it a
>>  blocking factor, it will be one.
>> >>> 
>> >>> I agree with Juergen. It is not clear to me how the proposed split
>> >>>between intended and applied configuration is supposed to affect the
>> >>>data models we are working on.
>> >> 
>> >> 
>> >> As I understand it, solution #1 affects the models themselves,
>>whereas
>> >>solutions #2 and #3 are transparent to the models.
>> >
>> >Then #1 looks like a non-starter to me.
>> 
>> I’d like to point out that we also have the requirement to allow
>>retrieval
>> of derived-state along with intended-config and applied-config. This
>>will
>> require modification to most of the existing YANG drafts as most now
>>have
>> separate trees for config and operational state.
>
>I don't agree with the conclusion that changes are needed due to this
>requirement.
>
>Solution #1 ("openconfig") requires changes to handle applied config.
>Solution #2 ("kent's") does not.
>
>Both solutions #1 and #2 use separate nodes for derived state.
>
>It might appear as #1 and #2 are very different in their handling of
>derived state, since #1 put all config false nodes directly under the
>config true nodes, whereas #2 in some cases have a top-level
>"xxx-state" config false node.
>
>But in fact #2 allows the solution in #1 as one special case.  The
>reason that RFC 7223 has a separate list for derived state interfaces
>is to allow for non-configured interfaces to be monitored.  If this
>was not a requirement, all config false nodes could (would) have been
>defined in the config true interface list.

I see that this is discussed in the latest version of
draft-ietf-netmod-rfc6087bis-05.txt and that it is “appropriate" to put
the operational state in the same subtree as the config state if it would
not exist if not configured. Is “appropriate” a recommendation?

   Careful consideration needs to be given to the location of
   operational state data.  It can either be located within the
   configuration subtree for which it applies, or it can be located
   outside the particular configuration subtree.  Placing operation
   state within the configuration subtree is appropriate if the
   operational values can only exist if the configuration exists.


However, we currently have many YANG models in progress where the config
and state trees are separate subtrees. If we all agree with the opstate
requirement for derived state, perhaps it is time to get the word out and
modify these models.

Thanks,
Acee 



>
>
>/martin

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

Re: [netmod] action-stmt

[Martin Bjorklund]

Hi,

Andy Bierman  wrote:
> Hi,
> 
> The action-stmt example on page 27 is wrong.
> The  element is missing.  It is shown correctly
> on page 105.
> p27
>  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>http://acme.example.com/system";>
>  eth1
>  
>192.0.2.1
>  
>
>  
> 
> 
> p105
> 
> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>
>  http://example.net/server-farm";>
>apache-1
>
>  2014-07-29T13:42:00Z
>
>  
>
>  

Fixed.

> Sec. 7.15  provides few details wrt/ input processing.
> Extra input is ignored? (draft is silent about that).
> YANG attributes like "insert"or "operation" are ignored? (also silent).

Right, just as the text for rpcs.  Do you think we need to add some
text about this?

> Sec 7.15.2, para 2 is not clear whether the XML hierarchy
> has to exist in any particular datastore (or opstate).
> Since there is no mention of datastores in 7.15, I
> assume the text just refers to the input containing
> schema-valid XML, which may or may not correspond
> to actual data instances somewhere inn the server.

Yes.


/martin

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

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

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote:
> >> Hi Juergen,
> >> 
> >> On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
> >> >On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
> >> >>It’s true that the draft is largely centered around the 
> >> >>intended/applied config notion, but not exclusively.  Specifically, 4-B 
> >> >>has "Ability to map intended config nodes to associated derived state 
> >> >>nodes".  I think that this might be the only exclusion though and, if it 
> >> >>weren’t for it I would’ve used your title suggestion from the LC 
> >> >>review.   Should one requirement have such influence over the title is 
> >> >>the question.  I was trying to be fair to it, but maybe it's going too 
> >> >>far.
> >> >>
> >> >>Regarding visibility and control, I was attempting to use common words 
> >> >>(not normative terms) here.  My intent for them is something along the 
> >> >>lines of:
> >> >>
> >> >> visibility: read/understand
> >> >> control: write/orchestrate
> >> >>
> >> >We do not write operational state. I have no clue how 'orchestrate'
> >> >helps me either. What is wrong with using defined terminology in
> >> >a title?
> >> I don't think that using defined terminology is a problem.  But I also 
> >> think that the title that you have suggested seems to suggest a narrower 
> >> scope that what the requirements articulate.
> >> 
> >> In particular, the draft places requirements relating the configuration 
> >> to the derived state (I.e. Req 4B).
> >> 
> >> It also places further requirements on how management protocols are 
> >> expected to handle synchronous and asynchronous config edit requests. 
> >> (E.g. Req 2 A, B, C and associated definitions).
> >
> > Note that synchronous and asynchronous are defined in terms of
> > intended / applied configuration.
> >  
> >> I don't have a particular problem with the current title, but if you 
> >> don't like visibility/control, then perhaps "Terminology and 
> >> Requirements for Enhanced Handling of Operational State"?
> >
> > Better but I still think this proposal is too broad given the content
> > of the document. I still believe my proposal is right to the point.
> 
> +1
> 
> The draft talks about introducing applied configuration and its
> relationship to state data and intended configuration (which, I believe,
> is the good old "running"). I don't see any enhanced handling of
> operational state.

Well, the applied config is part of the operational state, and there
are requirements for retrieval of the operational state.  So it is
related.   I think the current title is fine.


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

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

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote:
>> Hi Juergen,
>> 
>> On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
>> >On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
>> >>It’s true that the draft is largely centered around the 
>> >>intended/applied config notion, but not exclusively.  Specifically, 4-B 
>> >>has "Ability to map intended config nodes to associated derived state 
>> >>nodes".  I think that this might be the only exclusion though and, if it 
>> >>weren’t for it I would’ve used your title suggestion from the LC 
>> >>review.   Should one requirement have such influence over the title is 
>> >>the question.  I was trying to be fair to it, but maybe it's going too 
>> >>far.
>> >>
>> >>Regarding visibility and control, I was attempting to use common words 
>> >>(not normative terms) here.  My intent for them is something along the 
>> >>lines of:
>> >>
>> >>   visibility: read/understand
>> >>   control: write/orchestrate
>> >>
>> >We do not write operational state. I have no clue how 'orchestrate'
>> >helps me either. What is wrong with using defined terminology in
>> >a title?
>> I don't think that using defined terminology is a problem.  But I also 
>> think that the title that you have suggested seems to suggest a narrower 
>> scope that what the requirements articulate.
>> 
>> In particular, the draft places requirements relating the configuration 
>> to the derived state (I.e. Req 4B).
>> 
>> It also places further requirements on how management protocols are 
>> expected to handle synchronous and asynchronous config edit requests. 
>> (E.g. Req 2 A, B, C and associated definitions).
>
> Note that synchronous and asynchronous are defined in terms of
> intended / applied configuration.
>  
>> I don't have a particular problem with the current title, but if you 
>> don't like visibility/control, then perhaps "Terminology and 
>> Requirements for Enhanced Handling of Operational State"?
>
> Better but I still think this proposal is too broad given the content
> of the document. I still believe my proposal is right to the point.

+1

The draft talks about introducing applied configuration and its
relationship to state data and intended configuration (which, I believe,
is the good old "running"). I don't see any enhanced handling of
operational state.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] applied configuration and system-controlled entries

[Ladislav Lhotka]

Robert Wilton  writes:

> Hi Lada,
>
> I think that requirement 1D is fairly key to what is being asked for 
> here to allow both the user and system to easily relate between what the 
> operator desires and what configuration the system is actually using,

In a way, system-controlled interfaces are default entries in the
interface list - and the system can certainly be using interfaces with
no configuration installed by NETCONF/RESTCONF clients.

> so I wouldn't be particularly keen on loosening this requirement.

OK, but then IMO this intended-applied dualism is of limited
utility. For many systems or services, asynchronicity is not an option,
or isn't important.

>
> For the ACL example:
> Would it be feasible to change the ACL module to use a leafref to the 
> interface name, with the added constraint that you have to at least 
> configure the existence of an interface before you can have any 
> configuration referring to it?

Well, yes, that's how it is supposed to be done now - also, for example,
for stacking interfaces as in Appendix B of RFC 7223.

It is not only extra work: the interface list can be locked, so it may
not be possible to immediately create a dummy interface entry and,
consequently, an ACL rule with that interface cannot be configured. In
this sense, using a string rather than a leafref looks like a reasonable
choice.

As Martin pointed out, with YANG 1.1 it would be possible to refer to an
interface entry in state data from configuration. On the other hand,
with "require-instance false" validation won't detect errors in ACL
configuration such as referring to a non-existent interface.

Lada

>
> Thanks,
> Rob
>
>
> On 07/01/2016 10:20, Ladislav Lhotka wrote:
>> Hi,
>>
>> a good use of applied configuration could be to formalize the concept of 
>> system-controlled entries as defined in RFC 7223, routing-cfg, and probably 
>> elsewhere, too.
>>
>> My idea is that system-controlled interfaces or other entries would appear 
>> in applied configuration, but not in intended configuration until something 
>> needs to be really configured. We could then permit leafrefs from intended 
>> configuration to refer to leafs in applied configuration. One case where 
>> this would be useful is the ACL module, where match conditions refering to 
>> interfaces currently have to use plain strings as references to interface 
>> names.
>>
>> However, the above idea seems to be at odds with requirement 1D in 
>> opstate-reqs-02. I wonder: could that requirement be relaxed or removed so 
>> that the above use case can be supported?
>>
>> Thanks, Lada
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Martin Bjorklund]

Dean Bogdanovic  wrote:
> 
> > On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder
> >  wrote:
> > 
> > On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote:
> >> Juergen Schoenwaelder  wrote:
> >>> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:
>  
>  With YANG 1.1, a leafref can be marked as "require-instance false",
>  which allows a interface-state-ref to be used in config:
>  
>    type if:interface-state-ref {
>  require-instance false;
>    }
>    // + add description that explains what happens if there is no such
>    //   instance
>  
>  
>  (NOTE: this doesn't work w/ pyang at the momement, I am working on a
>  fix)
>  
> >>> 
> >>> And it would have to be if:interface-ref instead
> >>> if:interface-state-ref
> >>> I think.
> >> 
> >> No, I meant interface-state-ref.  This way you can put a filter on
> >> non-configured interfaces.
> >> 
> > 
> > But with require-instance false, this is also true for
> > if:interface-ref.  If I preconfigure and interface, I might also want
> > to preconfigure ACLs refering the preconfigure interface. And note
> > that if:interface-state-ref refers to a config false leaf.
> 
> In this case we have to change to yang-version 1.1. The plan was to
> have it for 1.0. Do we want to move the ACL model to YANG minimum
> version 1.1?

I think it is ok.  We're fixing issues like this one in 1.1 so that we
don't have to rely on various workarounds.  Note that the second WGLC
for 1.1 just ended, w/ mostly minor proposed edits.


/martin

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

Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:
> > > > 
> > > > With YANG 1.1, a leafref can be marked as "require-instance false",
> > > > which allows a interface-state-ref to be used in config:
> > > > 
> > > >type if:interface-state-ref {
> > > >  require-instance false;
> > > >}
> > > >// + add description that explains what happens if there is no such
> > > >//   instance
> > > > 
> > > > 
> > > > (NOTE: this doesn't work w/ pyang at the momement, I am working on a
> > > > fix)
> > > > 
> > > 
> > > And it would have to be if:interface-ref instead if:interface-state-ref
> > > I think.
> > 
> > No, I meant interface-state-ref.  This way you can put a filter on
> > non-configured interfaces.
> >
> 
> But with require-instance false, this is also true for
> if:interface-ref.

Sure.

> If I preconfigure and interface, I might also want
> to preconfigure ACLs refering the preconfigure interface.

But this is also ok for interface-state-ref with require-instance
false.  I prefer this, b/c then we can say that once the target leaf
exists, the filter applies.

> And note
> that if:interface-state-ref refers to a config false leaf.

Yes, this is ok w/ require-instance false.


/martin

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

Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

> On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder 
>  wrote:
> 
> On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote:
>> Juergen Schoenwaelder  wrote:
>>> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:
 
 With YANG 1.1, a leafref can be marked as "require-instance false",
 which allows a interface-state-ref to be used in config:
 
   type if:interface-state-ref {
 require-instance false;
   }
   // + add description that explains what happens if there is no such
   //   instance
 
 
 (NOTE: this doesn't work w/ pyang at the momement, I am working on a
 fix)
 
>>> 
>>> And it would have to be if:interface-ref instead if:interface-state-ref
>>> I think.
>> 
>> No, I meant interface-state-ref.  This way you can put a filter on
>> non-configured interfaces.
>> 
> 
> But with require-instance false, this is also true for
> if:interface-ref.  If I preconfigure and interface, I might also want
> to preconfigure ACLs refering the preconfigure interface. And note
> that if:interface-state-ref refers to a config false leaf.

In this case we have to change to yang-version 1.1. The plan was to have it for 
1.0. Do we want to move the ACL model to YANG minimum version 1.1?
> 
> /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] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Juergen Schoenwaelder]

On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:
> > > 
> > > With YANG 1.1, a leafref can be marked as "require-instance false",
> > > which allows a interface-state-ref to be used in config:
> > > 
> > >type if:interface-state-ref {
> > >  require-instance false;
> > >}
> > >// + add description that explains what happens if there is no such
> > >//   instance
> > > 
> > > 
> > > (NOTE: this doesn't work w/ pyang at the momement, I am working on a
> > > fix)
> > > 
> > 
> > And it would have to be if:interface-ref instead if:interface-state-ref
> > I think.
> 
> No, I meant interface-state-ref.  This way you can put a filter on
> non-configured interfaces.
>

But with require-instance false, this is also true for
if:interface-ref.  If I preconfigure and interface, I might also want
to preconfigure ACLs refering the preconfigure interface. And note
that if:interface-state-ref refers to a config false leaf.

/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] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:
> > 
> > With YANG 1.1, a leafref can be marked as "require-instance false",
> > which allows a interface-state-ref to be used in config:
> > 
> >type if:interface-state-ref {
> >  require-instance false;
> >}
> >// + add description that explains what happens if there is no such
> >//   instance
> > 
> > 
> > (NOTE: this doesn't work w/ pyang at the momement, I am working on a
> > fix)
> > 
> 
> And it would have to be if:interface-ref instead if:interface-state-ref
> I think.

No, I meant interface-state-ref.  This way you can put a filter on
non-configured interfaces.


/martin

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

Re: [netmod] comments

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 08 Jan 2016, at 09:40, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> 
> >>> On 29 Dec 2015, at 17:47, Andy Bierman  wrote:
> >>> 
> >>> 
> >>> 
> >>> On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka  wrote:
> >>> Hi,
> >>> 
> >>> I propose the following change to sec. 14 in 6020bis (third paragraph):
> >>> 
> >>> OLD
> >>>   This grammar assumes that the scanner replaces YANG comments with a
> >>>   single space character.
> >>> 
> >>> NEW
> >>>   This grammar assumes that the scanner replaces YANG comments outside
> >>>   quoted arguments with a single space character.
> >>> 
> >>> 
> >>> 
> >>> A comment inside a quoted string is not a YANG comment.
> >>> It is just part of a string that happens to look like a comment.
> >> 
> >> As far as I can tell, this is not clear from the text.
> > 
> > Note that 6.1.3 says:
> > 
> >   If a string contains any space or tab characters, a semicolon (";"),
> >   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
> >   it MUST be enclosed within double or single quotes.
> 
> Yes, but it doesn't say that comment sequences inside a quoted
> string are interpreted as literal characters.
> In another mail I proposed a simple change to sec. 6.1.1 that would
> solve this issue: 
> 
>Inside a quoted argument string, the above character pairs
>are never interpreted 
>as the start or end of a comment.

Ok, I added this clarification.


/martin


> > 
> > Also, section 14 says:
> > 
> >   This grammar assumes that the scanner replaces YANG comments with a
> >   single space character.
> 
> Yes, as long as it is clear that a comment cannot be inside a quoted argument.
> 
> Lada
> 
> > 
> > 
> > 
> > /martin
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 

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

Re: [netmod] whitespace characters

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 08 Jan 2016, at 09:31, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> Hi,
> >> 
> >> the definition of "enum" argument (sec. 9.6.4 in 6020bis) says:
> >> 
> >>   The string MUST NOT be empty and MUST NOT have any leading or trailing
> >>   whitespace characters.
> >> 
> >> It is not clear what "whitespace character" means.
> > 
> > It is supposed to be unicode whitespace.  Should we write:
> > 
> >  The string MUST NOT be empty and MUST NOT have any leading or trailing
> >  whitespace characters (any Unicode character with the "White_Space"
> >  property).
> > 
> > or simply
> > 
> >  The string MUST NOT be empty and MUST NOT have any leading or trailing
> >  Unicode whitespace characters.
> > 
> 
> I guess I prefer the more verbose version.

Ok, fixed.

> >> The ABNF indicates this:
> >> 
> >>   WSP = SP / HTAB
> >> ; whitespace
> > 
> > This is copied from RFC 5234.
> 
> OK, but it's not the whitespace that the enum definition talks about.
> 
> BTW, sec. 9.7.2 says that "bits" value is "a space-separated list". I
> assume what's meant here is only the regular space, i.e. U+0020.

Yes.  It doesn't say "whitespace-separated list".


/martin



> 
> Lada 
> 
> > 
> > 
> > /martin
> > 
> > 
> > 
> >> 
> >> I think in the "enum" definition LF (and maybe also CR?) should also
> >> count as a whitespace character.
> >> 
> >> Lada
> >> 
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >> 
> >> 
> >> 
> >> 
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >> 
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 

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

Re: [netmod] whitespace characters

[Ladislav Lhotka]

> On 08 Jan 2016, at 09:31, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> Hi,
>> 
>> the definition of "enum" argument (sec. 9.6.4 in 6020bis) says:
>> 
>>   The string MUST NOT be empty and MUST NOT have any leading or trailing
>>   whitespace characters.
>> 
>> It is not clear what "whitespace character" means.
> 
> It is supposed to be unicode whitespace.  Should we write:
> 
>  The string MUST NOT be empty and MUST NOT have any leading or trailing
>  whitespace characters (any Unicode character with the "White_Space"
>  property).
> 
> or simply
> 
>  The string MUST NOT be empty and MUST NOT have any leading or trailing
>  Unicode whitespace characters.
> 

I guess I prefer the more verbose version.

> 
>> The ABNF indicates this:
>> 
>>   WSP = SP / HTAB
>> ; whitespace
> 
> This is copied from RFC 5234.

OK, but it's not the whitespace that the enum definition talks about.

BTW, sec. 9.7.2 says that "bits" value is "a space-separated list". I assume 
what's meant here is only the regular space, i.e. U+0020.

Lada 

> 
> 
> /martin
> 
> 
> 
>> 
>> I think in the "enum" definition LF (and maybe also CR?) should also count 
>> as a whitespace character.
>> 
>> Lada
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] comments

[Ladislav Lhotka]

> On 08 Jan 2016, at 09:40, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> 
>>> On 29 Dec 2015, at 17:47, Andy Bierman  wrote:
>>> 
>>> 
>>> 
>>> On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka  wrote:
>>> Hi,
>>> 
>>> I propose the following change to sec. 14 in 6020bis (third paragraph):
>>> 
>>> OLD
>>>   This grammar assumes that the scanner replaces YANG comments with a
>>>   single space character.
>>> 
>>> NEW
>>>   This grammar assumes that the scanner replaces YANG comments outside
>>>   quoted arguments with a single space character.
>>> 
>>> 
>>> 
>>> A comment inside a quoted string is not a YANG comment.
>>> It is just part of a string that happens to look like a comment.
>> 
>> As far as I can tell, this is not clear from the text.
> 
> Note that 6.1.3 says:
> 
>   If a string contains any space or tab characters, a semicolon (";"),
>   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
>   it MUST be enclosed within double or single quotes.

Yes, but it doesn't say that comment sequences inside a quoted string are 
interpreted as literal characters.
In another mail I proposed a simple change to sec. 6.1.1 that would solve this 
issue:

   Inside a quoted argument string, the above character pairs are never 
interpreted
   as the start or end of a comment.

> 
> Also, section 14 says:
> 
>   This grammar assumes that the scanner replaces YANG comments with a
>   single space character.

Yes, as long as it is clear that a comment cannot be inside a quoted argument.

Lada

> 
> 
> 
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] comments

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 29 Dec 2015, at 17:47, Andy Bierman  wrote:
> > 
> > 
> > 
> > On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka  wrote:
> > Hi,
> > 
> > I propose the following change to sec. 14 in 6020bis (third paragraph):
> > 
> > OLD
> >This grammar assumes that the scanner replaces YANG comments with a
> >single space character.
> > 
> > NEW
> >This grammar assumes that the scanner replaces YANG comments outside
> >quoted arguments with a single space character.
> > 
> > 
> > 
> > A comment inside a quoted string is not a YANG comment.
> > It is just part of a string that happens to look like a comment.
> 
> As far as I can tell, this is not clear from the text.

Note that 6.1.3 says:

   If a string contains any space or tab characters, a semicolon (";"),
   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
   it MUST be enclosed within double or single quotes.

Also, section 14 says:

   This grammar assumes that the scanner replaces YANG comments with a
   single space character.



/martin

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

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

[Juergen Schoenwaelder]

On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote:
> Hi Juergen,
> 
> On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
> >On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
> >>It’s true that the draft is largely centered around the 
> >>intended/applied config notion, but not exclusively.  Specifically, 4-B 
> >>has "Ability to map intended config nodes to associated derived state 
> >>nodes".  I think that this might be the only exclusion though and, if it 
> >>weren’t for it I would’ve used your title suggestion from the LC 
> >>review.   Should one requirement have such influence over the title is 
> >>the question.  I was trying to be fair to it, but maybe it's going too 
> >>far.
> >>
> >>Regarding visibility and control, I was attempting to use common words 
> >>(not normative terms) here.  My intent for them is something along the 
> >>lines of:
> >>
> >>visibility: read/understand
> >>control: write/orchestrate
> >>
> >We do not write operational state. I have no clue how 'orchestrate'
> >helps me either. What is wrong with using defined terminology in
> >a title?
> I don't think that using defined terminology is a problem.  But I also 
> think that the title that you have suggested seems to suggest a narrower 
> scope that what the requirements articulate.
> 
> In particular, the draft places requirements relating the configuration 
> to the derived state (I.e. Req 4B).
> 
> It also places further requirements on how management protocols are 
> expected to handle synchronous and asynchronous config edit requests. 
> (E.g. Req 2 A, B, C and associated definitions).

Note that synchronous and asynchronous are defined in terms of
intended / applied configuration.
 
> I don't have a particular problem with the current title, but if you 
> don't like visibility/control, then perhaps "Terminology and 
> Requirements for Enhanced Handling of Operational State"?

Better but I still think this proposal is too broad given the content
of the document. I still believe my proposal is right to the point.

/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] whitespace characters

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> the definition of "enum" argument (sec. 9.6.4 in 6020bis) says:
> 
>The string MUST NOT be empty and MUST NOT have any leading or trailing
>whitespace characters.
> 
> It is not clear what "whitespace character" means.

It is supposed to be unicode whitespace.  Should we write:

  The string MUST NOT be empty and MUST NOT have any leading or trailing
  whitespace characters (any Unicode character with the "White_Space"
  property).

or simply

  The string MUST NOT be empty and MUST NOT have any leading or trailing
  Unicode whitespace characters.


> The ABNF indicates this:
> 
>WSP = SP / HTAB
>  ; whitespace

This is copied from RFC 5234.


/martin



> 
> I think in the "enum" definition LF (and maybe also CR?) should also count as 
> a whitespace character.
> 
> Lada
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> 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