Subject: [netmod] draft netmod 94 minutes posted

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Nov 2015 18:32:06 +0000

All,

The minutes for the two NETMOD sessions have been posted:

    https://www.ietf.org/proceedings/94/minutes/minutes-94-netmod

Please provide comments/corrections on these draft minutes by Wed, Nov 25th.

PS: huge thanks to Ignas and Andrew for putting these together!

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Nov 2015 10:05:00 +0100 (CET)

> Please provide comments/corrections on these draft minutes by Wed, Nov 25th.

I got a comment based on the minutes that it seems like we are
suggesting that people should not use "choice" at all.  I listened to
the recording, and I believe some crucial points were lost:

On page 7:

OLD:

[RS]  if we want to simplify things, we need to remove choice completely.
[MB]  L that is likely a good idea.
[RS]  you need to track which branch gets used. It does not explicitly
      does not show in the tree. And  
      for those who do not like they could not implement it.
[MB]   maybe it is only applicable to very small trees only.

NEW:

[RS]  if we want to simplify things, we need to remove choice
      completely.  I am not proposing that we do this.
[MB]  I agree.
[RS]  you need to track which branch gets used. It does not explicitly
      show in the tree. And  
      for those who do not like they could not implement it.
[MB]  The data model designer needs to use these constructs carefully.
      "choice" is often used in very small trees only.

And to further clarify things, I do *not* think we should make this
"simplification".  "choice" and "when" are both useful.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 24 Nov 2015 14:22:34 +0000

Hi Kent, Andrew

Do you have a pointer to the recordings please?  I tried the audio 
streams on the link below, but I can't seem to get them to work.

https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html

Thanks,
Rob

On 17/11/2015 18:32, Kent Watsen wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Nadeau Thomas <[email-masked]>
Date: Tue, 24 Nov 2015 09:32:52 -0500

It doesn't work for me either. I’ll file a case with the support folks to take a look.

	—Tom

> On Nov 24, 2015:9:22 AM, at 9:22 AM, Robert Wilton <[email-masked]> wrote:
> 
> Hi Kent, Andrew
> 
> Do you have a pointer to the recordings please?  I tried the audio streams on the link below, but I can't seem to get them to work.
> 
> https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html <https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html>
> 
> Thanks,
> Rob
> 
> 
>>     https://www.ietf.org/proceedings/94/minutes/minutes-94-netmod <https://www.ietf.org/proceedings/94/minutes/minutes-94-netmod>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 Nov 2015 15:36:26 +0100 (CET)

> https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html

Try this one:

http://ietf94.conf.meetecho.com/index.php/Recordings

/martin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 24 Nov 2015 14:48:09 +0000

Thanks, Martin.  That works.

Rob

On 24/11/2015 14:36, Martin Bjorklund wrote:
> .

---

From: Kent Watsen <[email-masked]>
Date: Tue, 24 Nov 2015 14:53:13 +0000

>> https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html

When clicking on the “audio stream” link:

  - Safari says “ This webpage has content that requires an Internet plug-in.
    This page contains content of “audio/x-mpegurl” type. You do not have the
    plug-in required to view this content.  I clicked the “missing plugin”
    link, but it didn’t do anything.

  - Firefox offers to save the file or load with iTunes.  Loading with iTunes
    doesn’t work.  Saving to file and then examining its contents shows
    "http://icecast-ietf.conf.meetecho.com:8000/room301.mp3”, which looks
    like it’s more for the live stream as oppose for a recorded stream.

>http://ietf94.conf.meetecho.com/index.php/Recordings

This worked for me in Firefox, but not Safari (it spins forever trying to load the page)

Thanks,
Kent

---

From: Robert Wilton <[email-masked]>
Date: Tue, 24 Nov 2015 16:59:20 +0000

Hi Kent,

I've some minor modifications of some of the minutes, mainly just to 
clarify who was asking some of the questions/comments (mostly between 
Rob Shakir and myself), but also some other minor clarifications when I 
was listening back to the audio.

[Before]

10 min: draft-ietf-openconfig-netmod-opstate-01    (Anees Shaikh or [RS] Shakir)
Rob Shakir presenting.
[LL] Would it be possible to have multiple management interfaces (NETCONF, RESTONF, other) - is the intended configuration supposed to be private per transport protocol?
[RS]  Would think no. There is one intended configuration per device.
[LL] this may have some locking implications.
[TC]  Why did you chose to use intended/applied approach?
[RS]  This allows us to use YANG today.
[KW] there were 3 solutions drafts.
[TC]	we are doing the same thing in BBF, and would like to mimic the solution agreed here.
[AS] There is a section i a draft that addresses this.
[LB]  I am confused on the process for the requirements. You said you will make consensus call for requirements today?
[KW] we will do a consensus call on solutions. I believe there is consensus on requirements.
[LB]  on a list there was a discussion on planning to poll for consensus but that did not seem to happen.
[KW] confirming consensus on requirements now by humming - consensus achieved.

[After]
10 min: draft-ietf-openconfig-netmod-opstate-01    (Anees Shaikh or [RS] 
Shakir)
Rob Shakir presenting.
[LL] Would it be possible to have multiple management interfaces 
(NETCONF, RESTONF, other) - is the intended configuration supposed to be 
private per transport protocol?
[RS]  Would think no. There is one intended configuration per device.
[LL] this may have some locking implications.
[TC]  Why did you chose to use intended/applied approach rather than 
using datastores?
[RS]  1. No such thing as an applied datastore today.  This solution 
allows us to use YANG today. 2. Our solution allows for a single path 
that is not dependent on the datastore.
[KW] there were 3 solutions drafts.
[TC]    we are doing the same thing in BBF, and would like to mimic the 
solution agreed here.
[AS] There is a section in our draft that addresses some of these 
questions.
[LB]  I am confused on the process for the requirements. You said you 
will make consensus call for requirements today?
[KW] we will do a consensus call on solutions. I believe there is 
consensus on requirements.
[LB]  on a list there was a discussion on planning to poll for consensus 
but that did not seem to happen.
[KW] confirming consensus on requirements now by humming - consensus 
achieved.

[Before]

10 min: other solutions for the opstate-reqs (Robert Wilton)
Robert Wilton presenting.
[RW]  no changes to existing YANG models - that does not seem to be practical. There are vendor extensions anyway.
[RW] Wilton  if models are standardised in IETF, they should work in all cases.

[KW] we would like to know which of those solutions should progress forward.
[Rw]  would be nice to poil for who has read the solutions drafts?
[KW] who would favor solution 1. Humm. 2. Humm (most). 3. Humm
[KW] Does anyone object to solution 2? Please go to mike?
[Rw]  Didn't we do that already? We seem not to going anywhere forward with this discussion. We did clarify wording, but that is mostly it. It is noting for operator to help with configuring a network. Is it a perfection problem here? Can we produce something practically useful?
[CM] There are large installations based on existing YANG specifications.
[RW]	I take that into account. I have none in my network though that use existing model. I am not saying that we should throw away the existing solution in favor of the future solution.
[CM] There is a technology shift.
[CH] We are not forcing to implement some particular data store technology. This is more of a way of thinking of it.

[After]
10 min: other solutions for the opstate-reqs (Robert Wilton)
Robert Wilton presenting.
[RS] No changes to existing YANG models - that does not seem to be 
practical. There are vendor extensions anyway.
[RW]   if models are standardised in IETF, they should work in all cases.

[KW] we would like to know which of those solutions should progress 
forward.
[RS] Would be nice to poll for who has read the solutions drafts?
[KW] [Show of hands] About half the room have read the three drafts.
[KW] Who would favor solution 1. Humm. 2. Humm (most). 3. Humm
[KW] Does anyone object to solution 2? Please go to mike?
[RS]  Didn't we do that already? We seem not to going anywhere forward 
with this discussion. We did clarify wording, but that is mostly it. It 
is nothing for operator to help with configuring a network. Is it a 
perfection problem here? Can we produce something practically useful?
[CM] There are large installations based on existing YANG and NETCONF 
specifications.
[RS]    I take that into account. I have none in my network though that 
use existing model. I am not saying that we should throw away the 
existing solution in favor of the future solution.
[CM] There is a technology shift.
[CH] We are not forcing to implement some particular data store 
technology. This is more of a way of thinking of it.

[Before]

10 min: draft-openconfig-netmod-model-catalog-00   (Anees Shaikh)
Anees Shaikh presenting.
...
[KW] Maybe IETF tools could host this too.
[KW] please hum if this is important work.

[After]
10 min: draft-openconfig-netmod-model-catalog-00   (Anees Shaikh)
Anees Shaikh presenting.
...
[KW] please hum if this is important work.
[KW] [Humm]  It's important.

[Before]

5 min: draft-wilton-netmod-intf-ext-yang-01  (Robert Wilton)
Moved from morning session.Robert Wilton presenting.
[LL] I think this is really necessary to do, and that is one of the reasons why derive functionality was introduced. [IF] aift types served purposes for SNMP MIBs. I do not propose to obsolete these types. We likely need a tree of identities that could be used.
[RS] Wilton  this is more of a label of the interface type.
[MB]   This seems to be a nice idea. Defining these identities that define the properties of interface seems useful, and then derive the actual interface identities from those interface technology type identities. Maybe property identities could be a separate model.
[RS]  augmentation needs to be in the same ??
[MB]   that is a side effect of allowing mandatory augments?
[KW] who has read the draft  ~10. Who supports the interface extension being adopted?
[DR] waiting for IEEE 802.1Q WG chair - what is that?
[MJ]  Glen thinks that the extension of VLAN YANG model should be happening there.
[RS]  this is related to overlapping of the bridging model implementation?
[DR] do you have any mail exchanges for this? Maybe this could be raised in IEEE plenary. Please forward me any emails on this discussion.

[After]

5 min: draft-wilton-netmod-intf-ext-yang-01  (Robert Wilton)
Moved from morning session.Robert Wilton presenting.
[LL] I think this is really necessary to do, and that is one of the reasons why derive functionality was introduced. [IF] aift types served purposes for SNMP MIBs. I do not propose to obsolete these types. We likely need a tree of identities that could be used.
[RW] This is more of a label of the interface type.
[MB]   This seems to be a nice idea. Defining these identities that define the properties of interface seems useful, and then derive the actual interface identities from those interface technology type identities. Maybe property identities could be a separate model.
[RW]  augmentation needs to be in the same module as the identity definition.
[MB]   that is a side effect of allowing mandatory augments.
[KW] who has read the draft  ~10. Who supports the interface extension being adopted?
[KW] [Support indicated].  OK, good.  Will confirm on the WG mailing list.
[DR] waiting for IEEE 802.1Q WG chair - what is that?
[MJ]  Glen thinks that the extension of VLAN YANG model should be happening there.
[RW] Concern is overlap with the 802.1Q YANG model for bridges.  But this model doesn't overlap because it it only defines an interface based model for classification.
[DR] do you have any mail exchanges for this? Maybe this could be raised in IEEE plenary. Please forward me any emails on this discussion.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Wed, 25 Nov 2015 01:12:28 +0000

All,

I have compiled Martin and Robert’s updates into the attached file, and below is the diff.  As far as I can tell, these updates are all well and good.   Thank you Martin and Robert.

Given that it’s a holiday in the States, please send any final corrections by Monday, Nov 30th.

Kent

# diff minutes-94-netmod-new.txt minutes-94-netmod.txt
190,191c190,191
< [TC] Why did you chose to use intended/applied approach rather than using datastores?
< [RS] 1. No such thing as an applied datastore today.  This solution allows us to use YANG today. 2. Our solution allows for a single path that is not dependent on the datastore.
---
> [RS] This allows us to use YANG today.
194c194
< [AS] There is a section in our draft that addresses some of these questions.
---
> [AS] There is a section i a draft that addresses this.
203,204c203,204
< [RS] No changes to existing YANG models - that does not seem to be practical. There are vendor extensions anyway.
< [RW] if models are standardised in IETF, they should work in all cases.
---
> [RW] Wilton  if models are standardised in IETF, they should work in all cases.
206,208c206,207
< [RS] Would be nice to poll for who has read the solutions drafts?
< [KW] [Show of hands] About half the room have read the three drafts.
< [KW] Who would favor solution 1. Humm. 2. Humm (most). 3. Humm
---
> [RW] would be nice to poil for who has read the solutions drafts?
210,212c209,211
< [RS] Didn't we do that already? We seem not to going anywhere forward with this discussion. We did clarify wording, but that is mostly it. It is nothing for operator to help with configuring a network. Is it a perfection problem here? Can we produce something practically useful?
< [CM] There are large installations based on existing YANG and NETCONF specifications.
< [RS] I take that into account. I have none in my network though that use existing model. I am not saying that we should throw away the existing solution in favor of the future solution.
---
> [RW] I take that into account. I have none in my network though that use existing model. I am not saying that we should throw away the existing solution in favor of the future solution.
214c213
< [CH] We are not forcing to implement some particular data store technology. This is more of a way of thinking of it.
---
> [CH] We are not forcing to implement some particular data store technology. This is more of a way of thinking of it.
232d230
< [KW] [Humm]  It's important.
314,317c312,315
< [RS] if we want to simplify things, we need to remove choice completely.  I am not proposing that we do this.
< [MB] I agree.
< [RS] you need to track which branch gets used. It does not explicitly show in the tree. And for those who do not like they could not implement it.
< [MB] The data model designer needs to use these constructs carefully.  "choice" is often used in very small trees only.
---
> [RS] you need to track which branch gets used. It does not explicitly does not show in the tree. And for those who do not like they could not implement it.
401c399
< [RW] This is more of a label of the interface type.
---
> [RS] Wilton  this is more of a label of the interface type.
403,404c401,402
< [RW]  augmentation needs to be in the same module as the identity definition.
< [MB]   that is a side effect of allowing mandatory augments.
---
> [MB]   that is a side effect of allowing mandatory augments?
406,410c404,407
< [KW] [Support indicated].  OK, good.  Will confirm on the WG mailing list.
< [DR] waiting for IEEE 802.1Q WG chair - what is that
< [MJ]  Glen thinks that the extension of VLAN YANG model should be happening there
< [RW] Concern is overlap with the 802.1Q YANG model for bridges.  But this model doesn't overlap because it it only defines an interface based model for classification.
< [DR] do you have any mail exchanges for this? Maybe this could be raised in IEEE plenary. Please forward me any emails on this discussion.
---
> [DR] do you have any mail exchanges for this? Maybe this could be raised in IEEE plenary. Please forward me any emails on this discussion

From: Robert Wilton <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 24, 2015 at 11:59 AM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] draft netmod 94 minutes posted

Hi Kent,

I've some minor modifications of some of the minutes, mainly just to clarify who was asking some of the questions/comments (mostly between Rob Shakir and myself), but also some other minor clarifications when I was listening back to the audio.

[Before]

[After]
10 min: draft-ietf-openconfig-netmod-opstate-01    (Anees Shaikh or [RS] Shakir)
Rob Shakir presenting.
[LL] Would it be possible to have multiple management interfaces (NETCONF, RESTONF, other) - is the intended configuration supposed to be private per transport protocol?
[RS]  Would think no. There is one intended configuration per device.
[LL] this may have some locking implications.
[TC]  Why did you chose to use intended/applied approach rather than using datastores?
[RS]  1. No such thing as an applied datastore today.  This solution allows us to use YANG today. 2. Our solution allows for a single path that is not dependent on the datastore.
[KW] there were 3 solutions drafts.
[TC]    we are doing the same thing in BBF, and would like to mimic the solution agreed here.
[AS] There is a section in our draft that addresses some of these questions.
[LB]  I am confused on the process for the requirements. You said you will make consensus call for requirements today?
[KW] we will do a consensus call on solutions. I believe there is consensus on requirements.
[LB]  on a list there was a discussion on planning to poll for consensus but that did not seem to happen.
[KW] confirming consensus on requirements now by humming - consensus achieved.

[Before]

[After]
10 min: other solutions for the opstate-reqs (Robert Wilton)
Robert Wilton presenting.
[RS] No changes to existing YANG models - that does not seem to be practical. There are vendor extensions anyway.
[RW]   if models are standardised in IETF, they should work in all cases.

[KW] we would like to know which of those solutions should progress forward.
[RS] Would be nice to poll for who has read the solutions drafts?
[KW] [Show of hands] About half the room have read the three drafts.
[KW] Who would favor solution 1. Humm. 2. Humm (most). 3. Humm
[KW] Does anyone object to solution 2? Please go to mike?
[RS]  Didn't we do that already? We seem not to going anywhere forward with this discussion. We did clarify wording, but that is mostly it. It is nothing for operator to help with configuring a network. Is it a perfection problem here? Can we produce something practically useful?
[CM] There are large installations based on existing YANG and NETCONF specifications.
[RS]    I take that into account. I have none in my network though that use existing model. I am not saying that we should throw away the existing solution in favor of the future solution.
[CM] There is a technology shift.
[CH] We are not forcing to implement some particular data store technology. This is more of a way of thinking of it.

[Before]

[After]

[Before]

Moved from morning session.

[After]

Moved from morning session.

Thanks,
Rob

All,

Thanks,
Kent

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/netmod