Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

[Phil Shafer]

Bal?zs Lengyel writes:
>https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00

[I've moved to a "deep lurker" role here, but ...]

Can we ensure this model contains a "format" leaf in the RPC's input
so that future (and proprietary) formats can be supported?   That
leaf can be an identityref that defaults to yang-patch.

Thanks,
 Phil

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

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Phil Shafer]

Juergen Schoenwaelder writes:
>Frankly, carrying the different basic modes over to 
>sounds like a mistake. Complexity for no real value.

+1

Thanks,
 Phil

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

Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[Phil Shafer]

Andy Bierman writes:
>The draft avoids discussion of any useful operations based on tags.

Nor does it really clearly say "what" is being tagged.  The absract
talks about "used to help classify and organize modules", but the
Introduction lacks any expansion on this.  There's really no clear
problem statement or a clear definition of why we need tags or what
one would use them for.

It would also be helpful to understand why "#hashtag" and the string
format ("ietf:routing", "vendor:super-duper:...") are chosen over
YANG identities.  It seems like identity naming standards and inheritance
would be good features.

Also it's not clear why these would be configurable rather that
controlled by the module author.  I'd rather have the OAM standard
YANG module say something like:

module ietf-oam {
import "ietf-category" { prefix ietf-category; }

identify ietf-oam {
base ietf-category:ietf-standard;
description "This module category represents something
 OAM related.";
}

ietf-category:module-category ietf-oam;
...
}

The draft says:

   Implementations that do not support the reset rpc statement (whether
   at all, or just for a particular rpc or module) MUST respond with an
   YANG transport protocol-appropriate rpc layer error when such a
   statement is received.

The entire idea of NETCONF/YANG is that the client _knows_ what it
can safely send instead of tossing spaghetti at the wall until
something sticks.  Avoid programming-by-error-detection, which
creates fragile infrastructure.

Use "feature" to control optional portions of a YANG module.  I'd
suggest one feature for "reset" support and another for "read-only",
since IMHO the idea of someone munging the categories of standard
modules is, well, disconcerting.

"Local" tags are not well explained.  The idea of a user/admin
tagging modules means that something is broken.  Users shouldn't
understand YANG modules.  Users use applications, some of which are
home-grown.  Is "local" appropriate for my "audit interfaces" script?

6.1 is missing the list "module-tags".

9.1 advocates putting vital information in the description string,
which is IMHO not a good idea.  We want to put as much information
in machine-readable format as possible, so I can ask ietf.org
questions like "give me a list of ietf-oam-related yang modules"
and get a nice list.

It also talks about "SHOULD" and "MAY" tags without giving any
clue as to why or when this would be appropriate or useful.

So my vote would be that this document needs some significant work
and expansion before it's a supportable draft.  I think the authors
have more in their heads than they've put into the draft and I'd
like to see the rest of their thoughts.

Thanks,
 Phil

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

Re: [netmod] revised-datastores and commonality of schemas

[Phil Shafer]

"Sterne, Jason (Nokia - CA/Ottawa)" writes:
>The  DS needs to have both the template itself in the schema as well 
>as
>whatever nodes are used to hold 'exploded' data.  But what about intended and
>operational ?

For JUNOS, we carry both the raw and expanded views, though nothing
in JUNOS is looking at the raw data outside of the UI code.  But we
carry it, so that scripts can access this information and find the
original "intent" for config.

For example, if my interface template looked like:

interfaces {
apply-macro so-0/0/0 {
inet-address 10.3.2.1/30;
role customer-facing;
}
}

and then my commit script turned this into traditional JUNOS
config, like:

interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.3.2.1/30;
filter customer-facing;
 }
 family mpls;
 family iso;
}
}
}
protocols {
bgp {
group customer-facing {
peer 10.3.2.2 {
local-address 10.3.2.1;
policy customer-facing;
...

And whatever else "customer-facing" means.

Both sets of config will be in  and  so that
when I find an interface that's down, I can look (in )
at the original apply-macro and see the role of the interface to know
how loud an alarm I should be raising.

Thanks,
 Phil

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

Re: [netmod] Action and RPC statements

[Phil Shafer]

Sorry, if I wasn't clear.  I meant the  element would
be directly under , so the system knows where to start
looking for data.  Guessing is bad.

Thanks,
 Phil


Andy Bierman writes:
>So a server will be required to guess the correct datastore until it
>finds the right one that matches the action instance?
>
>   
>   
>  
> 10
> 
>candidate
> 
>  
>
>
>
>The server will guess the datastore in some proprietary order and parse
>instances of /top/ and /top/list1.  Then it finds the  action
>and parses the input to get to the datastore and find out the real datastore
>to use.  If the server guessed wrong, then it reparses the  against
>the requested datastore.  Hopefully the schema trees match up.
>
>Will vendors do all the extra work required to support this sort of thing?
>I doubt it.
>
>
>Andy
>
>
>
>
>On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer <p...@juniper.net> wrote:
>
>> Robert Wilton writes:
>> >ii) However, as far as I can see, it doesn't make sense for an action to
>> >directly affect the contents of any configuration datastore, that should
>> >be done via a purpose built rpc (like edit-config).
>>
>> An example action would be to retrieve the  fingerprint of an ssh
>> key.  I might want to get the fingerprint of a key in 
>> before I commit it.
>>
>> Or I could have an action that sets the SNMPv3 auth key to a random
>> value, and I want to invoke that action against .
>>
>> Seems like  might also be an interesting place to target
>> actions, but I can't think of a good example.
>>
>> There are always scenarios where something is useful, and the problem
>> with ruling it out is that it becomes needed at some later point.
>> We've a habit of ruling out things and later wishing we had them.
>>
>> Is the easy fix to just put a datastore leaf under rpc/action and
>> have it default to operational?  Any specific RPC can define its
>> own datastore leaf of hard-code the database in the description
>> (explicitly or implicitly ), but the  RPC only
>> gets this if we make a new parameter for it.
>>
>> Thanks,
>>  Phil
>>
>
>--001a11411b0ad2d58d055cee96cb
>Content-Type: text/html; charset="UTF-8"
>Content-Transfer-Encoding: quoted-printable
>
>Hi,So a server will be required to gue=
>ss the correct datastore until itfinds the right one that matche=
>s the action instance?=C2=A0 =C2=A0action=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0top=C2=A0 =C2=A0 =
>=C2=A0 =C2=A0 =C2=A0 list1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
>=C2=A0 =C2=A0 =C2=A0key10/key=C2=A0 =C2=A0 =C2=
>=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0do-test=C2=A0 =C2=A0 =C2=
>=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datastorecandidate/datas=
>tore=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/do-=
>test=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /list1<=
>div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /top=C2=A0 =C2=A0 /a=
>ctionThe server will guess the datastore in s=
>ome proprietary order and parseinstances of /top/ and /top/list1=
>.=C2=A0 Then it finds the do-test actionand parses the i=
>nput to get to the datastore and find out the real datastoreto u=
>se.=C2=A0 If the server guessed wrong, then it reparses the action =
>againstthe requested datastore.=C2=A0 Hopefully the schema trees=
> match up.Will vendors do all the extra work requ=
>ired to support this sort of thing?I doubt it.iv>Andyiv>On Tue, O=
>ct 31, 2017 at 11:36 PM, Phil Shafer o:p...@juniper.net" target=3D"_blank">p...@juniper.net wrote=
>:ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:
>ii) However, as far as I can see, it doesnt make sense for an acti=
>on to
>directly affect the contents of any configuration datastore, that shoul=
>d
>be done via a purpose built rpc (like edit-config).
>
>An example action would be to retrieve the=C2=A0 fingerprint of an ssh
>key.=C2=A0 I might want to get the fingerprint of a key in candidate=
>;
>before I commit it.
>
>Or I could have an action that sets the SNMPv3 auth key to a random
>value, and I want to invoke that action against candidate.
>
>Seems like startup might also be an interesting place to target
>actions, but I cant think of a good example.
>
>There are always scenarios where something is useful, and the problem
>with ruling it out is that it becomes needed at some later point.
>Weve a habit of ruling out things and later wishing we had them.
>
>Is the easy fix to just put a datastore leaf under rpc/action and
>have it default to operational?=C2=A0 Any specific RPC can define its
>own datastore leaf of hard-code the database in the description
>(explicitly or implicitly operational), but the action RPC =
>only
>gets this if we make a new parameter for it.
>
>Thanks,
>=C2=A0Phil
>
>
>--001a11411b0ad2d58d055cee96cb--

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

Re: [netmod] Action and RPC statements

[Phil Shafer]

Robert Wilton writes:
>ii) However, as far as I can see, it doesn't make sense for an action to 
>directly affect the contents of any configuration datastore, that should 
>be done via a purpose built rpc (like edit-config).

An example action would be to retrieve the  fingerprint of an ssh
key.  I might want to get the fingerprint of a key in 
before I commit it.

Or I could have an action that sets the SNMPv3 auth key to a random
value, and I want to invoke that action against .

Seems like  might also be an interesting place to target
actions, but I can't think of a good example.

There are always scenarios where something is useful, and the problem
with ruling it out is that it becomes needed at some later point.
We've a habit of ruling out things and later wishing we had them.

Is the easy fix to just put a datastore leaf under rpc/action and
have it default to operational?  Any specific RPC can define its
own datastore leaf of hard-code the database in the description
(explicitly or implicitly ), but the  RPC only
gets this if we make a new parameter for it.

Thanks,
 Phil

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

Re: [netmod] XPath node type tests

[Phil Shafer]

Andy Bierman writes:
>I think text() and node() are just filter tests.
>
>  /foo/*[text()] would return all the child nodes of /foo that are leaf or
>leaf-list
>
>text() returns a boolean (0 or 1).  Do not use it for value testing:
>
>  /foo/*[text() =3D 'fred']  // wrong!
>
>  /foo/*[. =3D 'fred']  // correct

I haven't looked at the spec, but this isn't true for libxml2/libxslt/libslax:

(sdb) n
4: var $foo :=  {  "one";  "two"; }
(sdb) n
2: main  { }
(sdb) p $foo
[node-set] (1) rtf-doc

  one
  two



(sdb) p $foo/*
[node-set] (1)

  one
  two


Outside predicates, it's a node test, matching text nodes:

(sdb) p $foo/*/text()
[node-set] (0)

(sdb) p $foo/*/*/text()
[node-set] (2)
one
two

But inside predicates is does return the text, probably like string():

(sdb) p $foo/*/*
[node-set] (2)
one
two

(sdb) p $foo/*[text() == 'one']
[node-set] (0)

(sdb) p $foo/*/*[text() == 'one']
[node-set] (1)
one

It could be just a bug in libxml2;  I'll take a look.

Thanks,
 Phil

P.s.: the command line I used was:

   slaxproc -d -m 'main  { }' -E -m 'var $foo :=  {  "one"; 
 "two"; }'

The ":=" operator turns RTFs into node-sets (via calling node-set()).

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

Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive

[Phil Shafer]

Andy Bierman writes:
>But this means if any clients use the disable-node feature then all clients
>need to know about the feature as well, or they will mistake these nodes
>for enabled nodes (i.e., plain configuration according to the standard) .

The alternative would be removing inactive config from normal
 results, which means that a save/restore would be
discarding inactive config, which isn't acceptable.  Better to give
all data than to risk discarding anything.

Thanks,
 Phil

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

Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive

[Phil Shafer]

"t.petch" writes:
>Inactive appears a dozen times but is not defined, except in the course
>of those appearances it effectively is, but is sometimes 'inactive',
>sometimes 'inactive configuration', sometimes 'inactive data'.

Agree.  Consistent terms are good things.

>I would find it clearer if the term was used consistently and if there
>was an explicit definition amongst the other definitions in section 2
>such as
>
>inactve configuration: Configuration that is present in  which
>is not in use by the device and which plays no part in validation.  It
>cannot appear in any other datastore.

Inactive configuration should be allowed in  and ,
as well as in dynamic datastores.  It's hard to put constraints on
a facility that we're really not defining.

>The protocols that are currently
>standardised do not support inactive configuration but a number of
>proprietary protocols do.

In JUNOS, we use the standard protocols but encoded these as
non-standard attributes.

>Inactive configuration is only exposed to
>clients that indicate support for inactive configuration; clients not
>indicating support for  inactive configuration receive the contents of
> with the inactive configuration removed.

This is also not true for our implementation.  If you 
on any datastore that contains inactive data, you'll receive
that data.

Thanks,
 Phil

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

Re: [netmod] FW: Regarding IPR on draft-ietf-netmod-revised-datastores-04

[Phil Shafer]

Kent Watsen writes:
>The NETMOD chairs need your on-list response to this email.
>- all the other authors have already replied...

I know of no IPR related to this draft.

Thanks,
 Phil

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

Re: [netmod] nmda-guidelines-01: value space for config vs state

[Phil Shafer]

Mahesh Jethanandani writes:
>What happens if I have a 'must' statement that is written for
>validating configuration? Will it be enforced on operational datastore?

The last paragraph of 4.7 of the NMDA draft talks about constraints
in operational:

   As a result of remnant configuration, the semantic constraints
   defined in the data model cannot be relied upon for ,
   since the system may have remnant configuration whose constraints
   were valid with the previous configuration and that are not valid
   with the current configuration.  Since constraints on "config false"
   nodes may refer to "config true" nodes, remnant configuration may
   force the violation of those constraints.  The constraints that may
   not hold include "when", "must", "min-elements", and "max-elements".
   Note that syntactic constraints cannot be violated, including
   hierarchical organization, identifiers, and type-based constraints.

So constraints like value space (since the are type-based) cannot
be violated.

IMHO there are few cases where the value spaces differ and those
must be modeled with dual leafs.  This is unfortunate, but is better
than forcing dual leafs on all situations.  As mentioned in the
future we can make a YANG extension statement to tie the two leafs
together.

Thanks,
 Phil

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

Re: [netmod] datastore conformance

[Phil Shafer]

Andy Bierman writes:
>The YANG definitions defined for NETCONF and RESTCONF operations do not 
>actually
>require the "real" datastore identities to be used by a server.

The identities are defined in the YANG modules contained in the
NMDA draft (draft-ietf-netmod-revised-datastores).  The protocol-specific
drafts (draft-dsdt-nmda-netconf and draft-dsdt-nmda-restconf)
describe protocols operations that use these identities, such as
the  parameter to .  The YANG library draft
(draft-ietf-netconf-yang-library) allows the server to indicate
which datastores are supported.

>The server implementor
>has the freedom to replace all of the standard datastores with proprietary 
>definitions.

Yes.  The implementation can also choose not to support any
conventional datastores, allowing only, say, some new dynamic
datastore.  Clients can learn this via YANG Library.

In the end, I've confidence that the market place will give limited
success to servers that make funky and weird choices.  We all
understand that most-common behaviors are most desirable, but forcing
a limit on such things is imho counter productive.

>While this provides unlimited flexibility for the server, it also provides 
>unlimited
>complexity for the client.

"unlimited"?

>I think the existing :candidate, :writable-running, and :startup capabilities 
>cover
>the standard conventional datastores.

Yes, these capabilities allow a client to know that a server supports
a datastore, but not what it can contain.  It's not sufficient
information.  The client needs the YANG library information to
have meaningful interaction with a server.

>IMO the MUST be a new capability for the :operational datastore and the
>exact identityref and semantics for this datastore MUST be supported
>if the :operational:1.0 capability is advertised.

What does a new capability give that YANG library does not?

I don't follow the bit about "the exact identityref and semantics
for this datastore".  Is your concern that I could make a follow-on
to  that derives from the operational identity?

>Both NETCONF and RESTCONF can list capabilities so both protocols can advertise
>this capability URI.

Same for YANG Library, right?

Thanks,
 Phil

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

Re: [netmod] nmda-guidelines-01: value space for config vs state

[Phil Shafer]

"Sterne, Jason (Nokia - CA/Ottawa)" writes:
>   OK - so the same leaf (in the schema) has the same value space in the
>   conventional datastores and in the operational datastore.  That probably
>   makes sense since a single schema describes the model for that leaf
>   whether it is accessed in conventional DSes or the operational DS.
>
>   But I think that also means that *if* you need slightly different value
>   spaces for an item, then you'll need to split it into multiple leafs in
>   the schema.

Absolutely.  Do we need to call this/these scenarios out directly
in the NMDA draft?  Or is this more of an FAQ item?

Thanks,
 Phil

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

Re: [netmod] XPath questions about revised datastores

[Phil Shafer]

Andy Bierman writes:
>It has always been OK for a config=false data node's XPath expression to
>point at a config=true data node.
>But this has always meant the configured value. RD changes this behavior
>because the new opstate datastore
>contains only the operational values of config=true nodes. Now there is no
>way for such an XPath expression
>to test the configured value.

The XPath will refer to the current operational value, which is
better defined and more consistent behavior.  During the lack when
data is flowing between  and  as system
components read and follow new incoming configuration data, the
operational value should be guiding the constraints, not the
unrealized incoming value.

The XPath continues to work in a backwards compatible manner, but
the outcome is more crisply defined and the  datastore
will have better odds of being self-consistent.

Thanks,
 Phil

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

Re: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-02.txt

[Phil Shafer]

Andy Bierman writes:
>I think the remnant configuration text needs clarification.
>I thought the whole point of the operational datastore for config=true
>nodes was to
>provide the intended and applied values using the exact same
>instance-identifier.

Instance names are the same.  Remnant configuration is data that
remains in operational use (and is reported in ) after
it has been removed from .  This is typically the brief
period during implementation of the incoming data.  The text says:

  - remnant configuration: Configuration that remains part of the
applied configuration for a period of time after it has been removed
from the intended configuration or dynamic configuration.  The time
period may be minimal, or may last until all resources used by the
newly-deleted configuration (e.g., network connections, memory
allocations, file handles) have been deallocated.

There's also text in the "The Operational State Datastore" section
(quoted below).  What is needed to make it more clear?

>NC/RC/YANG does not allow the old operational value and new operational
>value to
>exist in the same datastore.  Once the server has the new value to report,
>it will overwrite
>the old value.

 should report the currently in use values, even when
that differs from .  The draft currently says:

  As a result of remnant configuration, the semantic constraints defined
  in the data model cannot be relied upon for , since the
  system may have remnant configuration whose constraints were valid
  with the previous configuration and that are not valid with the
  current configuration.  Since constraints on "config false" nodes may
  refer to "config true" nodes, remnant configuration may force the
  violation of those constraints.  The constraints that may not hold
  include "when", "must", "min-elements", and "max-elements".  Note that
  syntactic constraints cannot be violated, including hierarchical
  organization, identifiers, and type-based constraints.

>Perhaps you mean other instances will be considered old, but the RD
>solution has no way to
>correlate the new instances to the old ones.
>Therefore, YANG validation may
>fail on the operational
>datastore while updates are being applied. I think the draft should make
>this more clear.

Yes,  will be have circumstances where it's contents
will not be valid.  It's better that the box provide accurate data
than provide valid data that is not accurate.  So we say that while
syntactic constraints cannot be violated, semantic constraints can
be.

Thanks,
 Phil

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

Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00

[Phil Shafer]

Andy Bierman writes:
>IMO it is more robust not to assume people never see the real YANG
>statements.

Exactly.  We made YANG readable so that we wouldn't _need_ to view
it using tools.  This was one of the "insta-death" factors for UML.

Thanks,
 Phil

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

Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00

[Phil Shafer]

Ladislav Lhotka writes:
>leaf foo {
>description "This is my *favourite* leaf.";
>type string;
>}
>
>you may not like it, but it is absolutely legal and IMO also readable by 
>humans. As William previously mentioned, some communities are already doing 
>similar things. The principal aim of my I-D is to allow module authors to 
>explicitly state that they adhere to some rules, which helps authors of tools 
>reduce guesswork.

1) I think there's a difference between people using our ancient
ascii-based conventions that help the reader grok the author's
meaning, and supporting markdown (plus other syntaxes) that allow
ascii documents to produce HTML.

2) It's not something where one can say "don't use it if you don't
like it", because we will have to read these description statements
for review, etc.

3) Markdown is a class of tools, not a common tool.  CommonMark
works to standardize this, but I've no clue how "common" it is.

4) Consider that github supports >9 formats.  Are we expecting
readers/reviewers to become knowledgable about each of these?

Thanks,
 Phil

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

Re: [netmod] Interaction of 'when' and 'default' statements

[Phil Shafer]

William Ivory writes:
>Yes, I'd noticed that.  Does this make the behaviour 'undefined' in YANG 1.0?

No, this was a clarification.  The text in 6020 was reasonably clear:

   The "when" statement makes its parent data definition statement
   conditional.  The node defined by the parent data definition
   statement is only valid when the condition specified by the "when"
   statement is satisfied.

And no default should be provided for any invalid node.  If the node
can't exist, the default can't either.

Thanks,
 Phil

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

Re: [netmod] tree diagrams - flags

[Phil Shafer]

Phil Shafer writes:
>Juergen Schoenwaelder writes:
>>   is one of:

Apologies.  My brain's still in "low".

Thanks,
 Phil

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

Re: [netmod] tree diagrams - flags

[Phil Shafer]

Juergen Schoenwaelder writes:
>   is one of:
>rw  for configuration data
>ro  for non-configuration data

Given that these are really "config true" and "config false" and
that ephemeral data may well be writable and "config false", should
we change the names?  Writable read-only data would be a mistake.
"ct" and "cf"?  "c" and "-"?

Thanks,
 Phil

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

Re: [netmod] security considerations boilerplate updates to cover RESTCONF

[Phil Shafer]

The considerations should say more about how we delegate encryption
and authentication to the underlaying protocols, whatever they may
be.  We don't need details, just an understanding of the role of
each layer.

Thanks,
 Phil


Kent Watsen writes:
>
>A couple comments:
>
>1) drilling down on the mandatory-to-implement NC/RC protocols
>   is somewhat missing the point.  The important bit is that
>   *all* protocols transporting YANG-modeled data *only* have
>   secure transport layers.  More specifically, YANG-modeled
>   data may be transported over other protocols (e.g., coap),
>   and also one of the protocols have an insecure transport
>   protocol (e.g., it doesn't much help to talk about HTTPS
>   being mandatory-to-implement if RESTCONF allowed HTTP).
>
>2) just stating that there are secure transport layers still
>   isn’t sufficient, as these protocols must also require
>   mutual authentication in order to be secure, and for 
>   statements regarding NACM to make sense.  The text I posted
>   before had a statement like this in it.  
>
>I'm beginning to become a fan of the idea of defining a generic
>"Requirements for Protocols Transporting YANG-modeled Data"
>document - that would not only discuss security aspects, but
>also generic protocol operations, that documents like NC, RC,
>CoAP, etc. can point to...and even YANG (RFC 7950), rather than
>pointing directly at NETCONF as it does today...
>
>Kent // contributor
>
>
>On 3/16/2017 8:56 AM, Juergen Schoenwaelder wrote:
>> On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote:
>>> Latest proposal:
>>>
>>>  The YANG module defined in this document is designed to be accessed
>>>  via network management protocols such as NETCONF [RFC6241] or
>>>  RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
>>> layer,
>>>  and mandatory-to-implement secure transport is Secure Shell (SSH)
>>> [RFC6242],
>>>  while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement
>>> secure
>>>  transport is Transport Layer Security (TLS) [RFC5246].
>> Picking wording from Section 12 of RFC 8040 to replace your second
>> sentence I get this:
>>
>>  The YANG module defined in this document is designed to be
>>  accessed via network management protocols such as NETCONF
>>  [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the
>>  secure transport layer, and the mandatory-to-implement secure
>>  transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF
>>  layer is HTTPS, and the mandatory-to-implement secure transport is
>>  TLS [RFC5246].
>>
>>  The NETCONF access control model [RFC6536] provides the means to
>>  restrict access for particular NETCONF or RESTCONF users to a
>>  pre-configured subset of all available NETCONF or RESTCONF
>>  protocol operations and content.
>Yes, thank you.
>
>Regards, B.
>>
>> /js
>>
>
>
>
>___
>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] augment and if-feature

[Phil Shafer]

Robert Wilton writes:
>> But I don't think it can be done in an errata.
>Does this just leave the behaviour as undefined then? I.e. it is up to 
>the implementation to decide whether they error the augmentation.

Which is an unacceptable outcome.  Errata are an acceptable
means of addressing this.  We are not fixing a protocol design
error, but repairing a missing scenario.

   A savvy implementer of the specification can often, but not always,
   figure out what was intended by the RFC as published, but technical
   errors should be announced somehow.

In this case, the spec says nothing about an odd but interesting
scenario.  I don't think this requires a new version of the protocol,
just a clarification.

Thanks,
 Phil

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

Re: [netmod] augment and if-feature

[Phil Shafer]

Martin Bjorklund writes:
>It explicitly says that server's *implementation* of the augmented
>module contains the additional nodes.
>
>If you don't advertise a certain module, I don't think you can claim
>that your implementation contains that module.

The issue is that the module is advertised/implemented/supported
but a feature of that module is not.  If an module is also
advertised/implemented/supported, is that module's author
forced to repeat the if-feature conditionals for the first
module?  I think this is a bad idea/design/precedent, and
makes life harder.

>And similarly, if you don't advertise a feature, I don't think you can
>claim that your implementation implements nodes that are conditional
>on that feature.

You certainly can.  Consider the "feature local-storage" from
the spec, where this feature indicates availability of local
storage.  The feature may be conditionally advertised, based
on the presence of an SD card.

But that's not even what the spec says.  It's more narrow:

>  When a server implements a module containing an "augment" statement,
>  that implies that the server's implementation of the augmented module
>  contains the additional nodes.

The "additional nodes" it's talking about are the _new_ nodes from
the augmentation, not the original modules nodes.

I think this is a case we did not consider previously and we should
find a suitable answer and document it as errata, rather than leave
it hanging in the breeze.

Thanks,
 Phil

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

Re: [netmod] augment and if-feature

[Phil Shafer]

Martin Bjorklund writes:
>Phil Shafer <p...@juniper.net> wrote:
>> Martin Bjorklund writes:
>> >> What are your thoughts on this? Surely, an augment should not have to
>> >> contain if-feature statements of all parents of the augmented node.
>> >
>> >The spec says:
>> >
>> >   When a server implements a module containing an "augment" statement,
>> >   that implies that the server's implementation of the augmented module
>> >   contains the additional nodes.
>> >
>> >Compare with a simple augment of a node w/o an if-feature.  In this
>> >case, if the server implements the augmenting module, it MUST also
>> >implement the augmented module.
>> 
>> It implements the module, but it doesn't implement the nodes
>> since it doesn't express the feature.  IMHO this is a tool
>> bug and/or an errata,since otherwise one has to carry features
>> forward, repeating the if-feature using the original modules
>> prefix:feature-name on every augment of feature-based nodes.
>
>Well, I agree that it would have been better to state that if a server
>doesn't implement the augment target, then it doesn't implement the
>augment either.  But the text is pretty clear; this is not how it
>works.  This is not appropriate to "fix" in an errata.

I'm missing the part of the text that's clear.  The above quoted
section certainly doesn't say this.  That text is saying "if you
implement a module that augments a set of nodes, then the server's
schema for that original set of nodes now includes the new set of
nodes".  It's referring to schema nodes.

And if those schema nodes are conditional based on if-feature, then
those nodes are still in the schema, but are not supported by a
server unless the if-feature condition evaluates to true.

I don't see a conflict, it's just a case that we didn't think about
or write about.  It's a case that's not clearly handled in the spec,
for which reasonable implementations can disagree.  That's a bug
in the spec and it that can be clarified via errata.

Thanks,
 Phil

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

Re: [netmod] augment and if-feature

[Phil Shafer]

Martin Bjorklund writes:
>> What are your thoughts on this? Surely, an augment should not have to
>> contain if-feature statements of all parents of the augmented node.
>
>The spec says:
>
>   When a server implements a module containing an "augment" statement,
>   that implies that the server's implementation of the augmented module
>   contains the additional nodes.
>
>Compare with a simple augment of a node w/o an if-feature.  In this
>case, if the server implements the augmenting module, it MUST also
>implement the augmented module.

It implements the module, but it doesn't implement the nodes
since it doesn't express the feature.  IMHO this is a tool
bug and/or an errata, since otherwise one has to carry features
forward, repeating the if-feature using the original modules
prefix:feature-name on every augment of feature-based nodes.

Thanks,
 Phil

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

Re: [netmod] rfc 6087bis - stress importance of instance examples

[Phil Shafer]

+1.

As someone who does internal code review for Juniper changes, having
an example is a huge help to the reviewer (me).  It also helps to
convince the module author (them) that what they are advocating
will look horrible.

Thanks,
 Phil



Juergen Schoenwaelder writes:
>Hi,
>
>my experience is that when writing YANG modules it is tremendously
>helpful to focus on the instance documents. I find it essential to
>write down example snippets of instance documents to see whether they
>look elegant or clumsy. This is often not easy to determine from just
>reading a YANG model, in particular if groupings are involved. Examples
>help so much - you can easily spot whether the usage of singular or
>plural is reasonable in your names, whether you have redundancy in
>your names, whether the overall organization is effective. Even better,
>we have tools that can validate the examples so we can even be sure
>the examples are correct. (And if you do not know whether you got
>your pattern statement right, well, one way is to write examples.)
>
>I think we should encourage authors to write examples. It will help
>them to create better models and it will help reviewers tremendously
>while reviewing models. Good examples will also help users to get
>started.
>
>/js (who apparently is doing some heavy YANG reviewing work today)
>
>-- 
>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

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

Re: [netmod] Does the YANG "status" statement inherit from its parent node?

[Phil Shafer]

Robert Wilton writes:
>Wouldn't you just write this without the back reference to the 
>deprecated/obsolete leaf.
>E.g. wouldn't the following be sufficient to enforce the desired constraint?
> leaf old-stuff {
> status deprecated;
> must not(../new-stuff);
> }
> leaf new-stuff {
> }

Very True.  But imagine if the deprecated bits are in one module
and the new-stuff is in another.  The old-stuff cannot refer to the
new-stuff.

Thanks,
 Phil

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

Re: [netmod] top-level mandatory nodes

[Phil Shafer]

Andy Bierman writes:
>mandatory for config=false means it must exist in an  for a 
>operation retrieval.  It is by definition "server-supplied", so there is no
>server validation to worry about.
>
>YANG constraints are used on clients.
>Not that we are super-server-centric here, but client software
>uses YANG, not just server software.

I must be missing your meaning here.  Can you please give a
use case for when the data modeler would use "mandatory true"
for a "config false" top-level node?

Thanks,
 Phil

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

Re: [netmod] top-level mandatory nodes

[Phil Shafer]

I was really looking for a use case.  What's is a specific scenario
where one would want a device to always report data even when there
is no interesting data to report (since interesting data would mean
the device would want to report it)?

I've seen this misused where the modeler wants the device to say
"I've got no TLA data", where the model should be happy that being
implicit in the lack of data.

Thanks,
 Phil



Alex Campbell writes:
>The purpose of a mandatory config=false node is to say that the data is 
>_always_ needed.
>
>In the case where the node is also top-level, if your server fails to provide 
>that data,
> then your server is not compliant with the YANG.
>
>If the data is sometimes not needed, then the module author should not have 
>marked it as
> mandatory.
>
>Alex
>
>
>From: netmod <netmod-boun...@ietf.org> on behalf of Phil Shafer 
><p...@juniper.net>
>Sent: Thursday, 19 January 2017 10:35 a.m.
>To: Ladislav Lhotka
>Cc: NETMOD WG
>Subject: Re: [netmod] top-level mandatory nodes
>
>Ladislav Lhotka writes:
>>>> 6087bis says in sec. 5.10:
>>>>  Top-level database data definitions MUST NOT be mandatory.
>>Right - I think the following should do:
>>OLD
>>  Top-level database data definitions MUST NOT be mandatory.
>>NEW
>>  Top-level data nodes that represent configuration MUST NOT be mandatory.
>
>[old news, but...]
>
>I guess I'm missing the use case for mandatory top-level config=false
>data models.  Can you please describe one?  I imagine that just because
>my device implements a non-config data model, I should not be forced
>to generate data for it when/if that data is not needed.  What's the
>scenario where I need to be forced to make this data?
>
>Thanks,
> Phil
>
>___
>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] Does the YANG "status" statement inherit from its parent node?

[Phil Shafer]

Martin Bjorklund writes:
>But marking definition as obsolete in one module cannot automatically
>make definitions in *other* modules obsolete.
>
>(*) _maybe_ 7950 can be interpreted in this way when it says:
>
>   If a definition is "current", it MUST NOT reference a "deprecated" or
>   "obsolete" definition within the same module
>
>If you're in a good mood, you could argue that a child always
>"references" its parent.

That's a massively deforming interpretation of "references".

I'm not even sure this is a good rule at all.  Consider:

leaf old-stuff {
status deprecated;
must not(../new-stuff);
}
leaf new-stuff {
must not(../old-stuff);
}

My new-stuff definitely references old-stuff which is deprecated,
but this is a _good_ data model and should not be "MUST NOT"d out
of existence.

Thanks,
 Phil

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

Re: [netmod] top-level mandatory nodes

[Phil Shafer]

Ladislav Lhotka writes:
>>> 6087bis says in sec. 5.10:
>>>  Top-level database data definitions MUST NOT be mandatory.
>Right - I think the following should do:
>OLD
>  Top-level database data definitions MUST NOT be mandatory.
>NEW
>  Top-level data nodes that represent configuration MUST NOT be mandatory.

[old news, but...]

I guess I'm missing the use case for mandatory top-level config=false
data models.  Can you please describe one?  I imagine that just because
my device implements a non-config data model, I should not be forced
to generate data for it when/if that data is not needed.  What's the
scenario where I need to be forced to make this data?

Thanks,
 Phil

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

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

[Phil Shafer]

Robert Wilton writes:
>> The server is buggy if it is sending data that violates YANG constraints.
>> If any of these statements need to be different for config and oper
>> then the old style YANG has to be used instead.
>You just have a separate state leaf.  These are still allowed in a 
>combined tree.

We're trying to avoid a "separate state leaf" solution.  That's imho
the motivation for this whole exercise.

Thanks,
 Phil

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

Re: [netmod] Tacacs and YANG

[Phil Shafer]

Balazs Lengyel writes:
>We already have a radius model part in ietf-system; but are there any 
>plans to develop a TACACS+ model for YANG?
>
>How widely is TACACS+ used for remote authorization/accounting ? As an 
>outsider I would guess that remote authorization could really slow down 
>processing e.g. a big CLI script.

We use have clients using it.  Our fix for performance is to pre-load
regex-based constraints (from both radix and tacacs+ servers) to allow
pre-authorization of commands.  This also works during intermittent
networkings issues, which is vital for networking gear (assuming one
can do the initial login/pre-load operations).

Thanks,
 Phil

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

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

[Phil Shafer]

Ladislav Lhotka writes:
>Which doesn't mean that inconsistent (format of) state data is
>acceptable. My colleague develops a BGP looking glass, and it is
>really a terrible work because he has to do a lot of screen-scraping.
>Each time a vendor changes the data format, he has to update his
>software. I keep telling him that our nice protocols would save him
>from this drudgery.

This exact scenario was the motivation for our XML API all those
years ago.  Your colleague should be happy using a NETCONF/YANG-based
solution.

Thanks,
 Phil

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

Re: [netmod] Regarding IPR on draft-nmdsdt-netmod-revised-datastores

[Phil Shafer]

Lou Berger writes:
>"No, I'm not aware of any IPR that applies to this draft"

No, I'm not aware of any IPR that applies to this draft

Thanks,
 Phil

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

Re: [netmod] comments on revised-datastores-00

[Phil Shafer]

Ladislav Lhotka writes:
>So let's say we have a list with min-elements = 1 (such as the list of RIBs), 
>and there 
>is already one entry provided by the system. what has to be done in order to 
>make ded> valid? Should the system-controlled entry permeate up to ?

We should update the draft to make it clear to allow system-controlled
data to appear as part of the template/expansion activity so that
such data can be referred to from the running config.  For example,
a static route could have a next-hop of a system-defined lo0.  Not
that this is a good idea, but...

Thanks,
 Phil

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

Re: [netmod] RFC 8022 on A YANG Data Model for Routing Management

[Phil Shafer]

"Acee Lindem (acee)" writes:
>It may take more than one to reach consensus

It's sure to be a "rough consensus" ;^)

Great work gents!

Thanks,
 Phil

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

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-10.txt

[Phil Shafer]

>Title   : A YANG Data Model for Syslog Configuration

I've a few questions:

- The description says that the "facility/no-facility" case/leaf
is used "o effectively disable a particular log-action".  Why not
make an explicit "disable" leaf instead?  Using no-facilities like
this is confusing.

- Why use an explicit/mandatory selector node instead of making
this implicit, with the lack of a selector meaning match all?

- compare-op: we've always tried to use full words; would this be
better as "compare-operation" or just "compare"?

- equals-or-higher: you might want to explain that this is the
default even in the absence of the "select-sev-compare" feature.
(I'm assuming this is true.)

- You use "facility" as both a case and a list under selector-facility.
This seems confusing and misleading.

- "structured-data": says "describes how log messages are written
to the log file" but it applies to more than log files.

- Consider making "syslog-sign" into "signing-options" or something
similar, to be more clear.  The "syslog-" prefix is not needed,
since the reader knows we are talking about syslog, and the "sign"
is not clear.  Then you can remove the "sig-" prefix on the child
nodes.

- The "session" name is not clear, since there are many sort of
sessions; would "local-users" be better?

- What purpose for the "actions" container serve?  Can it be removed?

- "buffer" should be a feature, since many platforms do not implement it.

- How does an implementation specify the set of valid characters usable
for user names?

- Many networking devices have special tags at the front of their
messages, indicating the specific message.  For example "%ASA-1-104001"
in IOS, or "BGP_CEASE_PREFIX_LIMIT_EXCEEDED" in JUNOS.  We carry
these are specific SD-PARAMS when SD is used.  Is there a way to
filter using theses tags, or more generic SD-PARAMS?

Thanks,
 Phil

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

Re: [netmod] RFC 7950 on The YANG 1.1 Data Modeling Language

[Phil Shafer]

Martin Bjorklund writes:
>See Section 1.1 (Summary of Changes from RFC 6020)

I may be missing something but it says:

o Allow "choice" as a shorthand "case" statement (see
  Section 7.9.2).

which is definitely in 6020.

Thanks,
 Phil

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

Re: [netmod] RFC 7950 on The YANG 1.1 Data Modeling Language

[Phil Shafer]

rfc-edi...@rfc-editor.org writes:
>A new Request for Comments is now available in online RFC libraries.
>RFC 7950
>Title:  The YANG 1.1 Data Modeling Language 

I don't see a "changes since YANG-1.0" section.  Is this information
recorded somewhere?

Thanks,
 Phil

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

Re: [netmod] entity naming question

[Phil Shafer]

Juergen Schoenwaelder writes:
>I believe it is worth to move to a terminology
>that is far easier to understand and use; as long as the relationship
>to the old MIB modules is clearly documented we are fine I think.

+1

Thanks,
 Phil

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

Re: [netmod] YANG 1.1: XML naming restriction

[Phil Shafer]

Ladislav Lhotka writes:
>If it is still possible, it would IMO make a good sense to remove that comment 
>from the 
>ABNF in 6020bis, and make this change in sec. 7.1.4:
>
>OLD
>
>   A prefix is an identifier (see Section 6.2).
>
>NEW
>
>   A prefix is an identifier (see Section 6.2), and it MUST NOT be the string 
> "xml".

Should it call out "xmlns" also?

The original "xml" prohibition likely dates from JUNOS, where we
encoded insert requests using the identifier name as the attribute
(not yang:key), so element names followed the same rules as attributes.

http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/configuration/junos-xml-protocol-configuration-data-elements-reordering.html



 
value-for-moving-object 
value-for-moving-object 
 



Thanks,
 Phil

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

[Phil Shafer]

Kent Watsen writes:
>If a line card is missing, then (as I understand it), the server would not
>wait for the line-card to show up.  That said, if the client requested
>transactional/atomic update, a missing line-card would cause an immediate
>failure/rollback.

We have to avoid the scenario when a box boots with a missing FRU.
In past model has always been that missing hardware does not cause
a configuration to fail validity checks.  This is enforced by the
inability of config=true constraints from referring to config=false
nodes.

Thanks,
 Phil

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

[netmod] opstate-reqs: terminology

[Phil Shafer]

Semi-in-reply-to: <560aa471.3050...@cisco.com>

I keep thinking the terms in the draft somewhat confusing.  Okay,
confusing isn't exactly right.  I find the terms have a lot of
background that needs to be explained that's not obvious from the
simple explanations in the draft.  The reader will see these terms
and think they know what they mean without that deeper understanding.

For example:

   o  applied configuration - this data represents the state that the
  network element is actually in, i.e., that which is currently
  being run by particular software modules (e.g., the BGP daemon),
  or other systems within the device (e.g., a secondary control-
  plane, or line card).

This says nothing about how the current state relates to the
configuration.  The term "applied configuration" would imply that
this state is driven by configuration, but there's really nothing
here addressing that.  Does config for interfaces that don't exist
appear in AC?  Do implicit peers appear along side explicitly
configured ones?

Likewise:

   o  derived state - this data represents information which is
  generated as part of the system's own interactions.  For example,
  derived state may consist of the results of protocol interactions
  (the negotiated duplex state of an Ethernet link), statistics
  (such as message queue depth), or counters (such as packet input
  or output bytes).

There's nothing that clearly delineates DS from AC.  The switch
from "state" to "information" doesn't really add anything concrete.
Why is AC state but DS information?

How does one decide which category any particular leaf belongs in?
Does "protocol interactions" include ospf peers, their status, and
learned routes?  Is this the same for both explicitly configured
peers and unconfigured peers (set protocols ospf interface ge-0/0/0)?

I wouldn't have thought duplex as derived state, given that I can
configure a value for it.

Would it be better to think of these values in three sets?

A) values given explicitly by the user (== IC == running config)
B) current values which use organization identical to (A)
C) current values which are not organized identical to (A)

I think the real key is that values which _can_ be organized by the
data models used in (A) _should_ use identifical organization in (B).
When I read openconfig, that seems to be their real requirement.

So if (A) has duplex or OSPF peers or interfaces, then (B) will
list duplex state, peer state, and interface state using an identical
organization (in terms of parentage or containers, lists, and keys).

Once the concepts are clear, selecting terminology should be easier.
I'd actually prefer terms like "primary state" and "secondary state"
which force the reader to look up their meaning to terms like
"derived state" which the reader will likely assume they know the
meaning of.  Clean terms really help with understanding and discussions
especially when the audience grows beyond the key players active
here.

Should a request for better terms be a new, distinct issue?

Andy B. writes:
>> I do not agree at all that the running datastore means anything other
>> than the intended confg.   A new operation is needed to retrieve
>> the active config vs. the intended config.

Do we have a definition for "active config"?  Is this running config
or the parts of AC that are fed by IC?

Robert Wilton writes:
>If the running datastore only ever means intended config, then I think 
>that would imply:
>
>  - existing NETCONF servers should reply immediately after the config 
>has been semantically verified + written to the config subsystem before 
>the configuration is applied.

The running datastore is definitely only intended config.

My question is what "the configuration change MUST also be applied
in the system" means in a world of a hundred FRUs with a zillion
chips.  Does an "applied" MTU mean it hits the kernel, the embedded
FRU, or the final chip with enforces the MTU?  Does an "applied"
BGP peer mean an open connection or full route exchange and FIB
update?  There's a lot of gray space here.

The original NETCONF view is that when the config is atomically
accepted as the new, valid config, it's done.  Are we really talking
about changing that?

You see the same issue with AC's used of "particular software
modules", where any piece of functionality might well be a distributed
set of software instances, often with differing code (kernel,
embedded, chip).

FWIW, in JUNOS we show configuration from the configuration database
and _most_ operational commands from the routing engine, either
from its kernel or the daemons running on it.  We expect the kernel
to propagate an MTU as needed without asking the embedded FRU or
chips for their view of the MTU.

>  - the existing NETCONF/RESTCONF protocols has no direct mechanism for 
>indicating a failure to apply any configuration leaf, the only way such 
>information could be deduced is through related operational 

Re: [netmod] opstate-reqs: terminology

[Phil Shafer]

Andy Bierman writes:
>Perhaps the operational requirements are not that clear, so
>the terminology is also not that clear?

Are we trying to agree on the former without the later?

>Is there really a requirement to know detailed info about the
>differences between intended and applied config?

I'm assuming this will end up impacting either netconf operations
or yang data model construction.  At that point (if not before),
we'll need clear terms for app writers and data modelers.

>It seems like the general requirement is that the client
>needs to know when it can start using the network resource
>that has been added or modified in the intended config.

Consider that case where you add interface config for an interface
FRU that's not been inserted.  This config might not be used for
months, until the tech inserts the FRU.

>There are 2 modes that fall out from this requirement:
>  1) synchronous: do not return from this RPC until resources are ready
>  2) asynchronous: return right away from this RPC, and inform the client
>   when the resources are ready (could indicate ready in the RPC response)

Given the inherently squishy definition of "ready", I'd prefer to avoid #1.

Thanks,
 Phil

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

Re: [netmod] Y35: allow empty in union

[Phil Shafer]

Juergen Schoenwaelder writes:
And my understanding is that the list foo defined above will never
have an instance, correct? I assume decent compilers will continue to
create warnings when they can decide that a list will never have any
instances. (And yes, there are other ways to construct such lists, so
I am OK with removing a constraint preventing a specific case of such
useless lists.)

Doesn't removing the prohibition require us to accept such nonsense?

Thanks,
 Phil

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