Re: [netmod] why is the alarm YANG work being done in CCAMP?

[stefan vallin]

Hi Dan!
Agree, there is a long thread on this and I voted on NETMOD all along


Stefan Vallin
ste...@wallan.se
+46705233262

> On 17 Jul 2017, at 16:16, Dan Romascanu  wrote:
> 
> Hi,
> 
> I am sorry if I am late to observing this. Please feel free to bash me and 
> point to where this discussion already took place. I just heard in the NETMOD 
> WG meeting that draft-vallin-netmod-alarm-module is going to be undertaken by 
> the CCAMP WG. What is the reason? The problem space of Alarm management data 
> model seems IMO pretty generic, and on the other side I cannot see what is 
> CCAMP-ish or even RTG Area specific in this work. 
> 
> Thanks and Regards,
> 
> Dan
> (one of the authors of RFC 3877)
> ___
> 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] Side meeting on YOT

[Alexander Pelov]

Dear all,

This is a reminder for the YANG of THINGS Side meeting, which will take place 
*TODAY* (July 20th), 10AM-12PM CEST in room  room Tyrolka, Mezzanine Level.

The materials for the meeting are available online at the following address: 
https://github.com/Ixau/yot/tree/master/ietf99

Remote presence will be made available thanks to Jitsi - just go to the address 
through your browser: https://jitsi.tools.ietf.org/yot 
We will also try to take notes in the Etherpad: 
http://etherpad.tools.ietf.org:9000/p/yot  (This is of course an informal 
meeting, so don’t expect detailed minutes)

Best,
Alexander

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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Clyde Wildes (cwildes)]

Hi Alex,

Answers inline as [clyde]…

On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell" 
 wrote:

I am considering to implement the data model in this draft. (dependent on 
business priorities of course)
I have reviewed this draft and found the following issues.

* I see pattern-match is specified to use POSIX 1003.2 regular expressions. 
This is presumably for compatibility with existing implementations; however it 
is inconsistent with most of YANG (which is specified to use XPath regular 
expressions) - unless these are the same.

[clyde] I believe that my answer in the other thread explains why we used Posix 
1003.2 – it is commonly used. 

* pattern-match is inside the facility-filter container; common sense says 
this is wrong as pattern-match has nothing to do with facilities.

[clyde] I will move pattern-match up one level in the next version of the 
draft. Thanks for catching this!

* The advanced-compare container groups together two nodes that share a 
common "when" and "if-feature" statement, but don't seem to have any semantic 
relation to each other. Are there general guidelines on when to use a container?

[clyde] The confusion may come as a result of the when clause appearing before 
the if-feature clause which is set by the IETF statement order recommendation.

The when construct was suggested by Martin Björklund as a way of solving the 
case that advanced-compare does not apply for the ‘all’ and ‘none’ case.

The if-feature applies to the entire container – it is either supported or not.

* The advanced-compare container has a description starting with "This leaf 
..." even though it is not a leaf.

[clyde] This will be fixed in the next draft.

* The examples are missing  nodes.

[clyde] This will be fixed in the next draft.

* Perhaps there should be more consistent terminology for receivers of 
syslog messages; both "collectors" and "actions" are used in the draft. RFC 
5424 uses "collector" for the ultimate recipient of a log message - which might 
not be applicable, because the sending system has no idea whether the receiving 
system is a collector or a relay.

[clyde] The definition of “collector” in RFC 5424 is: A "collector" gathers 
syslog content for further analysis.

actions relate to the “further analysis” taken by the “collector”. 

“Collectors” appears in the model under the remote action and I believe the 
usage is correct:
  container remote {
if-feature remote-action;
description
  "This container describes the configuration parameters for 
   forwarding syslog messages to remote relays or collectors.";

I will revise the description of these terms in the next draft.

Thanks,

Clyde  


From: netmod  on behalf of Kent Watsen 

Sent: Saturday, 8 July 2017 6:34 a.m.
To: netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

This is a notice to start a three week NETMOD WG last call for the
document:

A YANG Data Model for Syslog Configuration
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-15

Note: Three weeks is more than needed, especially given this
  draft has been through Last Call before, but we understand
  folks are busy these days.

Please indicate your support or concerns by Friday, July 28, 2017.

We are particularly interested in statements of the form:
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...

As well as:
  * I have implemented the data model in this draft.
  * I am implementing the data model in this draft.
  * I am considering to implement the data model in this draft.
  * I am not considering to implement the data model in this draft.

Thank you,
NETMOD WG Chairs




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

[netmod] Migrating existing RFCs to NMDA

[Adrian Farrel]

Hi,

Rob's useful presentation at
https://www.ietf.org/proceedings/99/slides/slides-99-netmod-sessa-nmda-qa-01.pdf
listed a set of RFCs the "need to be updated".

That's a good first step, but we seem to have run out of magic pixie dust here
in the depot, so we were wondering how that "need" is going to be converted to
action.

Is there a plan? If not, what is the plan for a plan?

Thanks,
Adrian

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

[netmod] raw notes from session 1 - link for session 2

[Lou Berger]

Hi,
Please take a look at the raw notes from session 1 and feel free to fix
/ fill in any session details (remember, this should reflect *only* what
took/takes place -- discussion should be on the list).

The same link will be used for raw session note taking during our
upcoming second session.

http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-netmod?useMonospaceFont=true

Thanks,
Lou (and Kent)

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

Re: [netmod] Notification in Yang Modules

[Andy Bierman]

Hi,

The YANG notification-stmt is for defining your own event messages.
This can be used with 5277 or 5277bis notification delivery mechanisms.

The choice of mandatory or optional (via if-feature) is model-specific.
If the module functionality related to the notification is optional, the
notification-stmt should be the same (have the same if-feature-stmts)

If your notification is for pushing operational data that is also
retrievable via ,
then yang-push can be used instead.


Andy

On Wed, Jul 19, 2017 at 12:39 AM, Dhruv Dhody  wrote:

> ​
> ​Hi WG,
>
> As suggested by Lou, ​I am posting the question to the WG list with a
> suggestion that perhaps ​such a guideline could be addressed in 6087bis.
>
> My question to yang doctors regarding the Notification was -
>
> What is the guideline for including Notification in the Yang model, now
> that [I-D.ietf-netconf-yang-push] and 
> [I-D.ietf-netconf-subscribed-notifications]
> is the preferred approach?
>
> Should we keep only "mandatory to implement notifications" in the Yang
> model? Or just remove the notifications completely?
>
> A guideline to model writers would be helpful here, IMHO.
>
> Regards,
> Dhruv
>
> ___
> 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] Notification in Yang Modules

[Juergen Schoenwaelder]

Dhruv,

the question is very broad and hence difficult to answer. Some things
to consider:

For certain events that a system will detect and handle anyway and
that are generally relevant for management applications (an interface
going up or down for example), having a specific notification defined
will likely remain useful.

You also have to consider whether all systems implementing your data
model can be expected to implement the push and subscription models.
Despite implementation costs, these models come with a certain runtime
overhead as well.

/js

On Wed, Jul 19, 2017 at 01:09:53PM +0530, Dhruv Dhody wrote:
> ​
> ​Hi WG,
> 
> As suggested by Lou, ​I am posting the question to the WG list with a
> suggestion that perhaps ​such a guideline could be addressed in 6087bis.
> 
> My question to yang doctors regarding the Notification was -
> 
> What is the guideline for including Notification in the Yang model, now
> that [I-D.ietf-netconf-yang-push] and
> [I-D.ietf-netconf-subscribed-notifications] is the preferred approach?
> 
> Should we keep only "mandatory to implement notifications" in the Yang
> model? Or just remove the notifications completely?
> 
> A guideline to model writers would be helpful here, IMHO.
> 
> Regards,
> Dhruv

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


-- 
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] Notification in Yang Modules

[Dhruv Dhody]

​
​Hi WG,

As suggested by Lou, ​I am posting the question to the WG list with a
suggestion that perhaps ​such a guideline could be addressed in 6087bis.

My question to yang doctors regarding the Notification was -

What is the guideline for including Notification in the Yang model, now
that [I-D.ietf-netconf-yang-push] and
[I-D.ietf-netconf-subscribed-notifications] is the preferred approach?

Should we keep only "mandatory to implement notifications" in the Yang
model? Or just remove the notifications completely?

A guideline to model writers would be helpful here, IMHO.

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

Re: [netmod] ACL draft defines ether-type as a string

[Acee Lindem (acee)]

My thoughts exactly… A sparse enum is the rational approach.
Thanks,
Acee

On 7/19/17, 2:37 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)"  wrote:

>I like the union approach.
>
>I'm not sure that we really want IEEE to have to define an enum entry
>for every possible Ethertype value.   This just means that
>implementations probably ends up with another large mapping table where
>99% of it is just noise.  So I would suggest that 'named ethertypes' are
>restricted to the set of current ones in standard use that people care
>about, and allow vendors to request that their specific ones be added if
>required.
>
>+1 to the description describing the canonical format.
>
>Thanks,
>Rob
>
>
>On 19/07/2017 07:50, Juergen Schoenwaelder wrote:
>> It may even mean that they plan to change ether-type-0x to foo
>> once 0x is allocated to foo, which would be a problem. It seems
>> a union of a uint16 and an enum can be more robust.
>>
>>   type union {
>> type uint16;
>> type enumeration {
>>   enum ipv4 {
>> value 0x0800;
>> description
>>   "Internet Protocol version 4 (IPv4)";
>> reference
>>   "RFC 791: Internet Protocol"
>>   }
>> }
>>   }
>>
>> A caveat is that the canonical representation of a uint16 is decimal
>> (and YANG today has no way to control that), which may be a bit
>> inconvenient here. Perhaps the description clause should overwrite
>> this. There is probably also a need to remember implementors that the
>> canonical representation of the union retains the notation, that is,
>> if I write a numeric value (i.e., if I write '0x800' I get back the
>> numeric value 2048 but if I write the enum value 'ipv4' I get back the
>> enum 'ipv4' and not a numeric value.
>>
>> I have also found a definition in [1] that uses a string with a
>> pattern to match a different notation for ether type numeric values.
>>
>>typedef ethertype-type {
>>  type string {
>>pattern '[0-9a-fA-F]{2}-[0-9a-fA-F]{2}';
>>  }
>>  description
>>"The EtherType value represented in the canonical order defined
>>  by IEEE 802. The canonical representation uses uppercase
>>  characters.";
>>  reference
>>"IEEE 802-2014 Clause 9.2";
>>}
>>
>> While this may be more compliant to IEEE 802-2014 Clause 9.2, having
>> some type that easily resolves to a number may be more desirable in
>> practice.
>>
>> [1] 
>>https://github.com/YangModels/yang/blob/master/standard/ieee/802.1/draft/
>>ieee802-dot1q-types.yang
>>
>> /js
>>
>> PS: Writing definitions for seemingly simple types can be fun.
>>
>> On Tue, Jul 18, 2017 at 10:29:40PM +, Alex Campbell wrote:
>>> Doesn't this mean that if a new protocol is defined, then it won't be
>>>usable in ACLs until the server's data model is upgraded? (And with
>>>many devices, that is quite likely never)
>>>
>>>
>>> 
>>> From: netmod  on behalf of Mahesh
>>>Jethanandani 
>>> Sent: Tuesday, 18 July 2017 6:21 p.m.
>>> To: NetMod WG
>>> Subject: [netmod] ACL draft defines ether-type as a string
>>>
>>> The issue of ether-type defined as a string was discussed with
>>>participants from IEEE in IETF. It was generally agreed that since
>>>ether-types are well known values, and centrally managed, that they be
>>>defined as enumerations. There was some clarification sought by IEEE on
>>>which values need to be published. It was suggested that ether-types
>>>that are either private or do not have a protocol identified would be
>>>named as ether-type-0x where 0x represents the value assigned.
>>>All the remaining ether-types will be defined as enums with the well
>>>known names.
>>>
>>> As far as the impact of that on the ACL draft is concerned, it will be
>>>to remove all local definitions for ether-type from the draft, such as
>>>the one below and instead use the definition from IEEE, whenever that
>>>is done. It does however put a dependency on the IEEE model.
>>>
>>>
>>>  leaf ether-type {
>>>type string {
>>>  pattern '[0-9a-fA-F]{4}';
>>>}
>>>description
>>>  "The Ethernet Type (or Length) value represented
>>>   in the canonical order defined by IEEE 802.
>>>   The canonical representation uses lowercase
>>>   characters.
>>>
>>>   Note: This is not the most ideal way to define
>>>   ether-types. Ether-types are well known types
>>>   and are registered with RAC in IEEE. So they
>>>   should well defined types with values. For now
>>>   this model is defining it as a string.
>>>
>>>
>>>   There is a note out to IEEE that needs to be
>>>   turned into a liaison statement asking them to
>>>   define all ether-types for the industry to use.";
>>>reference
>>>  "IEEE 802-2014 Clause 9.2";
>>>  }
>>>  reference
>>>"IEEE 802: IEEE Standard for Local an