Minutes IETF102: netmod

Meeting Minutes Network Modeling (netmod) WG
Title Minutes IETF102: netmod
State Active
Other versions plain text
Last updated 2018-08-07

Meeting Minutes

> NetMod Minutes For IETF 102

> Session 1:
> TUESDAY, July 17, 2018
> 1330-1530 Afternoon Session I
> Place du Canada
> Audio stream:        http://ietf102streaming.dnsalias.net/ietf/ietf1025.m3u
> Session 2:
> FRIDAY, July 20, 2018
> 0930-1130 Morning Session I
> Laurier
> Audio stream:        http://ietf102streaming.dnsalias.net/ietf/ietf1023.m3u
> Etherpad:       
> Meetecho:        http://www.meetecho.com/ietf102/netmod > Jabber:      
 xmpp:netmod@jabber.ietf.org?join > Available post session: > Recording: 

> YouTube:

> TUESDAY, July 17, 2018
> 1330-1530 Afternoon Session I
> Place du Canada
> Audio stream:        http://ietf102streaming.dnsalias.net/ietf/ietf1025.m3u
> Presentation                Start Time        Duration        Information
> 1                13:30        10        Title:        Intro, Charter &
WG Status > Presenter:        Chairs > Draft:        N/A Joel Jaeggli
presenting > 2                13:40        15        Title:        Interface
Extensions > Presenter:        Rob Wilton > Draft:       
https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang >

Rob presenting
Lada (Ladislav Lhotka): These are very good drafts, but IEEE models are
difficult to implement for simple devices. Is there an options or liason to
provide review of their modules? Rob: It's too late as their models are quite
mature. IEEE have their own configuration model already for those devices. I
would have liked to see them reusing like the sub-interface constructs and
things that doesn't actually necessarily work with their model. And I've given
examples of how to use sub-interfaces with the LTL TPM model. That allows you
to do transparent bridging. Lada: Really need something simpler (from IEEE)
Scott Mansfield: Issue of YANG coordination is being taken serriously by IEEE
and already working with ITU. .1Q document is "done" there are other modules
proceeding in IEEE. There are opportinities for collaboration: monthly
meetings, etc.  IEEE is using YANG Catalog. Put comments there. there is also
meeting of a yang group in the IEEE the last Wednesday of every month and there
is an ITU call last the third Monday of every month Lou Berger: Scott, what do
you think about Lada's liaison suggestion. Scott: Liasons are useful but better
to raise on an individual level Rob: there are 2 fundamental issues, IEEE and
IETF being done in parallel Scott: talking now would be good, future models
should be more module Lou: does this issue is enough of an an that it rises to
the level of having a coordination for next meeting Scott: Suggest coordination
with a subgroup would be worthwhile Rob: there is already some discussion
taking place Lou: We (chairs) will follow up offline

Rob: I will draft a liaison that can be used to inform IEEE of status.
> 3                13:55        10        Title:        YANG Module Tags
> Presenter:        Chris Hopps
> Draft:        https://tools.ietf.org/html/draft-ietf-netmod-module-tags

Chris presenting
Joel: who has read it (this or prev): a healthy number
Joel: who thinks it's ready: a good percentage who have read
Joel: who thinks it is not ready: none
Joel: We will take it to the list

> 4                14:05        20        Title:        YANG Data Extensions
> Presenter:        Kent Watsen
> Draft:        https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext

Lada: It¡¯s really something that's needed and it's very convenient that you
can define some scheme of independent of encoding. But concern as proposing it
at a standard implying that it is a normal way of using YANG, when it really
isn't.  Slippery slope, if we want to do this, then should continue to RFC
8040. Kent: Your concerns apply to RFC 8040. Lada: In restconf RFC8040, there
are some rational way. This seem to be making it more official. Lou: Why do you
think that it isn't a standard before (in RFC 8040) Lada: Because it make the
community more aware of it. Kent: Your concern really is about extensions,
would it help if there was an applicability statement. Lada: If it a proposed
standard then expect folks would use it. Lou: Is it that you don't like
extensions of the specific YANG data extension? Lada: I don't like an
extensions that change yang semantics. Question of scope about what is being
done in extensions.  As soon as we change what it is in RFC 7950 then it is a
problem. Lou: Since this is already an extension in RFC 8040.  Perhaps it would
be good to do a draft to explain how extensions should be allowed. Lada: Now
have YANG data augment, which wasn't in RFC 8040.  Undermines the value of YANG
in a standard. Rob: Would you be happy if this was done as part of a Yang 1.2
or Yang 2.0, or do you object to idea of YANG data? Lada: I would be happy if
it was done in the a new YANG specification.  Could be done in a small draft
(to define yang independent of data stores.) Kent: To clarify, if a new version
of YANG, then it could be a top level statement. Lada: I'd prefer YANG be
generic and be usable to model data without being tied to

How to proceed:
#1 define both "yang-data" and "augment-yang-data" (a few)
#2 only define "augment-yang-data" (no one)
#3 un-adopt draft (almost same to #1)

Joel: who can not live with #1 (no one)
option 1 selected: mostly because no one said that they could not live with it
Lada: I can use #1 even though I don't like it

WRT slide 6: Some felt it could be legal, most felt that it should not be legal

Rob/Lou: would be good to define a statement (draft?) that clarifies our
[mis-]use of the extension statement here.

> 5                14:25        65        Title:        YANG Model
Versioning Design Team > Presenter:        Rob Wilton > Draft:       

Rob presenting
Chris Hopps: Fan of using namespace to indicate non-backwards compatable
revisions, but Req1.2 states the namespace must be the same. Rob Wilton: It
depends on how well people are play to the code to the clients, and whether
people are using fixed paths. Tim Carey: About rq1.2: As a client, I don't know
that this is not backward-compatible, that data node I'm using right. Rob
Wilton: (Rq 1.2 ) It's not the intention to be saying the clients can find out
that there's something's changing in non-backward compatible way. Italo Busi:
What about clinets that are upgraded talking to an old server? One use case
could be a hierarchical controller talking with multiple domain controllers,
some of which are not updgraded to support the new model version. Rob: Thinks
that this is a request to what is being offered instead (of not having forever
backwards compatibility) Igor Bryskin: If you have a model that is not
backwards compatible.  There are cases where one client can talk with multiple
servers: if there is no common ground you have an issue. Balazs Lengyel:
(responding to Igor/Italo) You can just obsolete or deprecated something nodes.
I think a client has to check the revision of all modules before really
working. Alex Clemm: Why limit data nodes, or also includes rpcs,
notifications, etc.? Rob Wilton: Could be more generically stated as "schame
nodes" Kent Watsen(contributor): existing clients *today* clients or some
future existing clients Rob Wilton: Mean today clients Kent: Okay, so this
speaks to the migration/transition strategy Chris Hopps: This is a requirement
that actually pops out, because of you saying that you need to be able to have
multiple modules without different namespace names. Rob Wilton: Yes. Chris
Hopps: We're creating problems that didn't exist before. You can have multiple
modules if they have different namespaces Lou B: If you have an idea, it's
worth discussing Chris Hoops: I'm just I'm making comments Gert Grammel: Want
definition of what is/is not backwards compatible Rob: Using RFC definition
Vladimir Vassilev: Be careful of over engineering and overly complex solutions
Chris H: Stating that the namespace cannot change limits solution space Balazs
L: Disagrees, chaning namespace causes too many other changes Chris H: Maybe
restate Req1.[1/2] to indicate goal without suggesting a solution Lada L: The
option of changing the name of whom are already here. It is not a not good way
to do this. If we want to change module names that we can.

Lou B:How many people are comfortable w/ req as modified by today's discussion
(Req1.2, and flexibility): a reasonable number Lou B: How many people are
uncomfortable: one (already stated issue at mic) Lou B: Home many think that we
should not be talking about this? no one

Lou: We will poll the list soon

Kent (contributor): Any requirement needs to be added to support yang-data?
Rob/Lou: Sounds more like a yang-data problem

Lou: What's the best way for folks to bring ideas to the Design Team?
Rob: Just drop an email (netmod-ver-dt@ietf.org)

> Adjourn                15:30
> Session 2:
> FRIDAY, July 20, 2018
> 0930-1130 Morning Session I
> Laurier
> Audio stream:        http://ietf102streaming.dnsalias.net/ietf/ietf1023.m3u
> Presentation                Start Time        Duration        Information
> 1                9:30        5        Title:        Intro
> Presenter:        Chairs
> Draft:        N/A

> 6                9:35        15        Title:        Comparison of NMDA
datastores > Presenter:        Alex Clemm > Draft:       

Alex presenting
Qin: Compare different datastore or same datastore at different time. When will
start? Alex: There is no time option and state aspect. RPC is performed when it
be requested. Rob: Agree with Qin's comment that the doc should mention what
happens when the schema differs between two datastore.  You might want to have
an option to exclude nodes that are present in the schema in one datastore but
not the other.  It would also be useful to have an option to decide whether on
original metadata is part of the operation. Lada:Support! And one use case
could be connected with restconf transactions document - emerging the staging
repository into .

Balazs Lengyel: Will the patch always use create or merge.  Just have one way
to parse the difference (e.g. don't sometimes report as creates, other times as
deletes). Alex: There is a choice here or where it is just reporting the
difference Balazs: Agree that it is enough to just know the difference. Reshad
Rahman: Question about why the draft has moved from NETCONF WG to NETMOD WG.
Alex: The recommendation of the chairs was to move from NETCONF WG to NETMOD
WG. Kent: It is closely related to NMDA work, so it seemed to make sense to
move it here.

Lou: how many think we should be working on this problem? (a really good number)
Lou: How many have read this document.  £¨Also a really good number£©
Lou: How many think we should adopt this document (also a really good number)
Kent: How many think we should NOT adopt (None)
We will confirm on list

> 7                9:50        15        Title:        YANG Instance Data
Files > Presenter:        Balazs Lengyel > Draft:       
https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data Balazs
presenting Open Issue 1 : Shall we recommend as a general practice: Servers
SHOULD document their capabilities using instance data? Rob: I prefer there is
not in this document. Suggest to keep this draft more abstract in terms of how
to define the instance data. Kent: How to publish the instance document? Joel:
I think we need a method there. I don¡¯t think it need to be done in this
draft, but this problem should be solved in a particular way. Jugern (On
Jabber):This is misplaced a file format specification in a file format
specification. Lada: This should not be in this document because this data
format is quite generic and can be used for any number of other proposes. Tim:
Some other drafts talk about factory datastore, is there different? Balazs :
This is about getting information before you actually have the network nodes
available. Rob: The factory datastore is the default configuration where the
device comes up. Balazs: This give the way for ¡°factory datastore¡± but
doesn¡¯t prescribe that. Tim: Just want to figure out that what the connection
of ¡°instance data¡± and ¡°factory datastore¡±. Rob: I don't think you get the
interoperability if you need to publish this data. Lou: It's OK to have a draft
to introduce that you implementation like report some information, but how to
report it should outside the document. Adrian: it's not directly related but
this could intersect with mud in the future, should take a look at that work.
Balazs: Support defining a separated document to introduce how to report
capability? (a few)

Open issue 2 : Should we use yang-data-ext to define the instance data module?
Kent: Any data is not a part of datastore.
Lada: Lada: Without yang data extension, it just defined some schema, so if a
server decides to implement it, I don¡¯t see anything wrong. Xufeng Liu:You not
try to redefine the datastore, right? -- Balazs: No. Balazs:Support using
yang-data-ext: (a reasonable number / few)
    Against using yang-data-ext: (very few)
Joel: (To Lada) You cannot define the metadata that one might want to include
your instance data. some solution for augmenting to be able to say I want to
add this metadata. I think we need for something for that.

open issue 2(second bullet): Shall we add a datastore parameter for config=true
data? Rob: I think if the dates approach was included, it would be an optional
thing.  And you least need a flag to say it is configuration data or operation
data. I think you need more indication as what the data is. Lou:It seems like
we're mixing some concepts which are really the data representation focused on
build a representation and the other concepts items that are focused on how we
are moving that representation or restoring that representation.

open issue 3: Allow mulitple instance-data-sets in one file?

Lada: In your document it said that this data is stored in the file then the
file name should encode the version. I think this is a really bad practice.

Lou: How many people think this document should  be adopted now -- current
version? (a few)
   How many people would like to see an updated based on today's discussion and
   then adoption? (less) How many people oppose this document? (none)

Chairs will discuss off-line then send something to the list

> 8                10:05        15        Title:        Handling Long Lines
in Artwork in Drafts > Presenter:        Qin Wu / Kent Watsen > Draft:   

Qin presenting..
Rob: Maybe also be used in yang tree.
Igor Bryskin:Auto extraction better
Lou:How many people think this should be done in this WG (a good nulmber)?
Dean Bogdanovic: Opsawg WG may be a better pleace.
Adrian Farrel: if a graphical artworks cannot fit the 68 character width,
folding it would be it even worse Kent: the draf says that it is NOT
RECOMMENDED to use this solution for graphical artwork, you would like this to
be changed to a MUST NOT use Adrian: yes

> 9                10:20        15        Title:        Generalized Network
Control Automation YANG Model > Presenter:        Xufeng Liu / Igor Bryskin
> Draft:       

Xufeng Presenting...
Interesting in this work (a few)
Not interesting in this work (a few)
Andy like the idea but not all the solutions.(Jabber)
Tim:We know we have the problem but I think there is a finite state document.
Suggest you guys get together and see if you can come in with a decent
solution. Lou: Do you discuss with the author of FSM? Xufeng: Not yet. Lou:You
need spend some more time with FSM document to figuring out where there's
overlap or there's not. Igors: Implement or experimanet? If it can implement,
it more valuable to do.

> 10                10:35        10        Title:        YANG model for
finite state machine > Presenter:        Nicola Sambo > Draft:       

Nicola Sambo remote presenting..
Lou: Do you think it need to discuss with ECA draft?
Nicola: Yes, ECA is more generic.

> 11                10:45        15        Title:        Yang data model for
Terminal Access Controller Access Control System > Presenter:        Bo Wu /
Zitao Wang > Draft:       

Michael presenting..
Joel: Back when I was ops-AD: We started work to document how tacacs+ is
implemented today in the industry, we are not looking to add more to that draft
(extensions would go in new drafts). This work would seem fit in OPSAWG. Ignas:
Current tacacs+ works not looking to add more feature. A module for tacacs+
seems to be needed. If you talk about system, those two protocols can be
selected by the choice. So it may be a good idea to try to work on AAA system
framework and then have tacacs and radius put into that. > Adjourn