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
On 17/11/2015 18:32, Kent Watsen wrote:
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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
