   In statements that have any data definition statements as
   substatements, those data definition substatements MUST NOT be
   reordered.

'augment "/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type"'
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

'augment "/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type"'
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

'augment "/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type"'
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

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

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

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. 

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. 
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. 

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. 
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. 

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.
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. 

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. 

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

Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I have one question related to "5.1.  Module Naming Conventions".

Currently, the YANG modules that I have included as part of my
individual IDs don't currently use an "ietf-" prefix because the
drafts haven't been adopted as WG documents yet.

However, this means that the pyang tool throws up a warning for this.
E.g.
interfaces-common@2015-10-19.yang:1: warning: RFC 6087: 4.1: no module
name prefix used, suggest ietf-interfaces-common

So, am I right in not including the ietf prefix for non WG adopted
drafts?  If so, should the above warning in pyang be made
informational instead?

I think it wiuld be useful if 6087bis provided guidelines for these
kinds of modules as well.

That said, I think that pyang --ietf should still flag this as an
error.  When checking a non-WG module, use --lint instead of --ietf.
4.9.  Validation Tools

   All modules need to be validated before submission in an Internet
   Draft.  The 'pyang' YANG compiler is freely available from github:

      https://github.com/mbj4668/pyang

   If the 'pyang' compiler is used, then the "--ietf" command line
   option SHOULD be used to identify any IETF guideline issues.

/martin

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