Re: [netmod] general permission on metadata

[Juergen Schoenwaelder]

Lada,

I do not think this belongs into the YANG specification. NC has been
designed to support arbitrary XML so any NC compliant implementation
will not screw up on XML attributes. The JSON encoding could say that
names with @ may be used for special purposes and must be supported
and that implementations must be expected to handle full I-JSON and
not the subset used by YANG.

I guess I am not even sure yet that there is a problem that requires
fixing. But if it requires fixing, than its an encoding or protocol
issue, not a data modeling language issue.

/js

On Wed, Nov 04, 2015 at 02:30:26PM +0900, Ladislav Lhotka wrote:
> Hi,
> 
> my idea was that YANG spec contain a general statement that data may be 
> complemented with annotations, i.e. information that's not represented in the 
> data model as regular YANG data nodes, and that every encoding has to specify 
> how these annotations can be recognized in the payload. Parsers of YANG data 
> (in whatever encoding) then MUST be prepared to receive such annotations (and 
> perhaps ignore them).
> 
> I don't think such a statement is encoding-specific.
> 
> Lada
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> 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] general permission on metadata

[Ladislav Lhotka]

Hi,

my idea was that YANG spec contain a general statement that data may be 
complemented with annotations, i.e. information that's not represented in the 
data model as regular YANG data nodes, and that every encoding has to specify 
how these annotations can be recognized in the payload. Parsers of YANG data 
(in whatever encoding) then MUST be prepared to receive such annotations (and 
perhaps ignore them).

I don't think such a statement is encoding-specific.

Lada

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




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

Re: [netmod] netmod-opstate-reqs: Are 2.A. and 4.C. the same thing ? (derived + non-derived)

[Randy Presuhn]

Hi -

> From: "Sterne, Jason (Jason)"
> Sent: Nov 3, 2015 12:02 AM
> To: "netmod@ietf.org"
> Subject: [netmod] netmod-opstate-reqs: Are 2.A. and 4.C. the same thing ? 
> (derived + non-derived)
...
> But isn’t 4.C. also a repeat of 2.A. ?
>
> 2.A.:  The ability to retrieve the applied configuration
> and derived state nodes in a single protocol operation.
>
> 4.C.: Be able to retrieve both the derived and non-derived state
> aspects of operational state together.
>
> Or am I missing some subtlety here ?
 
It sounds to me like there are three different sets of information
here:
  - configuration data
  - operational state data that is a function of configuration data
(it's ambiguous whether it is intended that "derived" means
something can be computed using *only* configuration data as
inputs or that additional inputs are possible)
  - operational state data that is not a function of configuration data
(e.g., chassis temperature, input line voltage, door ajar)

Randy

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

[netmod] Queue for NETMOD Remote Attendees

[Alexa Morris]

If you are planning to participate in the NETMOD session here at IETF 94 today 
— either locally in Yokohama or as a remote participant — we want to make sure 
that you are aware that the IETF is providing a remote participants with a 
fairly new way to ask questions or make comments. In addition to using the 
Jabber room, for the NETMOD session there is also the opportunity for remote 
participants to enter a virtual queue and ask questions directly into the 
meeting room. 

This experimental queue was used in several sessions at IETF 92 and IETF 93, so 
you may have already seen it in action. There will be two queues for the NETMOD 
session — a virtual queue and an actual (in-room) queue. Remote attendees will 
log into the Meetecho platform and will have a virtual mic line that they can 
enter if they have a question or comment. In-room participants will continue to 
use normal mic lines. 

Instructions for remote participants are at 
http://ietf94.conf.meetecho.com/index.php/Remote_Participation. 

Information on how to join the Meetecho session is at 
http://ietf94.conf.meetecho.com/.

Verify that you are WebRTC compliant (required to use the virtual queue) by 
performing a self-test here: 
http://ietf94.conf.meetecho.com/index.php/Self_Test. 

Regards,
Alexa

--
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

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

[netmod] YANG packages

[Martin Bjorklund]

Hi,

The YANG packages draft that I mentioned today is
http://tools.ietf.org/id/draft-bierman-netmod-yang-package-00.txt

I think it might be suitable for Ian's draft on CPE modeling.


/martin

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

[netmod] groupings non-augmentable?

[Ladislav Lhotka]

Hi Lou,

I didn't understand the point in your presentation where you said that 
groupings are not augmentable. What you can do is the following:

module A {
  grouping foo { ... }
}

module B {
  import A { prefix A; }
  grouping foo {
uses A:foo;
... // additional nodes
  }
}

While it doesn't involve the keyword "augment", this is my undestanding of how 
a grouping can be augmented/extended. Do you need anything else?

Lada

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




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

Re: [netmod] syslog-model-05: terminal logging vs session logging

[Clyde Wildes (cwildes)]

Jason,

As always, thanks for your feedback!

I am consolidating your two sets of comments into one reply with my responses 
as [clw]:

[js] I’m not sure it is typical to have configuration in a device that 
basically instructs the device to enable logging to the terminal for “user x” 
whenever that user later logs in (and if they had multiple login sessions then 
presumably log events would be delivered to each session).

[js] Isn’t logging to a terminal more typically enabled on a CLI *session* 
basis rather than configured against a particular user ?

[clw] There are two concepts: logging to terminals no matter which user is 
logged in - Cisco "logging monitor",  and Linux ”/dev/ttyx’‘ support this 
concept; logging to specific or all user sessions (even multiple sessions with 
the same user id) – Linux ":omusrmsg:root", ":omusrmsg:*", and Juniper "user 
(username | *)" support this concept. A Juniper example: when the user logs in, 
logging begins if there is a username match using this Junos config command 
(asterisk means all users):

syslog {
   user ( | *) {
   ;
  match "regular-expression";
   }
}

I agree that the model would be clearer if these cases were treated separately. 
I captured both requirements in a revision to the proposed syslog model where I 
modify the terminal action into two actions: one for terminal and one for 
session. The diff is small and is attached.

Please let me know what you think.


[js] The introduction says "We are using definitions of Syslog protocol from 
[RFC3164] in this draft." but the YANG model mostly references 5424.

[clw] I will include this in the next revision.


[js]  In section 3 maybe use the term "Remote Collector(s)" instead of 
Server(s) ? Collector seems more in line with RFC5424 (or "Remote Receiver" if 
others prefer that).

[clw] I will include this in the next revision.


[js]  In the Section 3 figure make all the Distributors have a common syntax 
for plural vs singular "Log Buffer(s)", "Log File(s)", "Remote Collector(s)", 
“User Terminal(s)”

[clw] I will include this in the next revision.


[js]  Document is missing the standard legend for the PYANG tree

[clw] I will include this in the next revision.


Thanks,

Clyde

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of "Sterne, Jason (Jason)" 
mailto:jason.ste...@alcatel-lucent.com>>
Date: Wednesday, October 28, 2015 at 11:50 AM
To: "netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: [netmod] syslog-model-05: terminal logging vs session logging

Hi all,

One of the syslog destinations in the model is the “terminal” (for all users or 
specific users).

Isn’t logging to a terminal more typically enabled on a CLI *session* basis 
rather than configured against a particular user ?

I believe it is also typical for session logging to stop/disappear when that 
session is ended (i.e. it is not persistent config).

I’m not sure it is typical to have configuration in a device that basically 
instructs the device to enable logging to the terminal for “user x” whenever 
that user later logs in (and if they had multiple login sessions then 
presumably log events would be delivered to each session).

I think session logging is something that is really purely CLI (i.e. 
interactive sessions with human users) and maybe not even applicable to 
configuration via NETCONF (since we’d never want to send a stream of syslog 
events as text to the NETCONF client/session like we do to the terminal for a 
CLI user).

In section 5 of the draft it mentions that syslog:log-actions/terminal maps to 
Cisco NXOS “logging monitor 2”.  I believe that is intended to enable logs to a 
particular *session* (not user).   IOS-XR behavior is similar.  The ALU SR OS 
logging config has the concept of sending (enabling) log events to a particular 
session (but not configured against a user).

Jason





ietf-syslog.diff
Description: ietf-syslog.diff
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Queue for NETMOD Remote Attendees

[Alexa Morris]

If you are planning to participate in the NETMOD session here at IETF 94 today 
— either locally in Yokohama or as a remote participant — we want to make sure 
that you are aware that the IETF is providing a remote participants with a 
fairly new way to ask questions or make comments. In addition to using the 
Jabber room, for the NETMOD session there is also the opportunity for remote 
participants to enter a virtual queue and ask questions directly into the 
meeting room. 

This experimental queue was used in several sessions at IETF 92 and IETF 93, so 
you may have already seen it in action. There will be two queues for the NETMOD 
session — a virtual queue and an actual (in-room) queue. Remote attendees will 
log into the Meetecho platform and will have a virtual mic line that they can 
enter if they have a question or comment. In-room participants will continue to 
use normal mic lines. 

Instructions for remote participants are at 
http://ietf94.conf.meetecho.com/index.php/Remote_Participation. 

Information on how to join the Meetecho session is at 
http://ietf94.conf.meetecho.com/.

Verify that you are WebRTC compliant (required to use the virtual queue) by 
performing a self-test here: 
http://ietf94.conf.meetecho.com/index.php/Self_Test. 

Regards,
Alexa

--
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

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

Re: [netmod] IETF 94 - Remote Participation information and request for jabber scribes

[Kent Watsen]

Yes, time is tight for the morning session, the more we can dispatch beforehand 
the better.

Not just Jabber scribe, but also minute-takers - please, if you’re willing to 
take minutes for the morning session, let us know now.

Lastly, I forgot to bring my thunderbolt-to-hdmi/dvi cable thingy.  If anyone 
has one I could borrow for the morning session, I would be most grateful!

K.

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of "Andrew McLachlan (amclachl)" 
mailto:amcla...@cisco.com>>
Date: Wednesday, November 4, 2015 at 12:33 AM
To: "netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: [netmod] IETF 94 - Remote Participation information and request for 
jabber scribes

Dear All

Request for Jabber Scribes

We would be very grateful if there are a couple of folks who would be willing 
to volunteer as a scribe for either of the two sessions we have at this IETF.

Since I’m unable to attend this IETF, and the tz is against me for email later, 
please ping both Kent and I directly just to be sure one of us sees your email 
before the meetings.

kwat...@juniper.net
amcla...@cisco.com

Wednesday:
0900 - 1130 JST - Room 301 -
1300 - 1500 JST - Rooms 411/412 -

Room - xmpp:net...@jabber.ietf.org?join
Logs - http://jabber.ietf.org/logs/netmod


Remote Participation

Following on from IETF 92 & 93,  IETF 94 is going to be expanding the use of 
the Meetecho.

Details of how to use this system are available here - 
http://ietf.org/meeting/94/remote-participation.html#Meetecho

The two sessions are available via the following links

0900 - 1130 JST - Room 301 - http://www.meetecho.com/ietf94/netmod
1300 - 1500 JST - Rooms 411/412 - http://www.meetecho.com/ietf94/netmod_II


Thank you in advance.


Kent, Tom, Andrew
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IETF 94 - Remote Participation information and request for jabber scribes

[Andrew McLachlan (amclachl)]

Dear All

Request for Jabber Scribes

We would be very grateful if there are a couple of folks who would be willing 
to volunteer as a scribe for either of the two sessions we have at this IETF.

Since I’m unable to attend this IETF, and the tz is against me for email later, 
please ping both Kent and I directly just to be sure one of us sees your email 
before the meetings.

kwat...@juniper.net
amcla...@cisco.com

Wednesday:
0900 - 1130 JST - Room 301 -
1300 - 1500 JST - Rooms 411/412 -

Room - xmpp:net...@jabber.ietf.org?join
Logs - http://jabber.ietf.org/logs/netmod


Remote Participation

Following on from IETF 92 & 93,  IETF 94 is going to be expanding the use of 
the Meetecho.

Details of how to use this system are available here - 
http://ietf.org/meeting/94/remote-participation.html#Meetecho

The two sessions are available via the following links

0900 - 1130 JST - Room 301 - http://www.meetecho.com/ietf94/netmod
1300 - 1500 JST - Rooms 411/412 - http://www.meetecho.com/ietf94/netmod_II


Thank you in advance.


Kent, Tom, Andrew
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leaf-list uniqueness requirement for non-config nodes

[Juergen Schoenwaelder]

On Mon, Nov 02, 2015 at 09:40:00PM -0800, Randy Presuhn wrote:
> Hi -
> 
> >From: Juergen Schoenwaelder 
> >Sent: Oct 29, 2015 1:06 AM
> >To: netmod@ietf.org
> >Subject: [netmod] leaf-list uniqueness requirement for non-config nodes
> >
> >Hi,
> >
> >RFC 6020 say:
> >
> >   The values in a leaf-list MUST be unique.
> >
> >While this may have a justification for config true nodes (to allow
> >modifications of individual elements using edit-config), this
> >constraint does not seem to make much sense for non-config nodes.
> >
> >Note that YANG requires keys for lists for config nodes (to allow
> >modifications of individual elements using edit-config) but it does
> >not requires keys or uniqueness for for lists for non-config nodes.
> >
> >In order to be consistent, I think the above requirement should be
> >changed to this:
> >
> >   The values in a leaf-list MUST be unique if the nodes represent
> >   configuration.
> 
> How would this affect a model needing a leafref to the information?
>

How does a model reference a leaf in a key-less config false list?

I guess they both work the same way. ;-)

/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] netmod-opstate-reqs: Are 2.A. and 4.C. the same thing ? (derived + non-derived)

[Sterne, Jason (Jason)]

Hi all,

In reading through the netmod-opstate-reqs draft I see it is already noted that 
5 seems to be a repeat of 4.a.

But isn't 4.C. also a repeat of 2.A. ?

2.A.:  The ability to retrieve the applied configuration and derived state 
nodes in a single protocol operation.

4.C.: Be able to retrieve both the derived and non-derived state aspects of 
operational state together.

Or am I missing some subtlety here ?

Jason

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