Re: [netmod] 6020bis more than one revision of a module

[David Reid]

> >I'm reviewing 6020bis since it is in working group last call. 
> >I see a new requirement that a server MUST NOT implement
> >more than one revision of a module. I understand that supporting
> >more than one revision can cause problems, but I expect that
> >it will happen in practice. I know it happens sometimes with
> >MIBs in SNMP. I think MUST NOT is too strong.
> 
> I've encountered the same phenomenon in the SNMP universe,
> so if I expected Netconf to used as a replacement for SNMP
> I'd have the same concern.
> 
> Randy

Here is the situation I face. We put a netconf server in our SNMP Master
agent. Using the MIB to YANG conversion rules from RFC 6643 we can provide
read-only access (or read-write in a non-standard way) via netconf and yang
to all of the MIB data. We have existing customers using different revisions
of the same MIB module in different subagents. If they convert those
MIB modules to YANG modules and access the information via netconf, it
would violate the proposed rule.

-David Reid 

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

Re: [netmod] 6020bis more than one revision of a module

[Andy Bierman]

On Wed, Oct 14, 2015 at 8:24 AM, David Reid  wrote:

> > There seems to be 3 solutions, none of which are very good:
> >
> > 1) document everything: return lots of
> > instance-level conformance information and expect the client
> > to sort it out
> >
> > 2) Advertise the newer version and let the client figure out
> > that some instances only allow 1 - 10
> >
> > 3) Advertise the older version and let the client figure out
> > that some instances allow 1 - 20.
> >
> >
> > YANG says to do (3).
>
> Where does YANG tell which version the server should advertise?
>
>

Not sure but advertising range 1 - 10 is safe since all instances support
that.

Presumably, the reason we advertise capabilities is so the client will
only try operations that it thinks the server supports.  The downside
for inaccuracy is either (2) false advertising or (3) under-advertising


-David Reid
>
>
Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6020bis more than one revision of a module

[David Reid]

> There seems to be 3 solutions, none of which are very good:
> 
> 1) document everything: return lots of
> instance-level conformance information and expect the client
> to sort it out
> 
> 2) Advertise the newer version and let the client figure out
> that some instances only allow 1 - 10
> 
> 3) Advertise the older version and let the client figure out
> that some instances allow 1 - 20.
> 
> 
> YANG says to do (3).

Where does YANG tell which version the server should advertise?

-David Reid

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

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

[Kent Watsen]

>Anyway, as long as a regular NC/RC server does not have to pay a price
>for this applied config idea, I have no real problem with this since I
>am sure the market will sort this out.

This goes to the solution - that it should allow servers to opt-in to
support applied config.

I have also been thinking about market response.  It is a bit frustrating
to even think that solution might not be widely popular, but the reality
is that I don't see how it can be widely implemented - and so maybe it
will only be popular for datacenter operators?

Kent // as a contributor


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

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

[Robert Wilton]

Hi All,

Are there any more comments on the following proposed descriptions, or
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully effect the
configuration change to all impacted components in the server, updating
both the server's intended and applied configuration (see terms), before
replying to the client.  The reply to the client indicates whether there
are any errors in the request or errors from applying the configuration
change.

Asynchronous configuration operation - A configuration request to update
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied
configuration state (see term) is updated after the configuration change
has been fully effected to all impacted components in the server.  The
reply to the client only indicates whether there are any errors in the
original request.

Synchronous configuration server - a configuration server that processes
all configuration operations as synchronous configuration operations.

Asynchronous configuration server - a configuration server that processes
all configuration operations as asynchronous configuration operations.

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:

On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:

Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:

On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:

Hi Kent,

Feeding in the various input, I think that this is the best refinement
that I've come up with:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server SHOULD ensure that the
request is valid, and MUST fully effect the configuration change to all
impacted components in the server, updating both the server's intended
and applied configuration (see terms), before replying to the client.
The reply to the client indicates whether there are any errors in the
request or errors from applying the configuration change.

What does "SHOULD ensure that the request is valid" mean? RFC 6020
says:

When datastore processing is complete, the final contents MUST obey
all validation constraints.  This validation processing is performed
at differing times according to the datastore.  If the datastore is
 or , these constraints MUST be enforced at the
end of the  or  operation.  If the
datastore is , the constraint enforcement is delayed
until a  or  operation.

Are we talking about datastore validation or validation of a request?
If the former, are we watering down a MUST to a SHOULD?

Really it is datastore validation, particularly for an async request
where the intended config nodes are updated before replying. I'm not
intentionally trying to water down a MUST to a SHOULD, but Kent had
concerns that my previous description using "semantically validate"
would exclude an ephemeral datastore, so I was trying to water down the
description and also describe the behaviour in a way that isn't specific
to either RESTCONF/NETCONF or datastores.

Perhaps, the start of sentence could simply be changed to:

The server MUST fully effect the configuration change to all
impacted components in the server ...

And equivalently for the asynchronous case below:

The server MUST update the server's intended configuration ...


Works for me. Sometimes less is more.


And I would not be surprised if we also need this sooner or later:

   Mixed configuration server - a configuration server that processes
   some configuration operations as synchronous configuration
   operations and some configuration operations as asynchronous
   configuration operations.

Yes, I would expect that clients may want to define the expected
behaviour, potentially on a per request basis.

I doubt that servers will offer clients to choose; I am more with Andy
that in real systems, depending on the data model, certain parts of a
data model may be synchronous while others may be asynchronous.


Any further comments?

Based on the feedback from Andy and others, it seems that the prevailing
view is that existing NETCONF and RESTCONF should be regarded as being
asynchronous in their behaviour in that the config nodes in the running
datastore only represent the intended configuration and not the applied
configuration.

Depends on the definition of applied configuration - where is the latest
version of it?

The last proposed text for intended/applied is as below:

   intended configuration - this data represents the 

Re: [netmod] 6020bis - sec. 5.6.4 comments

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> regarding $subj:
> 
> - What about extensions? Do modules defining them have to be
>   implemented? That is, is "default-revision" true or false for such
>   modules?

The "default-revision" leaf doesn't exist in ietf-yang-libary.  I will
remove the note about aligning with ietf-yang-libary, and do:

OLD:

   If a server implements a module A that imports a module C without
   specifying the revision date of module C, and the server does not
   implement C (e.g., if C only defines some typedefs), the server
   MUST list module C in the "/modules/module" list from
   "ietf-yang-library", and it MUST set the leaf "default-revision" to
   "true" for this module.

NEW:

   If a server implements a module A that imports a module C without
   specifying the revision date of module C, and the server does not
   implement C (e.g., if C only defines some typedefs), the server
   MUST list module C in the "/modules/module" list from
   "ietf-yang-library", and it MUST set the leaf "conformance" to
   "import" for this module.


> - Third paragraph:
> 
> OLD
> 
>This is regardless of if module B is imported by revision or not.
> 
> NEW
> 
>If module B is imported by revision, the corresponding "revision-date"
>statement is ignored.

I think your proposed text can be misunderstood.  The "revision-date"
statement is not ignored; typedefs etc. will be taken from the
specified revision.



/martin

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

Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"

[Kent Watsen]

Thank you Robert for bringing the discussion back to the github issues.

Robert writes:

> In particular:
>- does it include support for templating (as per 
> openconfig-netmod-opstate-01 section 7.3.)?
>- is it allowed to represent system created objects that have no 
> corresponding configuration?
>
> Requirement 1.D states

 D.  For asynchronous systems, when fully synchronized, the data
   in the applied configuration is the same as the data in the
   intended configuration.

>
> So, if this requirement statement stands as being valid (which I think it 
> should) then that would imply that the answer for both the two issues above 
> must be "no".  The only question would be whether these need to be explicitly 
> listed out?

[KENT] so I think I have to (begrudgingly) agree with your logic.I have 
heard the operators state that they want the intended/applied comparison to be 
drop-dead simple.  To that end, it would not be possible to flatten templates 
or apply defaults, or make any other change - it needs to be as close as 
possible to a carbon-copy of the original intended configuration (where 
deviations are allowed only for cases like a missing line-card).  To this end, 
yes, I think that we could tack on a statement like the following:

That is, the intended configuration is a subset of the applied
configuration where omissions are only due to when the
configuration cannot be applied (e.g., a missing line-card).

What do you think?



>>  - how does it relate to the state of the system after a equivalent 
>> synchronous config commit (if at all)?
>>
> Again, I think that definition of requirement 1.D, along with the proposed 
> definition of synchronous configuration operation vs asynchronous 
> configuration operation, will provide a sufficient answer to this question.  
> I.e. that the state of the system after an asynchronous config operation 
> must, when fully synchronized, be the same as the state of the system after 
> an equivalent synchronous configuration operation completes and replies back.

[KENT] I agree with this, but I think it impacts issue #6 more so than issue #4 
- right?


Thanks,
Kent


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

Re: [netmod] Yang 1.0/1.1 ABNF Grammar:

[Martin Bjorklund]

Robert Wilton  wrote:
> Hi Martin,
> 
> I was looking at the YANG ABNF grammar a bit more last night (to see
> how hard it would be to write a parser for it) and I had a couple more
> observations.  Apologies that this is after the WG last call ...
> 
> 1. [Trivial] The indentation of the range statement in 9.3.5 looks
> wrong.
> 
> 9.3.5. Usage Example
> 
>  typedef my-decimal {
>type decimal64 {
>  fraction-digits 2;
>range "1 .. 3.14 | 10 | 20..max";
>}
>  }
> 
> 
> I presume that it should be:
> 
> 9.3.5. Usage Example
> 
>  typedef my-decimal {
>type decimal64 {
>  fraction-digits 2;
>  range "1 .. 3.14 | 10 | 20..max";
>}
>  }

Fixed.

> 2.  The description of yang-char (around page 186) doesn't seem to be
> quite accurate (relative to description of legal characters in 6. YANG
> Syntax), and given that it excludes character values outside the
> unicode range.

Hmm, which characters are outside the unicode range?

>;; any Unicode character including tab, carriage return, and line
>;; feed, but excluding the other C0 control characters, the surrogate
>;; blocks, and the noncharacters.
>yang-char = %x9 / %xA / %xD / %x20-D7FF /
>...
> 
> 
> Should this be:
> 
>;; any Unicode or IOS/IEC 10646 character including tab, carriage return,
>;; and line
>;; feed, but excluding the other C0 control characters, the surrogate
>;; blocks, and the noncharacters.
>yang-char = %x9 / %xA / %xD / %x20-D7FF /

I think this would be ok.

> 3. There are lots of comments where "these stmts can appear in any
> order", e.g.
> 
>linkageStmts   = ;; these stmts can appear in any order
>  *importStmt
>  *includeStmt
> 
> Am I right in interpreting that there can be any number of import and
> include statements and they can be interleaved in any arbitrary
> order?

Yes.

> E.g. this specific example (but not in the general case) could equally
> have been written *(importStmt / includeStmt).

Well, the grammar defines the canonical order.  With the alternative
rule above, the canonical order would be different.


/martin

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

Re: [netmod] nested choices

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> my action item from yesterday's interim was to check whether some updates to 
> 6020bis are needed in order to address the corner cases presented by Balazs:
> 
> - https://mailarchive.ietf.org/arch/msg/netmod/i73sR0_d9UkshMuhxiCDOSZWhqk
> - https://mailarchive.ietf.org/arch/msg/netmod/gBum0NdkixozakgncYXPKPpLQDk
> 
> I would propose this minor change to sec. 7.9.3:
> 
> OLD
> 
>The default case is only important when considering the default
>values of nodes under the cases.
> 
> NEW
> 
>The default case is only important when considering the default
>contents of nodes under the cases (default values of leafs and
>leaf-lists, or default cases of nested choices).

Maybe a slight variation, and taking the entire paragraph into
account:

OLD:

  The default case is only important when considering the default
  values of nodes under the cases.  The default values for nodes under
  the default case are used if none of the nodes under any of the
  cases are present.

NEW:

  The default case is only important when considering the default
  statements of node under the cases (i.e., default values of leafs and
  leaf-lists, and default cases of nested choices).  The default
  values and nested default cases under the default case are used
  if none of the nodes under any of the cases are present.



/martin

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

Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

[Kent Watsen]

The new 1-D works for me.  It is similar in spirit to the proposal I just
sent in the issue #4 thread.

Thanks,
Kent


On 10/13/15, 9:14 AM, "Robert Wilton"  wrote:

>In an attempt to try and close on some of the proposed requirement text
>before Thursday's interim meeting.
>
>Does anyone have any outstanding objections on using this proposed text
>for Requirement 1.D, or is it sufficiently clear to update the draft,
>and resolve issue 1?
>
>OLD text for Requirement 1:
>
>1.  Ability to interact with both intended and applied configuration
>
>A.  The ability to ask the operational components of a system
>(e.g., line cards) for the configuration that they are
>currently using.  This is the "applied configuration".
>
>B.  Applied configuration is read-only
>
>C.  The data model for the applied configuration is the same as
>the data model for the intended configuration (same leaves)
>
>D.  For asynchronous systems, when fully synchronized, the data
>in the applied configuration is the same as the data in the
>intended configuration.
>
>
>NEW text (as above, changing 1.D only):
>
>1.  Ability to interact with both intended and applied configuration
>
>A.  The ability to ask the operational components of a system
>(e.g., line cards) for the configuration that they are
>currently using.  This is the "applied configuration".
>
>B.  Applied configuration is read-only
>
>C.  The data model for the applied configuration is the same as
>the data model for the intended configuration (same leaves)
>
>D.  When the configuration change for any intended configuration
>node has been successfully applied to the system (e.g. not
>failed, nor deferred due to absent hardware) then the
>existence and value of the corresponding applied
>configuration node must match the intended configuration
>node.
>
>
>Thanks,
>Rob
>
>
>On 06/10/2015 21:54, Juergen Schoenwaelder wrote:
>> On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote:
>>> Hi Juergen,
>>>
>>> On 06/10/2015 17:01, Juergen Schoenwaelder wrote:
 On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:
> Hi Kent,
>
> On 06/10/2015 01:40, Kent Watsen wrote:
>> This issue appears to have become more like issue #5 ­ should we
>>mark
>> this one a duplicate of the other?
> I suggest that we can just finalize on the text being discussed to
> replace 1.D and then resolve issue #1.
>
> Jason had proposed this text:
>
> When the configuration change for any intended configuration node has
> been successfully applied to the system (e.g. not failed, nor
>deferred
> due to absent hardware) then the existence and value of the applied
> equivalent of the node (whether that be a corresponding node in the
>data
> model, an attribute associated with the intended config node, the
> configuration node read from a different datastore or context, etc)
>must
> match the intended configuration node.
 I have no clue what "an attribute associated with the intended config
 node" or "the configuration node read from a different datastore or
 context" or "etc". means. What exactly is an "applied equivalent of
 the node"?

> Or perhaps this slightly briefer alternative is better?:
>
>  D.  When the configuration change for any intended
>  configuration node has been successfully applied to the
>  system (e.g. not failed, nor deferred due to absent
>hardware)
>  then the existence and value of the corresponding,
>possibly
>  notional, applied configuration node must match the
>intended
>  configuration node.
 What is the purpose of the phrase "possibly notional"?
>>> There was a concern that my previous text, i.e. as above but without
>>> "possibly notional", implied that applied configuration had to be
>>> actually represented as real data nodes in a YANG schema, which would
>>> disallow the solutions presented in draft-kwatsen-netmod-opstate-00 and
>>> draft-wilton-netmod-intf-ext-yang-00.
>>>
>>> On balance, my preference is to exclude the "possibly notional" phrase
>>> if the text is sufficiently clear without it.
>> My understanding is that draft-kwatsen-netmod-opstate-00 proposes to
>> represent applied config as nodes in a different datastore, so there
>> is no need for 'possibly notational'. I do not understand why
>> draft-wilton-netmod-intf-ext-yang-00 is relevant here. Do you mean
>> draft-wilton-netmod-opstate-yang-00? I do have major concerns about
>> this particular proposal since it changes the YANG data encoding
>> fundamentally. There was another proposal to use attributes, which is
>> also not without 

Re: [netmod] Order of evaluation for when?

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund  wrote:
> 
> > Balazs Lengyel  wrote:
> > > Hello Martin,
> > > I agree that A1 is what follows the spirit of YANG, but then IMHO you
> > > should change/correct 8.2.1 in YANG because that implies A2 and error.
> >
> > Ok, I agree.  I suggest we remove from 8.2.1:
> >
> >o  If data for a node tagged with "when" is present, and the "when"
> >   condition evaluates to "false", the server MUST reply with an
> >   "unknown-element" error-tag in the rpc-error.
> >
> > and add to 8.2.2:
> >
> >   o  Modification requests for nodes tagged with "when", and the "when"
> >  condition evaluates to "false".  In this case the server MUST reply
> >  with an "unknown-element" error-tag in the rpc-error.
> >
> >
> >
> 
> This seems like a BIG protocol change to  behavior.
> IMO this not an error at all.  In our server the false-when data is just
> pruned, and no error is ever sent for a pruned when=false data node.

So you are not following the current RFC 6020 spec?

I don't think this is a BIG protocol change, since the spec already
says that requests for nodes w/ false when expressions MUST send
error.  The change is to say that this behavior is true regardless of
evaluation order.

> It may be a client programming error for the client to provide
> false when nodes or not.  What if the client is reusing some
> code that sends 5 parameters, it it's OK if 1 of them gets
> pruned sometimes because of a false when (e.g, product
> feature-specific knob and that feature is not installed)

Well, it might be simpler to send if-featured nodes that the specific
server doesn't support - this is also an error in 6020.

> BTW, this is a really good example of what not to do, if one
> wants to make the YANG specification protocol independent.

That statement is true for the entire section 8.2, it is not
specifically true for this change.


/martin

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

Re: [netmod] Order of evaluation for when?

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund 
> > wrote:
> > >
> > > > Balazs Lengyel  wrote:
> > > > > Hello Martin,
> > > > > I agree that A1 is what follows the spirit of YANG, but then IMHO you
> > > > > should change/correct 8.2.1 in YANG because that implies A2 and
> > error.
> > > >
> > > > Ok, I agree.  I suggest we remove from 8.2.1:
> > > >
> > > >o  If data for a node tagged with "when" is present, and the "when"
> > > >   condition evaluates to "false", the server MUST reply with an
> > > >   "unknown-element" error-tag in the rpc-error.
> > > >
> > > > and add to 8.2.2:
> > > >
> > > >   o  Modification requests for nodes tagged with "when", and the "when"
> > > >  condition evaluates to "false".  In this case the server MUST
> > reply
> > > >  with an "unknown-element" error-tag in the rpc-error.
> > > >
> > > >
> > > >
> > >
> > > This seems like a BIG protocol change to  behavior.
> > > IMO this not an error at all.  In our server the false-when data is just
> > > pruned, and no error is ever sent for a pruned when=false data node.
> >
> > So you are not following the current RFC 6020 spec?
> >
> 
> 
> Yes we are following it.

Ok.

> The schema for the edit-config RPC operation contains
> an 'anyxml' for  node.  It does not contain any
> when-stmts for the data nodes that get passed in the  node.
> The correct behavior is to just enforce the error on the when-stmts
> that appear in the rpc-stmt.

I don't understand what you are trying to say.

Here's an example:

  augment /if:interfaces/if:interface {
when "if:type = 'ianaift:ethernetCsmacd'";

container ethernet {
  leaf duplex {
type enumeration {
  enum "half";
  enum "full";
}
  }
}
  }

Suppose the db is empty.

What if the edit-confif contains
 
  

  eth0
  full
  ianaift:ethernetCsmacd

  

will that work or not?  I.e., will the eth0 interface be created with
duplex full?
  

/martin



> 
> 
> 
> 
> > I don't think this is a BIG protocol change, since the spec already
> > says that requests for nodes w/ false when expressions MUST send
> > error.  The change is to say that this behavior is true regardless of
> > evaluation order.
> >
> > > It may be a client programming error for the client to provide
> > > false when nodes or not.  What if the client is reusing some
> > > code that sends 5 parameters, it it's OK if 1 of them gets
> > > pruned sometimes because of a false when (e.g, product
> > > feature-specific knob and that feature is not installed)
> >
> > Well, it might be simpler to send if-featured nodes that the specific
> > server doesn't support - this is also an error in 6020.
> >
> > > BTW, this is a really good example of what not to do, if one
> > > wants to make the YANG specification protocol independent.
> >
> > That statement is true for the entire section 8.2, it is not
> > specifically true for this change.
> >
> >
> > /martin
> >
> 
> 
> Andy

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

Re: [netmod] Order of evaluation for when?

[Andy Bierman]

On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund  wrote:

> Balazs Lengyel  wrote:
> > Hello Martin,
> > I agree that A1 is what follows the spirit of YANG, but then IMHO you
> > should change/correct 8.2.1 in YANG because that implies A2 and error.
>
> Ok, I agree.  I suggest we remove from 8.2.1:
>
>o  If data for a node tagged with "when" is present, and the "when"
>   condition evaluates to "false", the server MUST reply with an
>   "unknown-element" error-tag in the rpc-error.
>
> and add to 8.2.2:
>
>   o  Modification requests for nodes tagged with "when", and the "when"
>  condition evaluates to "false".  In this case the server MUST reply
>  with an "unknown-element" error-tag in the rpc-error.
>
>
>

This seems like a BIG protocol change to  behavior.
IMO this not an error at all.  In our server the false-when data is just
pruned, and no error is ever sent for a pruned when=false data node.

It may be a client programming error for the client to provide
false when nodes or not.  What if the client is reusing some
code that sends 5 parameters, it it's OK if 1 of them gets
pruned sometimes because of a false when (e.g, product
feature-specific knob and that feature is not installed)

BTW, this is a really good example of what not to do, if one
wants to make the YANG specification protocol independent.




> /martin
>
>

Andy


>
> > regards Balazs
> >
> > On 2015-10-13 13:30, Martin Bjorklund wrote:
> > > Balazs Lengyel  wrote:
> > >> Hello Martin,
> > >> If I had a model
> > >>
> > >> leaf a {type boolean;}
> > >> leaf b {
> > >>  when a
> > >>  type int8;
> > >> }
> > >>
> > >> if "a" is false and then you get an edit config with: set b=5 ; set
> > >> a=true
> > >> What should be the result?
> > >> A1)  this should succeed as at commit time the "when" will be true.
> > > yes.
> > >
> > >> A2) this should fail as at parsing (as described in 8.2.1 of the YANG
> > >> RFC) the when is false - yet. This would also mean that you need 2
> > >> edit-configs to set b=5.
> > >> regards Balazs
> > >
> > > /martin
> >
> > --
> > Balazs Lengyel   Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
> >
>
> ___
> 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] not a non-presence container

[William Lupton]

All,

Both RFC 6020 and the bis draft use the term "not a non-presence
container", sometimes with a reference to section 7.5.1.

Does this term mean the same as "presence container"? If so, I think it
would be easier (on the reader!) to say that instead. If not, I think that
the term warrants a mention in section 7.5.1.

Comments?

Thanks,
William Lupton
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"

[Andy Bierman]

On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen  wrote:

>
> Thank you Robert for bringing the discussion back to the github issues.
>
> Robert writes:
>
> > In particular:
> >- does it include support for templating (as per
> openconfig-netmod-opstate-01 section 7.3.)?
> >- is it allowed to represent system created objects that have no
> corresponding configuration?
> >
> > Requirement 1.D states
>
>  D.  For asynchronous systems, when fully synchronized, the data
>in the applied configuration is the same as the data in the
>intended configuration.
>
> >
> > So, if this requirement statement stands as being valid (which I think
> it should) then that would imply that the answer for both the two issues
> above must be "no".  The only question would be whether these need to be
> explicitly listed out?
>
> [KENT] so I think I have to (begrudgingly) agree with your logic.I
> have heard the operators state that they want the intended/applied
> comparison to be drop-dead simple.  To that end, it would not be possible
> to flatten templates or apply defaults, or make any other change – it needs
> to be as close as possible to a carbon-copy of the original intended
> configuration (where deviations are allowed only for cases like a missing
> line-card).  To this end, yes, I think that we could tack on a statement
> like the following:
>
> That is, the intended configuration is a subset of the applied
> configuration where omissions are only due to when the
> configuration cannot be applied (e.g., a missing line-card).
>
> What do you think?
>


I am wondering why operators would want to compare 2 massive subtrees
in the first place, where 1 is static and the other is changing constantly.

Do they really want this complex task or do they just want to
determine if the intended config has been applied yet?


Andy


>
>
> >>  - how does it relate to the state of the system after a equivalent
> synchronous config commit (if at all)?
> >>
> > Again, I think that definition of requirement 1.D, along with the
> proposed definition of synchronous configuration operation vs asynchronous
> configuration operation, will provide a sufficient answer to this
> question.  I.e. that the state of the system after an asynchronous config
> operation must, when fully synchronized, be the same as the state of the
> system after an equivalent synchronous configuration operation completes
> and replies back.
>
> [KENT] I agree with this, but I think it impacts issue #6 more so than
> issue #4 - right?
>
>
> Thanks,
> 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] opstate-reqs #4: Provide a tighter definition of "applied configuration"

[Robert Wilton]

On 14/10/2015 20:15, Kent Watsen wrote:

Andy writes:
> I am wondering why operators would want to compare 2 massive subtrees
> in the first place, where 1 is static and the other is changing 
constantly.

>
> Do they really want this complex task or do they just want to
> determine if the intended config has been applied yet?

I think that it is more the latter.   And there have been suggestions 
for solutions to provide something like a yang-patch to describe just 
the diffs.  Makes sense to me!


The NMS already knows the intended config since it sent it to the device 
in the first place, so in normal circumstances I would expect the NMS to 
only query the applied config (and possibly derived state at the same 
time) and then compare it to the NMS's view of the intended cfg for that 
device.  If the NMS is smart then it might be able to restrict most of 
the queries to only the device's applied config sub-trees that could 
possibly be out of sync, perhaps with periodic full synchronization checks.


Otherwise, I think that a function that returns just the diff may also 
be useful (the draft that I put forward also proposes a diff-cfg-only 
option).  However, it is also worth noting that the original 
requirements don't explicitly ask for this, so perhaps more of a nice to 
have than a formal requirement?


Thanks,
Rob




K.


From: Andy Bierman >
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen >
Cc: Robert Wilton >, 
"netmod@ietf.org " >
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of 
"applied configuration"




On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen > wrote:



Thank you Robert for bringing the discussion back to the github
issues.

Robert writes:

> In particular:
>- does it include support for templating (as per 
openconfig-netmod-opstate-01 section 7.3.)?
>- is it allowed to represent system created objects that have
no corresponding configuration?
>
> Requirement 1.D states

  D.  For asynchronous systems, when fully synchronized, the data
in the applied configuration is the same as the data in the
intended configuration.

>
> So, if this requirement statement stands as being valid (which I
think it should) then that would imply that the answer for both
the two issues above must be "no".  The only question would be
whether these need to be explicitly listed out?

[KENT] so I think I have to (begrudgingly) agree with your logic.
   I have heard the operators state that they want the
intended/applied comparison to be drop-dead simple.  To that end,
it would not be possible to flatten templates or apply defaults,
or make any other change – it needs to be as close as possible to
a carbon-copy of the original intended configuration (where
deviations are allowed only for cases like a missing line-card). 
To this end, yes, I think that we could tack on a statement like

the following:

That is, the intended configuration is a subset of the applied
configuration where omissions are only due to when the
configuration cannot be applied (e.g., a missing line-card).

What do you think?



I am wondering why operators would want to compare 2 massive subtrees
in the first place, where 1 is static and the other is changing 
constantly.


Do they really want this complex task or do they just want to
determine if the intended config has been applied yet?


Andy




>>  - how does it relate to the state of the system after a equivalent 
synchronous config commit (if at
all)?
>>
> Again, I think that definition of requirement 1.D, along with
the proposed definition of synchronous configuration operation vs
asynchronous configuration operation, will provide a sufficient
answer to this question.  I.e. that the state of the system after
an asynchronous config operation must, when fully synchronized, be
the same as the state of the system after an equivalent
synchronous configuration operation completes and replies back.

[KENT] I agree with this, but I think it impacts issue #6 more so
than issue #4 - right?


Thanks,
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] opstate-reqs #4: Provide a tighter definition of "applied configuration"

[Robert Wilton]

On 14/10/2015 19:00, Kent Watsen wrote:


Thank you Robert for bringing the discussion back to the github issues.

Robert writes:

> In particular:
>- does it include support for templating (as per 
openconfig-netmod-opstate-01 section 7.3.)?
>- is it allowed to represent system created objects that have no 
corresponding configuration?

>
> Requirement 1.D states
  D.  For asynchronous systems, when fully synchronized, the data
in the applied configuration is the same as the data in the
intended configuration.
>
> So, if this requirement statement stands as being valid (which I 
think it should) then that would imply that the answer for both the 
two issues above must be "no".  The only question would be whether 
these need to be explicitly listed out?


[KENT] so I think I have to (begrudgingly) agree with your logic.I 
have heard the operators state that they want the intended/applied 
comparison to be drop-dead simple.  To that end, it would not be 
possible to flatten templates or apply defaults, or make any other 
change – it needs to be as close as possible to a carbon-copy of the 
original intended configuration (where deviations are allowed only for 
cases like a missing line-card).  To this end, yes, I think that we 
could tack on a statement like the following:


That is, the intended configuration is a subset of the applied
configuration where omissions are only due to when the
configuration cannot be applied (e.g., a missing line-card).

What do you think?



>>  - how does it relate to the state of the system after a equivalent 
synchronous config commit (if at all)?

>>
> Again, I think that definition of requirement 1.D, along with the 
proposed definition of synchronous configuration operation vs 
asynchronous configuration operation, will provide a sufficient answer 
to this question.  I.e. that the state of the system after an 
asynchronous config operation must, when fully synchronized, be the 
same as the state of the system after an equivalent synchronous 
configuration operation completes and replies back.


[KENT] I agree with this, but I think it impacts issue #6 more so than 
issue #4 - right?


The original question that I was responding to was recorded in the 
description of issue #4, but I agree that this is also effectively 
covered by the proposed descriptions for #6 anyway.


Thanks,
Rob





Thanks,
Kent




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

Re: [netmod] upstate-reqs #8: ability to retrieve both op-state types together

[Robert Wilton]

Hi Kent,

I support adding this.

Thanks,
Rob


On 14/10/2015 19:56, Kent Watsen wrote:


I created this issue a little more than a week ago, but forgot to CC 
the list until now – sorry!


GitHub issue #8 (https://github.com/netmod-wg/opstate-reqs/issues/8) says:

START
On the interim call, Rob made in interesting point about 
config+operational, using BGP as an example.


Do we need to amend point 4 to allow for a method to retrieve these in 
a single operation?


OLD:

   4.  Separation of configuration and operational state data; ability
   to retrieve them independently
   A.  Be able to retrieve only the derived state aspects of
   operational state
   B.  Be able to retrieve only the non-derived state aspects of
   operational state

NEW:

   4.  Separation of configuration and operational state data; ability
   to retrieve them both together and independently
   A.  Be able to retrieve only the derived state aspects of
   operational state
   B.  Be able to retrieve only the non-derived state aspects of
   operational state
   C.  Be able to retrieve both the derived and non-derived state
   aspects of operational state together

STOP


Any objections to adding 4C?


Thanks,
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] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

[Kent Watsen]

On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"
 wrote:

>On Wed, Sep 23, 2015 at 03:03:57PM +, Kent Watsen wrote:
>> 
>> Popping the stack on this issue, the issue remains as to what to do
>>with requirement 3:
>> 
>>3.  Support for both transactional, synchronous management systems
>> as well as distributed, asynchronous management systems
>>
>
>I fail to understand 'transactional' and 'distributed' here.

I hope that these terms will be clarified on tomorrow's call.   There is
also a chance that these terms will be removed from the text altogether,
as they may be viewed as unnecessarily qualify the
synchronous/asynchronous terms.


> And
>frankly, I am not sure why the management _systems_ are classified to
>be synchronous or asynchronous - I think we are talking about
>protocols between a management system and a device.


Aye, I didn't see that before.

First off, elsewhere in the draft the term "system" is used 7 times to
refer to the device (e.g., NC/RC server).  The term "system" is otherwise
not defined.

But to your main point, we have been discussing the terms a/synchronous to
have to do with internal server processing of an edit request, but in '3'
the terms are being used to qualify a management system, which can't be
right.  I think that '3' should be rewritten to be a statement about
devices, not a statement about management systems.



>Anyway, I am not sure 3. is properly worded until someone defines
>'transactional', 'distributed', 'synchronous management systems' and
>'asynchronous management systems'.

The agenda for tomorrow's interim!  :)


Kent

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

Re: [netmod] opstate-reqs #4 (was #6: clarify impact of synchronous vs asynchronous)

[Kent Watsen]

Robert writes:

  intended configuration - this data represents the configuration
  state that the network operator intends the system to be in, and that
  has been accepted by the system as valid configuration.  This data is
  colloquially referred to as the 'configuration' of the system.

 applied configuration - this data represents the configuration
  state that the network element is actually in, i.e., the
  configuration state which is currently being being used by system
  components (e.g., control plane daemons, operating system
  kernels, line cards).

  So, is this text above acceptable, or does it need to be refined?


[hat on]

The discussion on these terms should happen on the opstate-reqs #4 thread.  
Renaming subject line to reflect that.

[hat off]

Jonathan Hansford made a suggestion to somehow clarify that the intended and 
applied configurations were limited to YANG-defined configuration data.  Maybe 
we could do this to both terms:

- this data represents the configuration...
+ YANG-defined data representing the configuration...


Also, Juergen wrote:

...we probably need to add text below the definition
of the term 'applied configuration' that acknowledges that this is
grey area and the definition of applied configuration is fuzzy here by
design.

So, perhaps something like this?

The system's ability to report applied configuration accurately may be
limited in some cases, such as when the the configuration goes through
an intermediate layer without an ability to inspect the lower layer.


Kent

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

Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Tue, Oct 13, 2015 at 03:09:34PM +0200, Ladislav Lhotka wrote:
>> 
>> > On 13 Oct 2015, at 13:01, Juergen Schoenwaelder 
>> >  wrote:
>> > 
>> > On Wed, Oct 07, 2015 at 05:37:36PM +, Kent Watsen wrote:
>> >> 
>> >> This is a notice to start a NETMOD WG last call for the document:
>> >> 
>> >> Defining and Using Metadata with YANG
>> >> http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02
>> >> 
>> >> Please indicate your support by Thursday October 22, 2015 at 9PM EDT.
>> >> We are not only interested in receiving defect reports, we are equally
>> >> interested in statements of the form:
>> >> 
>> > 
>> > I am concerned about this text:
>> > 
>> >   Annotations modify the schema of datastores and/or management
>> >   protocol messages, and may also change their semantics.  Therefore,
>> >   due care has to be exercised when introducing annotations in
>> >   network management systems in order to avoid interoperability
>> >   problems and software failures.
>> > 
>> > I think we should actually very clearly discourage annotations that
>> > modify the schema of datastores and/or management protocol messages
>> > instead of assuming all annotations are free to do so.
>> 
>> Annotations modify the schemas by definition because otherwise XML 
>> attributes, and objects in JSON encoding whose names start with "@", are not 
>> allowed.
>>
>
> For me, the schema of a datastore is the YANG data model. I do not
> want annotations that change the YANG data model of a datastore.
> Perhaps you mean something different but then the text allows multiple
> interpretations and hence it is problematic.

It depends on the definition of "schema". In any case, annotations add
some extra information that possibly might be persistent. FWIW, a RELAX
NG schema generated for datastore + annotation is different from the one
that's for datastore only.

>
> Annotations should add metadata but I think metadata must not change
> the semantics of the data model itself. I am also concerned if
> metadata changes the semantics of protocol messages. I am not

Some annotations that are of this sort, such as "inactive", have already
been discussed. The text you cited tries to explain possible pitfalls of
such annotations, but my understanding of the consensus so far has been
that it is not desirable to limit annotations to "benign" ones.

I guess the considerations are similar to extensions in general:
certain annotations may be a mandatory part of a protocol but is has
to be said in the protocol spec. This is essentially what was done for
NETCONF, and a special extension was used for defining the annotations
(XML attributes).

Lada

> interested in standards-track mechanisms that at the end increase the
> chances of interoperability problems and software failures.
>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

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

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