=============================================================
NETCONF Data Modeling Language WG (netmod)
IETF #92, Dallas, USA
Monday, Mar 23rd, 2015, 09:00-11:30, Gold
Tuesday, Mar 24th, 2015, 09:00-11:30, Gold
Minutes Juergen Schoenwaelder, Dean Bogdanovic
=============================================================
WG Chairs: Thomas Nadeau
Juergen Schoenwaelder
WG URL: http://tools.ietf.org/wg/netmod/
Jabber: xmpp:netmod@jabber.ietf.org
Agenda:
Monday (2015-03-23):
1. Administrivia (10 min)
2. YANG 1.1 (60 min)
3. YANG Guidelines Update (10 min)
4. JSON Encoding of YANG Data (20 min)
5. Defining and Using Metadata with YANG (20 min)
6. AOB (YANG Language and Infrastructure) (5 min)
7. SYSLOG Data Model (20 min)
8. Entity-MIB Yang Model/Design Team Update (5 min)
9. Inventory Data Model (5 min)
Tuesday (2015-03-24):
1. Administrivia (10 min)
2. YANG Model Coordination (5 min)
3. ACL Data Model (15 min)
4. Core Routing Data Model (20 min)
5. Data Model Classification (15 min)
6. Consistent Modeling of Operational State Data (20 min)
7. Operational Structure and Organization of YANG Models (15 min)
8. Diffserv Data Model (10 min)
9. Peer Mount Requirements (5 min)
10. AOB (Data Modeling)
Summary:
The NETMOD working group met twice during IETF 92 in Dallas. The
meetings (Monday 09:00-11:30 and Tuesday 09:00-11:30) were attended
by about 120 people in each session. The YANG 1.1 effort has been
working on closing the remaining issues. A complete revised
specification is expected to go to WG last call in April. The work
on the YANG guidelines document update will follow once YANG 1.1 is
stable. The JSON mapping will be revised and cover YANG 1.0 and 1.1.
The data models worked on by the NETMOD working group (core routing,
syslog, ACLs) are progressing with the authors primarily resolving
review comments. Some routing data model related design issues have
been resolved. A design team recently formed to work on a data model
for physical components (based on the SNMP ENTITY-MIB) has met at
the IETF. Additional working group discussions centered around the
question how to classify and how to organize data models. Finally,
work on a data model for Differentiated Services has been presented.
Slides:
http://www.ietf.org/proceedings/92/netmod.html
Audio:
http://www.ietf.org/audio/ietf92/
Meetecho:
http://ietf92.conf.meetecho.com/index.php/Recorded_Sessions
Actors:
- JS = Juergen Schoenwaelder
- TN = Thomas Nadeau
- AB = Andy Bierman
- MB = Martin Bjorklund
- LL = Ladislav Lhotka
- BC = Benoit Claise
- KW = Kent Watsen
- BL = Balazs Lengyel
- PS = Phil Shafer
- BW = Bert Wijnen
- AS = Anees Shaikh
- DB = Dean Bogdanovic
- PH = Peter van Horne
- CW = Clyde Wildes
- JD = Jie Dong
- SH = Susan Hares
- JT = Jason Stern
- AL = Acee Lindem
- JH = Jeffrey Haas
- SL = Stephane Litkovski
- AA = Alia Atlas
- RS = Rob Shakir
- JZ = Jeffrey (Zhaohui) Zhang
- MJ = Mahesh Jethanandani
- KS = Kevin D'Souza
- EO = Eric Osbourne
- AC = Alex Clemm
- NS = Norm Strahle
- EV = Eric Voit
Meeting Notes:
* YANG 1.1
** VRFY :Y34: remove/deprecate/replace the 'anyxml' statement
The current solution proposal is Y34-05. No comments in the room.
** VRFY :Y45: better conformance mechanism
The current solution proposal is Y45-02.
LL: I am not very happy with this solution, it is way too strict.
LL: I think we should have a solution that works with imports.
MB: Solution Y45-02 seems to be the only one handling all aspects
and import-by-revision does not work.
MB: Import by revision everywhere leads to update ripple effects.
LL: There is not ripple problem, implementations have to deal with
multiple modules at different revision levels.
AB: I agree with Martin that the ripple effect is a problem. When
you want to use a new version of a module, you have to update
everything else that you use from the same module.
AB: I like the fact that you have to make an explicit change if
you want to use a new version of a typedef/grouping.
PS: The cost should be on the person who uses definitions. If
someone does not want to use the new definition, he/she could
copy the old definition into his own module.
JS: The problem with this is that you end up with a larger number
of modules that have copied a common definition and from there
on the N copies life a life on their own.
PS: It should be a decision of the owner of the module whether an
old definition is kept or not.
LL: I do not know how often it will happen that people want to stick
with old definitions; I kind of agree with PS.
MB: We have been discussing this for almost a year. At this point,
if someone has a new / better solution, we need a concrete
proposal not just some rough idea.
JS: There are many details that interact here. You can easily solve
every detail alone but then things fall apart if you look at
the global picture. The current solution proposal is very
simple but you publish definitions without knowing who is
using definitions. There are no side-effect changes, authors
have to explicitly adopt new versions of definitions and they
do not have to check themselves whether any of the imported
definitions has semantically changed.
AB: Import by revision is not used everywhere and it is actually
a burden to maintain the revision dates current during the
development process.
AB: Copying definitions into a local module seems to be a bad
solution since it is at odds of having common definitions in
the first place.
PS: I understand that Y45-02 is the simplest answer. But it is
also the most expensive and painful.
JS: We are going to send Y45-02 out for verify. But note that it
will not be sufficient I do not like Y45-02, to make progress,
it will be required to describe a new solution that does work.
Please check against the I-Ds AB and MB posted on the issues.
We have spent an extensive amount of time on Y45 and it is
time to wrap this up.
** OPEN :Y26: allow mandatory nodes in augment
MB explains the two proposals Y26-01 and Y26-02.
LL: I do not think we can specify rules that cover all situations.
My suggestion is to allow mandatory nodes in augments.
AB: Does this must statement only apply for updates?
AB: The case I am most concerned about is that a vendor introducing
module Y should not break an existing module X.
AB: I do not think we should allow breaking modules via mandatory
things in an augment.
LL: The presence container does not really make the new leafs
mandatory. Other constraints (must and when expressions) can
also break modules. I prefer guidelines text. Some of our
data models are designed to augment significant portions into
a core model.
PS: Y26-02 adds the cost of an additional container but the contract
of the augmented module is preserved and this matters.
The opinion in the meeting was leaning towards Y26-02.
** OPEN :Y36: associate a notification with a data node
MB explains the proposals. Y36-01 keeps notifications on the
top-level while Y36-02 puts notification definitions inline. The
discussions seems to be around the question how to encode these
inline notifications in NETCONF.
AB: One goal was to simplify access control, Y36-01 does not
help us with that.
JS: Is it possible to get some volunteers to look into Y36 in
order to work out an encoding proposal? Some people agreed
to look into the encoding aspects.
BL: If this is only for symmetry, then I do not support this.
JS: The benefit is simplified access control.
** OPEN :Y57: non-unique leaf-list
MB explains the issue and that proposals are documenting the
history of solution development. The current solution proposal
is Y57-03 (which is an updated version of Y57-01 and Y57-02).
MB: I am concerned making a lot of changes for a relatively small
use case and it affects how updates are made.
AB: Addressing by position is fragile. A leaf-list is a derivative
case of a list where the list has only a key.
LL: This does not make much sense of system-ordered leaf-lists. For
an AS path, the work-around is introducing a list but it would
be really helpful in this case. This should be restricted to
user ordered lists.
BL: I posted the solution a couple of weeks ago and nobody raised
any issues so far.
JS asks who has read the proposal and out of those who think the
solution proposal is sound and complete. A few people had read the
complete proposal and most of them felt the proposal is sound and
complete.
JS reminds people that we had another issue Y09 to introduce
optional keys which after quite some discussion has been moved to
DEAD for YANG 1.1. This current issue Y57 seems to be related and
the solution requires to introduce addressing by position. The
question is whether the gain given by Y57 is worth the effort of
adding addressing by position.
The opinion in the meeting was two supporting Y57-03 against a few
not supporting Y57-03. This did not look like strong consensus for
making this change.
PS: How do we decide what to add and what not to add?
JS: We go through all issues and for each of them we analyze the
trade-offs (benefits of the change, costs of the change, ...)
and then we try to find consensus.
PS: If you do not adopt it, then the data model needs to make an
artificial key. If you adopt it, then position oriented edits
need to be supported by servers.
PS: I find the solution proposal that a delete of a
deletes only the first a and I have to send N
times a to delete all N values 'a' surprising.
I would prefer if a delete of a would delete
all values 'a'. The whole idea of manipulating sub-members
of a list by position seems awkward.
JS: Yes, it is something we do not do anywhere else.
BW: Two voices in favor is not a strong position to add something.
BL: Even today, we do not have a way to handle a leaf-list as a unit.
If we want to change the semantics, this can be done.
JS: It could be done is probably not sufficient. We need to see the
value of the change with regard to the costs it has.
AB: One area where it breaks, we do not have something like if match
in NETCONF. Things so far are always identified by their name but
never by their value or position.
BW: For a big and not so simple change, I think you need more than
two people in favor.
It seems the meeting does not have sufficient support for adopting
Y57-03.
** NEW :Y60: coexistence with YANG 1.0
Several questions need to be addressed in a coexistence section.
- Will YANG 1.1 obsolete YANG 1.0 or not?
- YANG 1.1 modules importing from YANG 1.0?
- YANG 1.0 modules importing from YANG 1.1?
- ...
AS: Given the state of deployment we have, can we not obsolete 1.0
right now?
JS: I think the procedural question is less problematic. We do have
YANG 1.0 data models published. Perhaps we keep YANG 1.0 alive
until all YANG 1.0 modules can revised naturally and we might
require all new modules to be YANG 1.1.
DB: We should leave some time for implementations to catch up and
to migrate to YANG 1.1. There are many YANG models outside the
IETF.
JS: At this point in time, lets simply make Y60 an OPEN issue and
the text for this section will be worked out when the other
edits of the YANG 1.1 document are finalized.
AB: You can't use YANG 1.1 in reusable modules until the general
infrastructure is ready to support YANG 1.1.
The meeting supported to move Y60 from NEW to OPEN.
** Actions
- JS: post VRFY on Y34-05
- JS: post VRFY on Y45-02
- JS: post VRFY on Y26-02
- JS: report Y36 encoding meeting results
- JS: post VRFY for moving Y57 to DEAD
- JS: post VRFY for moving Y60 to OPEN
* YANG Guidelines Update
AB presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-6.pdf
BC: Prefixing examples with a common prefix and/or using the CODE
BEGINS convention. The later has relations to license regulations.
JS: The CODE BEGINS convention was introduced to support automated
extraction of YANG modules, not for license issues.
BC: There is text in the IETF trust web page, I will forward it to
the list.
DB: Using a special tag EXAMPLE BEGINS is likely easier.
BC: There is the convention of using ACME and since we will soon
have a WG with that name.
BW: An example may be incomplete and not necessarily compile clean.
JS: We will settle this likely with the help of the yang-doctors
mailing list.
LL: When expressions on different leafs have different context nodes
(slide 5) and hence even if they mean the same, the expressions
will be different. We should avoid redundant when expressions.
MB: I think we decided to not allow this for keys in YANG 1.1.
AB: I want to change a module to YANG 1.1 without anything breaking.
MB: In certain cases, you will have to make some edits since YANG
is in a few places more restrictive.
TN: Do we need YANG 1.0 guidelines and YANG 1.1 guidelines?
AB: No, we will move to YANG 1.1 and YANG 1.0 becomes history.
AB: There is likely not a problem here since you can't have
conditional keys anyway.
MB: We might not need a guideline on this since YANG 1.1 has an
explicit rule for this.
AB: The augment with mandatory nodes issue (slides 6-7) might be
obsolete now given the discussion of Y26 a couple of minutes
ago.
MB: There is already text in 6020bis concerning 64-bit numbers
(slide 8) and hence additional text may not be needed.
** Actions
- AB: Go through the mail archives to find any missed issues
- AB: Go through YANG 1.1 issues to find any missed issues
* JSON Encoding of YANG Data
LL presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-5.pdf
PH: Do you have any idea when RESTCONF will become RFC?
JS: You have to ask other people, come to the NETCONF meeting
tomorrow.
PS: I am confused by your interpretation of anyxml. I do not
understand the rationale.
LL: Anyxml is just anyxml since there was only NETCONF (which uses
XML) when YANG was created.
PS: You are saying anyxml is any data in any format?
LL: The issue of transforming XML to JSON is not addressed by
this document. If an anyxml node needs rules, then the data
model writer has to specify the rules.
MB: Since we add anydata to YANG 1.1, would it not make more sense
to encode anyxml as a string? Right now, it is by definition
not interoperable.
LL: But there are use cases where you have JSON that you want to
exchange and the idea is to carry that in anyxml.
MB: That really changes what anyxml is. It is clearly defined in
RFC 6020.
LL: There was no notion about JSON encodings when RFC 6020 was
written and this explains it. If we do CBOR in the future,
arbitrary CBOR will be transported in anyxml.
MB: I am not sure that we can change the semantics of anyxml in
this way.
LL: We already represent YANG lists as JSON arrays.
PS: The step from a YANG list to a JSON array is close to zero. I
do not think this justifies the new interpretation of anyxml.
LL: Even if we decide that anyxml is any XML, we will have some
technical problems to solve.
JS: In YANG 1.1, we are adding anydata with the goal that encodings
can transfer any YANG defined data in an interoperable
way. Should this document not cover both YANG 1.0 and YANG 1.1
and define how anydata is encoded? The goal is to have an
interoperable solution that works with multiple encodings. The
goal is not to have more non-interoperable encodings.
LL: RESTCONF depends on JSON and it might be faster to publish this
document based on YANG 1.0 and do an update later when YANG 1.1
is done.
AB: Nobody has ever demonstrated a server that supports arbitrary
XML with anyxml. Why do we spent so much time on something that
is not being used in an interoperable way? I think we should
move on with something that is interoperable.
JS: Should this document stay YANG 1.0 only or cover both YANG 1.0
and 1.1?
BC: We have several dependencies between the documents and it seems
we need to publish several documents together.
JS: My feeling is that we are relatively close with YANG 1.1 to have
it in WG last call in May.
MB: I agree that this is feasible. More reviews are welcome. I also
support that we cover YANG 1.1 in the JSON document.
The meeting supported to cover both YANG 1.0 and YANG 1.1 in the
JSON document instead of doing this in two steps.
LL: What about anyxml then?
JS: We for sure need to have text that explains how to encode
anydata in an interoperable way. This is of high priority. We
will need to settle how to encode anyxml but this is then only
for corner cases since the direction is that we do anydata in
the future instead of anyxml.
** Actions
- LL: revise the JSON document, adding support for YANG 1.1
- JS: still need to settle the anyxml encoding issue
* Defining and Using Metadata with YANG
LL presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-4.pdf
JS: We had a call for adoption some time ago and the controversial
comments were related to the examples in the document. I think
the golden rule must be that metadata must be data that can be
safely ignored. Anything that changes behavior is not metadata.
LL: The document says that semantics of metadata are specified
elsewhere, this is really just defining the syntax.
PH: I assume that organizations will have their own way of carrying
metadata.
The meeting supported the adoption of this document.
** Actions
- JS: another call for adoption to verify the support of the meeting
* AOB (YANG Language and Infrastructure)
JS announces that he plans to step down as NETMOD co-chair when the
YANG 1.1 work has been finished. People interested to become NETMOD
co-chair should contact BC.
* Hackathon Notes
BC reports about a tool created during the IETF 92 hackathon that
extracts YANG modules out of IDs.
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-7.pdf
TN: It is helpful if YANG authors read the guidelines document.
* SYSLOG Data Model
CW presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-8.pdf
No questions were asked.
* Entity-MIB Yang Model/Design Team Update
TN explains that the design team was started just recently in order
to provide a YANG data model covering physical components. The
design team will meet later during the IETF 92 to discuss what needs
to be covered and how things can be done in a way that is backwards
compatible with existing SNMP instrumentation.
BC: The background is that inventory proposals in the I2RS started
to create data models that overlap with the ENTITY-MIB.
SH: What is the timeframe of the design team?
TN: The team will meet once per week and post an update once per
month so ideally this is complete in a few months.
* Inventory Data Model
JD presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-3.pdf
SH: This started as a natural extension of the topology work in I2RS
but falls somewhat outside the scope of I2RS and hence it got
moved here.
* YANG Model Coordination
BC described the recently started efforts for YANG data model
coordination. He introduced the YANG model coordination team. There
are 113 YANG models in the IETF, YANG is used or considered to be
used by several other SDOs, consortia, and open source projects.
YANG training material is being created and work is underway for a
YANG model repository. More details can be found on the OPSAWG
meeting slides:
http://www.ietf.org/proceedings/92/slides/slides-92-opsawg-2.pdf
* ACL Data Model
DB presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-12.pdf
JS: Is the ACE list ordered by user or not?
DB: Our suggestion is ordered by user. But the system may sort them by
number.
JS: The order matters. If you use ordered by user, then numbers do
not matter. Or the numbers matter, but then it is not ordered by
user.
PS: If they are ordered by user, the system can't sort them.
PS: If you use ordered by user, then why not use names instead of
numbers?
DB: We wanted to use names, there was a comment to go back to sequence
numbers.
PS: I am against using numbers.
JT: I want a way to allow both types of systems to support this module.
Systems that use sequence numbers internally will have a hard time
to support ordered by user. Perhaps the order can be augmented into
the list. Operators will get confused if the order is not consistent
with the numbers.
PS: You can't augment an ordered-by statement.
AL: An access list since beginning of time has been ordered by sequence
number.
PS: My implementation since the beginning of time as used names.
JT: There is clearly a mix of implementations out there. Perhaps this
can be made a feature?
MB: You can't have an if-feature on the ordered-by statement. If the
list is ordered-by user, you can easily map the position of each
list element internally to a sequence number.
JS: A list can only be ordered in one way. We can decide about the
order. Not sure what the alternatives would be, two lists?
LL: We could have a choice with an if-feature.
JS: How does the choice help?
LL: The proposal is to have two separate lists in a choice.
Three options:
(1) two lists - 5 hands
(2) sequence numbers / ordered by system - 2 hands
(3) names / ordered by user - 7 hands
AL: If you have the name as a tag, it will not be interoperable.
DB: With sequence numbers, you will end up with renumberings, which
is a performance problem.
AL: Each access list will have a name. You want each ACE to have a name
as well. If you do not have a sequence number, how does the system
know where things go?
PS: If you have names and you need numbers internally, simply use the
position.
MB: An ordered by user list means that the server has to maintain
the order given by the client. This is interoperable across
implementations.
AC: Maybe the draft should explain better how this works if we go
with a name for an ACE.
JH: User ordered means that an ACE is inserted into a list based on
how a user inserts it. The name (key) lets you refer to it but
it is not used for ordering.
** Actions
The draft needs to better document how ordered-by user works and
can be implemented on systems that internally use sequence numbers.
* Core Routing Data Model
LL presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-9.pdf
PS: Have you considered to use features for modularizations instead of
making things separate YANG models?
LL: I think it is a better design pattern to have separate data model
augmenting the proper choices.
PS: Can an interface be in multiple routing instances?
LL: This is an open issue, will talk about it later.
AL: I think the main goal is to agree on the base hierarchy since
several other models will depend on it.
JH: Was the question of multiple routing protocol instances (e.g.,
OSPF) brought up when routing instances were discussed?
LL: You could have multiple routing protocol instances already
before routing instances were discussed.
** Issue #1: instance vs. protocol-centric design
LL: A poll of opinions on instance vs. protocol-centric design
(slide 6) did not lead to a clear answer.
PS: You should ask operators and vendors since vendors like their
approach always most. That said, the routing-instance-centric
approach has nice isolation properties.
SL: The routing-protocol-centric approach has nice inheritance
properties but we can emulate that with templates in the
routing-instance-centric approach.
SL: In terms of operational feedback, it seems people tend to
prefer whatever they are used to. That said, I lean towards
the routing-instance-centric approach.
LL: Yes, people seem to like what they are used to.
AL: We did not reach consensus in the poll except that operators
want to have it done in one way.
JH: Both models are perfectly fine for a single management plane.
In multiple management plane, things become tricky. The
routing-instance-centric approach nicely maps to a set of
things, like the SNMP community string approach to distinguish
multiple similar instances of things.
CM: It would be interesting to hear from people who _program_
things. The notion of templates is odd for most programmers
but likely more useful for CLI users.
LL: The template idea is a special type of routing instance that
provides default information to other routing instances.
CM: But one could easily argue that this template could also reside
on the managing system, why do you want to waste storage on the
router for storing templates?
LL: I hope we will discuss templates soon on the routing
coordination mailing list.
AA: We are going to charter a routing area design team that will
look at the routing data models and how to make them work
together and to look at certain conventions to be used in
routing data models. The design team will also look at
extensibility. I do not see this routing area design team
directly impacting this model, it is more an orthogonal effort
to this.
LL: We have been trying to make the core routing model as extensible
as possible. Sure, there are still some assumptions we make, but
we try to be extensible where extensions can be reasonably be
expected.
AA: Yes, the routing area design team is more about documenting
how to make YANG data models extensible.
JS: Wonderful news. Is there a time line for the design team?
AA: The goal is to get the metamodel (how things fit together) out
by the next IETF. The other aspects may take more time. The
reason this is routing centric is that we need to keep the
work scoped.
RS: We should not think about people typing into the CLI, the goal
here is programmability. So we need to think about the operation
that people want to automate. From this perspective, the
routing-instance-centric model seems to make more sense to me.
LL: I believe mappings between the two models are possible.
RS: We should push this forward in order to get experience with it.
AL: I have looked into mappings of both directions and they seem to
be possible. It may be easier to map from a
routing-instance-centric model to a routing-protocol-centric
backend than from an routing-instance-centric backend to a
routing-protocol-centric model.
The meeting room showed a very strong and clear preference for the
routing-instance-centric model (many in favor, nobody in favor of
the routing-protocol-centric model).
** Issue #2: RIB Placement
LL: Current proposal is to move back to have RIBs per routing
instance instead of global RIBs.
SL: Global RIBs do not make sense to me. You can't share a RIB
between routing instances.
Nobody was speaking up in favor of global RIBs, hence this will be
changed back to have RIBs per routing-instance.
** Issue #3: RIB Connections
AL: There should be a feature to have multiple RIBs per address
family to support multi-topology routing that some platforms
support. The RIB should be contained in a routing instance and
as a feature there could be multiple RIBs per address family.
LL: This is not only a Juniper feature, the Bird routing daemon
has something similar.
JH: I am happy to have RIB connections removed. Routing protocols
interact with RIBs and RIB groups could be modeled as a logical
entity that passes information between RIBs.
LL: I am OK with removing this from the core model because this can
be added via augmentations.
Nobody was speaking up against removing RIB connections from the
core routing data model.
** Issue #4: Interface Assignment
JZ: Assignment to routing instances not only makes sense for IP layer
interfaces.
JZ: I could see that an IPv4 interface belongs to one routing
instance and an IPv6 interface belongs to a different routing
instance.
LL: For some interfaces, it does not make sense to assign them to
any routing instance.
JZ: There are already IPv4 and IPv6 specific containers for IP
interfaces (RFC 7277). They could be reused to scope things.
AL: This may be a better place to point to. Anyway, if we do have
two IP layer lists, we need guidance which one augmentations
should augment.
Further discussion on the mailing list is needed.
** Issue #5: IPv6 RA Parameters
AL: If we did not have RFC 7277, I would agree it does not make
a difference. But since we already have RFC 7277, we should
augment ip:ipv6.
Further discussion on the mailing list is needed.
** Remarks
BC: Since this core data model is very important, we may want to
wait with publication until at least one routing protocol
specific data model is done as well. Ideally, we would even
have some implementation experience before we publish this as
an RFC.
LL: I agree that we need to get this right and once published as
RFC it will be way more difficult to make changes.
* Data Model Classification
DB presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-13.pdf
MJ: I agree with CM that two levels are sufficient.
MJ: Proprietary extension to a standard model is just a proprietary
model, I do not see the difference you are making.
DB: An example is a match condition augmented into a standard model.
BC: The SYSLOG data model will focus on common features and vendors
will augment the standard data model with their specific
extensions.
RS: I do not care so much how many layers there are. What matters
is the abstraction between the layers. And this also relates how
operators are internally organized.
JH: There is a need for common names for knobs that are proprietary
but supported by multiple vendors.
??: Business model, service model etc. should be covered by an
information model. Component models should be covered by a data
model. We need an information model architecture in
addition to a data model architecture.
JH: The high-level architecture does not get specific to the point
that it prescribes implementation. That should probably be
clearer in the slides.
KS: There should be some abstraction between service model and the
element model. The Service Model should be neutral. Perhaps
that's what you mean by the YANG model.
DB: I can create a service model solely using proprietary YANG models.
KS: But this is going to be very hard for us to map.
DB: You have a choice how the service model is created.
KS: We also need some neutral model in the middle. It has to be
instantiated also outside of the element, e.g. a controller.
DB: You have to know what your devices do support.
KS: But there are always some devices that support things and other
devices that do not support things.
CM: You are far ahead of us. The decomposition is still open to be
worked on. I agree this is not in scope what we are doing now
and it is something we will have to take on.
EO: The idea of the IETF defining a service makes me nervous. The
fact that the IETF does not define service is a feature.
DB: We are not saying the IETF is going to define services. All we
try to come up with a taxonomy that works ideally across SDOs.
EO: As long as this does not lead to a proliferation of service
models, I am fine. We need to avoid feature creep.
BC: Service models in the IETF are an open question. We could do a
design team in the IETF to do this. We did this for L3VPN. We
have a new WG approved on Monday. I don't believe we should
have all services, but this one, yes.
AC: You have multiple dimensions and it makes sense to distinguish
them. Whether something is proprietary or standardized crosses
the layering hierarchy.
DB: This means splitting the orchestrator box also into two parts.
RS: The value of the L3 service model is (a) that we figure out
whether all service level knobs actually map to something in the
element models and (b) the decomposition work itself.
Identifying the primitives used to build services is useful.
EO: Primitives are great but we do not want to market RFC XYZ
services.
PS: There is a motivation between vendors and operators to have open
standards that drive tools to automate interaction with equipment.
What is the motivation for service modeling?
DB: We just want to define a taxonomy.
Further discussion on the mailing list is needed.
* Consistent Modeling of Operational State Data
AS presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-10.pdf
DB: If we adopt any of this, we should fold that into the RFC 6087
update.
TN: You also talked about changes for NETCONF.
NS: Is this a way to do better error handling, e.g., errors due to
a (transient) lack of resources?
AS: You can observe state data based on which you can decide what to
configure next. There is difference here between synchronous
transaction driven systems and asynchronous systems.
EV: Have you though about synchronization across multiple devices?
AS: Not really, we have so far focused on a single device.
PS: Why not use an operational state datastore? This seems pretty
simple, no?
AS: We have not thought much about this. Having things marked up in
the data model has advantages. It is not clear having an
operational state data store is sufficient.
BC: Thanks for sharing experience. What about existing RFCs? Do you
ask to change them?
RS: This is just a strawman. There is the question about datastores
and does the protocol have proper support to access separate
datastores.
TN: There are models in published RFCs. Does this affect them?
AS: We need some common convention for operational state.
JS: For the data models produced by the WG, we actually paid quite
some attention to operational state. This may not be as visible
from the drafts but quite some discussion of operational state
has gone into the design of say the interface data model. If
there is a better way, it needs to be significantly better to
justify the costs of changing data models published as RFCs.
AS: The problem may be more for work in development rather than
published models. That said, if you put models together, you
get a tree that looks somewhat suboptimal.
CM: It will be useful to have a programmer's view here. If things
are asynchronous, then you also need notifications.
AS: Yes, we have to move towards a continuous streaming model for
incremental updates.
JH: Structural separation is a good thing. I was hoping for a
request for NETCONF to define a get-op-state as an alternative
to the get operation.
AS: Yes, this would be nice to have, but it would be nice to have
a distinction in the data model.
JH: For the data models, you likely want foreign keys that make it
easy to correlate information.
BL: Finding state data for a specific configuration item is a
problem for us as well.
??: Have you implemented your proposal? There are performance impacts.
AS: The content of the different subtrees or the different datastores
is different. We have implemented it on the consumption side, but
not on the devices yet.
??: For us, this seems costly to support.
EV: There is a pub/sub requirements document in I2RS.
SL: For routing protocols, we augment the core routing data model and
we will not have many nodes at the top-level.
AS: But this works if there is a suitable model in place already.
AS: We came to the conclusion that the split between config and
operational state data is either done at the beginning of the
path or the end. This raises the question what is the beginning
of the path.
Further discussion on the mailing list is needed.
* Operational Structure and Organization of YANG Models
RS presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-11.pdf
DB: Why do you not intend to be extensible?
RS: We do try to be extensible, we do not try to be exhaustive.
AB: Where the data lives in the tree is almost irrelevant. We need
an outside classification instead of trying to encode semantics
into the tree.
Further discussion on the mailing list is needed.
* Diffserv Data Model
MJ presented his slides:
http://tools.ietf.org/agenda/92/slides/slides-92-netmod-2.pdf
Further discussion on the mailing list is needed.
* Peer Mount Requirements
Canceled - meeting did run out of time.
* AOB (Data Modeling)
Canceled - meeting did run out of time.