Re: [netmod] ACL Model 03 - ACL Type should be mandatory

[Martin Bjorklund]

Hi,

See below for some clarifying questions.


"Sterne, Jason (Jason)"  wrote:
> Hi all,
> 
> I met with Dean at IETF93 and we agreed that I should send a
> specific proposal to the list for this.  Here it is:
> 
> -
> Replace the following current snippets from model-03:
> -
> 
> list acl {
>   key "acl-name";
>   ...
> }
> 
> leaf acl-type {
>   type acl-type;
>   description
> "It is recommended to have an Access Control List with
>  uniform access list entries, all of the same type. When
>  this type is not explicitly specified, if vendor
>  implementation permits, the access control entries
>  in the list can be mixed,
>  by containing L2, L3 and L4 entries";
> }
> 
> identity ip-acl {
>   base acl:acl-base;
>   description
> "IP Access Control List is a common name for lists that contain
>  layer 3 and/or layer 4 match conditions.";
> }
> 
> identity eth-acl {
>   base acl:acl-base;
>   description
> "Ethernet Access Control List is name for layer 2 Ethernet
>  technology Access Control List types, like 10/100/1000baseT or
>  WiFi Access Control List";
> }
> 
>   
> with the following:
> 
> 
> list acl {
>   key "acl-type acl-name";
>   ...
> }
> (note this is similar construct to the routing model: 
>list routing-protocol {key "type name"... )
> 
> leaf acl-type {
>   type acl-type;
>   description
> "Type of access control list. Indicates the primary intended
>  type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc) 
>  used in the list instance.";

What exactly does "primary intended type of match criteria" mean?

How is the ace-type related to the acl-type?  Shouldn't the
ace-type-specific params be conditional (with "when") based on the
acl-type?


/martin



> }
> 
> identity ipv4-acl {
>   base acl:acl-base;
>   description 
> "ACL that primarily matches on fields from the IPv4 header
> (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP destination
> port).  An acl of type ipv4-acl does not contain matches on fields in
> the ethernet header or the IPv6 header.";
> }
> 
> identity ipv6-acl {
>   base acl:acl-base;
>   description
> "ACL that primarily matches on fields from the IPv6 header
> (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP destination
> port). An acl of type ipv6-acl does not contain matches on fields in
> the ethernet header or the IPv4 header.";
> }
>   
> identity eth-acl {
>   base acl:acl-base;
>   description
> "ACL that primarily matches on fields in the ethernet header.
>  An acl of type eth-acl does not contain matches on fields in
>  the IPv4 header, IPv6 header or layer 4 headers.";
> }
> 
> 
> ---
> Potential future augmentation of type:
> 
> 
> For future mixed types vendors (or the ietf) could augment the acl-type-base 
> with types like the following:
> 
>   identity mixed-l3-acl {
> base "access-control-list:acl-type-base";
> description "ACL that contains a mix of entries that primarily match on 
> fields 
>   in IPv4 headers and entries that primarily match on fields in IPv6 
> headers.
>   Matching on layer 4 header fields may also exist in the list.
>   An acl of type mixed-l3-acl does not contain matches on fields in
>   the ethernet header.";
>   }
>  
>   identity mixed-l2-l3-acl {
> base "access-control-list:acl-type-base";
> description "ACL that contains a mix of entries that primarily match on 
> fields 
>   in ethernet headers, entries that primarily match on fields in IPv4 
> headers,
>   and entries that primarily match on fields in IPv6 headers.  Matching 
> on layer 4 
>   header fields may also exist in the list.";
>   }
> 
> Regards,
> Jason
> 
> -Original Message-
> From: Sterne, Jason (Jason) 
> Sent: Sunday, July 19, 2015 12:58
> To: Sterne, Jason (Jason); netmod@ietf.org
> Subject: RE: ACL Model 03 - ACL Type should be mandatory
> 
> Given the data models below in some of the major implementations it also 
> seems like we should also (re-)consider having the 'type' as part of the ACL 
> key ("type name").  
> 
> In all those cases below it looks like an operator can currently configure 
> two different ACLs (e.g. an IPv4 and an IPv6 ACL) with the same name/id via 
> their CLI (e.g. a v4 ACL called "my-acl" and a v6 ACL called "my-acl").  
> 
> How would those lists be read in a  via the ietf ACL YANG modules 
> ?  We'd all have to mangle the names and reserve special names/prefix-chars 
> (e.g. _ipv4-my-acl and _ipv6-my-acl) to send them back to a NC client.  I'm 
> not sure if there is much of a disadvantage of just having type in the key 
> (assuming it is mandatory as advocated below).
> 
> I also 

Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification

[Benoit Claise]

Thanks Rob, that clarifies the situation for me.

Regards, Benoit

On 14 September 2015 at 08:43:53, Benoit Claise (bcla...@cisco.com) wrote:


Re-reading this section 4.5, I understand 6A and 6C, but is 6B also
required?
Do we need to make the link between a config node and all the derived
counters/statistics it influences, which might be in different YANG
models btw?

Yes - we need to deterministically retrieve, for a particular configuration 
object (e.g., interface, BGP peer) the set set of derived state nodes 
associated with it, such that we do not need to maintain complex mapping tables 
on the client side for this - and can efficiently query the server for them.

For instance, knowing that we configured a BGP peer at 
$SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/config/{leaf-set} 
then we would find the counters at 
$SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/state/ - allows us 
to (based on the fact that we just configured a peer) retrieve the state and 
counters that a client application will likely want to check without having to 
map to some other (set of locations).

Note that in previous discussions, it was expressed that this implied that the 
model had knowledge of how the protocol operates such that it was known that 
leaf A corresponding to some other derived-state leaf B. However, this isn’t 
true. As I expressed before, the intention is that it is possible for a NMS 
layer to easily retrieve the set of state objects that an interested client may 
require, without many disparate queries, based on the configuration path. The 
actual meaning may be completely unknown to this layer.

The openconfig-opstate approach allows state and config to be defined in 
separate modules - since the ‘state’ module in this case can simply augment the 
relevant ‘state’ containers within the config model.

Regards,
r.
.



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

Re: [netmod] ACL Model 03 - ACL Type should be mandatory

[Ladislav Lhotka]

"Sterne, Jason (Jason)"  writes:

> Hi all,
>
> I met with Dean at IETF93 and we agreed that I should send a specific 
> proposal to the list for this.  Here it is:
>
> -
> Replace the following current snippets from model-03:
> -
>
> list acl {
>   key "acl-name";
>   ...
> }
>
> leaf acl-type {
>   type acl-type;
>   description
> "It is recommended to have an Access Control List with
>  uniform access list entries, all of the same type. When
>  this type is not explicitly specified, if vendor
>  implementation permits, the access control entries
>  in the list can be mixed,
>  by containing L2, L3 and L4 entries";
> }
>
> identity ip-acl {
>   base acl:acl-base;
>   description
> "IP Access Control List is a common name for lists that contain
>  layer 3 and/or layer 4 match conditions.";
> }
>
> identity eth-acl {
>   base acl:acl-base;
>   description
> "Ethernet Access Control List is name for layer 2 Ethernet
>  technology Access Control List types, like 10/100/1000baseT or
>  WiFi Access Control List";
> }
>
>   
> with the following:
> 
>
> list acl {
>   key "acl-type acl-name";
>   ...
> }
> (note this is similar construct to the routing model: 
>list routing-protocol {key "type name"... )

Well, originally we had "name" as the only key but some routing folks
insisted on having "type" as the second key. Personally, I am not
entirely sold to this idea.

The thing is: YANG requires config lists to have keys but it doesn't
mean these keys need to be the same as parameters that are understood as
keys in a CLI.

One advantage of having YANG list keys separate from "public" keys is
that a user is free to change the public keys, and it also doesn't break
any internal references in the configuration. If you have "acl-type" and
"acl-name" as YANG list keys, then they cannot be changed.

So in fact I'd suggest to have an opaque ID as the only list key, and
then "acl-name" and "acl-type" as non-key leafs, perhaps subject to a
unique constraint.

Lada

>
> leaf acl-type {
>   type acl-type;
>   description
> "Type of access control list. Indicates the primary intended
>  type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc) 
>  used in the list instance.";
> }
>
> identity ipv4-acl {
>   base acl:acl-base;
>   description 
> "ACL that primarily matches on fields from the IPv4 header
> (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP destination
> port).  An acl of type ipv4-acl does not contain matches on fields in
> the ethernet header or the IPv6 header.";
> }
>
> identity ipv6-acl {
>   base acl:acl-base;
>   description
> "ACL that primarily matches on fields from the IPv6 header
> (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP destination
> port). An acl of type ipv6-acl does not contain matches on fields in
> the ethernet header or the IPv4 header.";
> }
>   
> identity eth-acl {
>   base acl:acl-base;
>   description
> "ACL that primarily matches on fields in the ethernet header.
>  An acl of type eth-acl does not contain matches on fields in
>  the IPv4 header, IPv6 header or layer 4 headers.";
> }
>
>
> ---
> Potential future augmentation of type:
> 
>
> For future mixed types vendors (or the ietf) could augment the acl-type-base 
> with types like the following:
>
>   identity mixed-l3-acl {
> base "access-control-list:acl-type-base";
> description "ACL that contains a mix of entries that primarily match on 
> fields 
>   in IPv4 headers and entries that primarily match on fields in IPv6 
> headers.
>   Matching on layer 4 header fields may also exist in the list.
>   An acl of type mixed-l3-acl does not contain matches on fields in
>   the ethernet header.";
>   }
>  
>   identity mixed-l2-l3-acl {
> base "access-control-list:acl-type-base";
> description "ACL that contains a mix of entries that primarily match on 
> fields 
>   in ethernet headers, entries that primarily match on fields in IPv4 
> headers,
>   and entries that primarily match on fields in IPv6 headers.  Matching 
> on layer 4 
>   header fields may also exist in the list.";
>   }
>
> Regards,
> Jason
>
> -Original Message-
> From: Sterne, Jason (Jason) 
> Sent: Sunday, July 19, 2015 12:58
> To: Sterne, Jason (Jason); netmod@ietf.org
> Subject: RE: ACL Model 03 - ACL Type should be mandatory
>
> Given the data models below in some of the major implementations it also 
> seems like we should also (re-)consider having the 'type' as part of the ACL 
> key ("type name").  
>
> In all those cases below it looks like an operator can currently configure 
> two different ACLs (e.g. an IPv4 and an 

Re: [netmod] ACL Model 03 - ACL Type should be mandatory

[Acee Lindem (acee)]

On 9/21/15, 10:23 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>"Sterne, Jason (Jason)"  writes:
>
>> Hi all,
>>
>> I met with Dean at IETF93 and we agreed that I should send a specific
>>proposal to the list for this.  Here it is:
>>
>> -
>> Replace the following current snippets from model-03:
>> -
>>
>> list acl {
>>   key "acl-name";
>>   ...
>> }
>>
>> leaf acl-type {
>>   type acl-type;
>>   description
>> "It is recommended to have an Access Control List with
>>  uniform access list entries, all of the same type. When
>>  this type is not explicitly specified, if vendor
>>  implementation permits, the access control entries
>>  in the list can be mixed,
>>  by containing L2, L3 and L4 entries";
>> }
>>
>> identity ip-acl {
>>   base acl:acl-base;
>>   description
>> "IP Access Control List is a common name for lists that contain
>>  layer 3 and/or layer 4 match conditions.";
>> }
>>
>> identity eth-acl {
>>   base acl:acl-base;
>>   description
>> "Ethernet Access Control List is name for layer 2 Ethernet
>>  technology Access Control List types, like 10/100/1000baseT or
>>  WiFi Access Control List";
>> }
>>
>> 
>> with the following:
>> 
>>
>> list acl {
>>   key "acl-type acl-name";
>>   ...
>> }
>> (note this is similar construct to the routing model:
>>list routing-protocol {key "type name"... )
>
>Well, originally we had "name" as the only key but some routing folks
>insisted on having "type" as the second key. Personally, I am not
>entirely sold to this idea.

Why not? Existing products support these semantics… Different types of
access-list should have independent name spaces (i.e., one should be able
to have an IP ACL named foo, an IPv6 ACL named foo, and a L2 ACL named
foo). 

Thanks,
Acee 





>
>The thing is: YANG requires config lists to have keys but it doesn't
>mean these keys need to be the same as parameters that are understood as
>keys in a CLI.
>
>One advantage of having YANG list keys separate from "public" keys is
>that a user is free to change the public keys, and it also doesn't break
>any internal references in the configuration. If you have "acl-type" and
>"acl-name" as YANG list keys, then they cannot be changed.
>
>So in fact I'd suggest to have an opaque ID as the only list key, and
>then "acl-name" and "acl-type" as non-key leafs, perhaps subject to a
>unique constraint.
>
>Lada
>
>>
>> leaf acl-type {
>>   type acl-type;
>>   description
>> "Type of access control list. Indicates the primary intended
>>  type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)
>>  used in the list instance.";
>> }
>>
>> identity ipv4-acl {
>>   base acl:acl-base;
>>   description 
>> "ACL that primarily matches on fields from the IPv4 header
>> (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP
>>destination
>> port).  An acl of type ipv4-acl does not contain matches on fields
>>in
>> the ethernet header or the IPv6 header.";
>> }
>>
>> identity ipv6-acl {
>>   base acl:acl-base;
>>   description
>> "ACL that primarily matches on fields from the IPv6 header
>> (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP
>>destination
>> port). An acl of type ipv6-acl does not contain matches on fields in
>> the ethernet header or the IPv4 header.";
>> }
>>   
>> identity eth-acl {
>>   base acl:acl-base;
>>   description
>> "ACL that primarily matches on fields in the ethernet header.
>>  An acl of type eth-acl does not contain matches on fields in
>>  the IPv4 header, IPv6 header or layer 4 headers.";
>> }
>>
>>
>> ---
>> Potential future augmentation of type:
>> 
>>
>> For future mixed types vendors (or the ietf) could augment the
>>acl-type-base with types like the following:
>>
>>   identity mixed-l3-acl {
>> base "access-control-list:acl-type-base";
>> description "ACL that contains a mix of entries that primarily
>>match on fields 
>>   in IPv4 headers and entries that primarily match on fields in
>>IPv6 headers.
>>   Matching on layer 4 header fields may also exist in the list.
>>   An acl of type mixed-l3-acl does not contain matches on fields in
>>   the ethernet header.";
>>   }
>>  
>>   identity mixed-l2-l3-acl {
>> base "access-control-list:acl-type-base";
>> description "ACL that contains a mix of entries that primarily
>>match on fields 
>>   in ethernet headers, entries that primarily match on fields in
>>IPv4 headers,
>>   and entries that primarily match on fields in IPv6 headers.
>>Matching on layer 4
>>   header fields may also exist in the list.";
>>   }
>>
>> Regards,
>> Jason
>>
>> 

[netmod] Fwd: Re: Openconfig protocol(s)

[Benoit Claise]

Forwarded Anees Shaikh's email, with permission.
Thanks Anees. I believe it's useful info for NETMOD.

Regards, Benoit
 Forwarded Message 

   hi Benoit, we will be publishing the primitives after we complete
   our internal review -- it's in progress.  There's nothing secret
   about it, or any intention on our part to not 'put our cards on the
   table.'

   As we've said publicly, at Google we are planning to use gRPC for
   example, while others in OpenConfig have expressed their intention
   to use protocols such as Thrift, and still others will use NETCONF,
   or their own REST-based protocol.  OpenConfig is not prescribing or
   endorsing any specific protocol -- we only insist that the data
   models be common.

...


   On Mon, Sep 14, 2015 at 8:00 AM, Benoit Claise > wrote:



From the preliminary meeting minutes

   Benoit: The two suggested solutions. They are based on
   NETCONF/RESTCONF. Are they using it for other protocols?
   Aneesh: We are using other protocols. Will share primitives.
   Benoit: If the solution is for NETCONF/RESTCONF, will it
   work for other protocols.
   Rob: If the solution is mappable for NETCONF/RESTCONF, would
   it be mappable for another protocol.
   Benoit: YANG is currently not protocol agnostic. Currently,
   it is tied to NETCONF/RESTCONF.
   Benoit: If the solution is for NETCONF/RESTCONF, is that
   acceptable?
   Rob: No. The solution has to be more general.
   Christian: Is the intersection of NETCONF/RESTCONF good
   enough for the other protocols.

   Rob mentioned during the call something such as: "we would share
   the expectations of the protocol".
   Please follow up and share the primitives or those expectations.
   However, in the end, I believe it would be favorable to
   everybody if you would play all your cards on the table, and
   directly share the protocols you plan on using.

   Regards, Benoit (OPS AD)










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

[netmod] WG Last Call for draft-ietf-netmod-yang-json-05 (until 2015-10-05)

[Kent Watsen]

This is a notice to start a NETMOD WG last call for the document "JSON
Encoding of Data Modeled with YANG":

https://tools.ietf.org/html/draft-ietf-netmod-yang-json-05

Please indicate your support by Monday October 5, 2015 at 9PM EDT.
We are not only interested in receiving defect reports, we are equally
interested in statements of the form:

  "I have reviewed I-D XYZ and I found no issues"
  "I have implemented the data model in I-D XYZ"
  "I am implementing the data model in I-D XYZ"
  "I am considering to implement the data model in I-D XYZ"

This is the second Last Call for this document.

Thanks,
Kent


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

Re: [netmod] New Version Notification for draft-ietf-netmod-yang-json-05.txt

[Juergen Schoenwaelder]

On Thu, Sep 17, 2015 at 08:24:28AM +0200, Ladislav Lhotka wrote:
> 
> Yes, but the same thing can be done with anyxml, right? It has been
> demonstrated in RFC 6241, ietf-yang-patch and probably elsewhere, too,
> and it does the job.
> 
> The use case of passing around literally "any XML" is really only
> theoretical, I think some kind of schema is always assumed.
> 
> So I believe we don't need two data node types for this purpose. And an
> advantage of anyxml is that its definition (from YANG point of view) is
> clear and unambiguous, whereas for anydata the phrase "can be modelled
> with YANG" may be interpreted in different ways. We are introducing a
> dubious new concept in YANG 1.1 with no apparent gain.
>

I do not think we are going to repeat that debate. I think we
concluded that anyxml does not mean any JSON.

/js

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

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

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt

[Andy Bierman]

Hi,

I agree that anydata is much better than anyxml because it represents
how this "schema replacement" is actually being used.

I don't worry about anyxml too much.
It would be better to just rename anyxml, or declare it really
means anydata, but that would not be backward-compatible.

If anyxml "XML semantics" were actually important, then YANG designers would
ask toolkit developers to support it correctly.  Since that has never
happened, it seems clear that anyxml never meant "any XML".


Andy


On Mon, Sep 21, 2015 at 1:40 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, Sep 16, 2015 at 11:25:25AM -0700, Andy Bierman wrote:
> >
> > The "anyxml" node allows XML-specific details like processing
> instructions.
> > It is a blob of XML.  It is not JSON.  It is not YANG.  It is XML.
> > This is academic, because the vast majority of servers do not support
> anyxml
> > at all.  None. Zero.  Not allowed in the server.  The few that do treat
> > anyxml
> > as if it were anydata.
> >
> > The "anydata" node is a blob of YANG data nodes.  It is not XML.
> > It is not JSON. This too will likely not be implemented in the vast
> majority
> > of servers.
> >
>
> Even very basic things like  need something like anyxml or
> anydata. Right now, we write anyxml but usually mean anydata. YANG 1.1
> aims at fixing this.
>
> /js
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] today's virtual interim on YANG 1.1 cancelled

[Juergen Schoenwaelder]

Hi,

after consulting with Martin Bjorklund, I decided to cancel today's
YANG 1.1 virtual interim meeting. Martin believes he has the input
needed to produce the next revision of draft-ietf-netmod-rfc6020bis.
This update should be posted during this week. We will then do any
word smithing that might be needed based on this revision of the YANG
1.1 specification. We will try to do most of the word smithing via the
mailing list but if needed we will make use of the YANG 1.1 virtual
interim meetings that we have allocated.

/js

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

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

Re: [netmod] Y26 again, sorry

[Juergen Schoenwaelder]

On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Thu, Sep 10, 2015 at 06:19:20PM -0700, Randy Presuhn wrote:
> >  
> >> >> Let's look at a slightly more complex hypothetical case to tease
> >> >> out how folks *want* things to work.  Assume the following have
> >> >> been defined:
> >> >>
> >> >>   - base module M
> >> >>   - augmentation Q
> >> >>   - augmentation R
> >> >>
> >> >> On a server claiming to supporting the modules containing M, Q,
> >> >> and R, respectively, which of the following might one encounter
> >> >> concurrently?
> >> >>
> >> >>  - plain M
> >> >>  - M+Q
> >> >>  - M+R
> >> >>  - M+Q+R
> >> >
> >> >It depends on what you mean by "encounter" but in terms of datastore
> >> >validity the only possible answer IMO is M+Q+R.
> >> 
> >> By "encounter" I mean if a client asks the server for all of its Ms,
> >> and the server also supports Q and R, are all of the Ms *guaranteed*
> >> to be M+Q+R, or is it possible that some of the Ms might lack Q or
> >> lack R of lack both?  If what netmod gives us is strictly M+Q+R,
> >> how would one model a system inhabited by a mixture of the four
> >> kinds of Ms?
> >
> > Retrieval is easy since a client is going to ignore data it does not
> > understand and the server is expected to report what makes sense from
> > the server's perspective. The question is relevant for writing: Is a
> > client programmed based on M going to work even if a server supports
> > M+Q, M+R, or M+Q+R? I believe the rule stated in section 7.15 of RFC
> > 6020 wanted to achieve this by forbidding mandatory nodes in
> > augmentations.
> >
> > Y26-02 says that a presence container may be used to avoid breaking an
> > old client. Frankly, it seems not totally clear to me what the
> > sentence in section 7.15 of RFC 6020 really means:
> >
> > If the target node is in another module, then nodes added by the
> > augmentation MUST NOT be mandatory nodes (see Section 3.1).
> >
> > Does this rule only apply to nodes directly added under the target
> > node or does it apply to the whole hierarchy added? In the later case,
> > this would still cause a problem with the presence container work
> > around.
> 
> Yes, it's unclear but IMO it is about mandatory nodes directly below the
> target node - a similar rule for module updates is in sec. 11.
> 
> >
> > The recent suggestion to replace MUST NOT with SHOULD NOT in this
> > sentence may be seen as a softer variant of Y26-01. However, I think
> > we would, in addition, have to describe when it is OK to have
> > mandatory nodes in augmentations and when not. Simply saying SHOULD
> > NOT instead of MUST NOT will not help people to understand the issues
> > around this.
> 
> The definition in RFC 2119 is:
> 
> 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
>there may exist valid reasons in particular circumstances when the
>particular behavior is acceptable or even useful, but the full
>implications should be understood and the case carefully weighed
>before implementing any behavior described with this label.
> 
> I think it should suffice if data model designers are aware of the
> fact that certain augments may break old clients, and give some
> reasoning if they use them anyway. 
> 
> >
> > When this issue was discussed in the past, it turned out to be
> > difficult to find someone to write the necessary text explaining when
> > augmenting mandatory nodes is safe and when not. Are we doing better
> > now?
> 
> I don't think we can enumerate all cases where it is allowed because
> YANG doesn't follow any rigid structure and there may be a variety of
> different designs.
> 
> I'd prefer to explain the ramifications of defining mandatory nodes in
> augments (and also in module updates) and leave it to the model designer
> to judge whether there are valid reasons to override the "SHOULD NOT" -
> and YANG doctors should verify it in IETF models.
> 
> I think the point is that parameters are mandatory not because a
> spiteful module author defines them so but rather because the system
> cannot work without them.
>

Still some text needs to be written explaining that breaking old
clients by adding new mandatory nodes is a no go. I did not ask to
enumerate all situations where it is allowed, I am looking for text
that clearly says what people have to look out for if they add
mandatory nodes.

/js

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

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