Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Martin Bjorklund <[e-mail]>]

"Rob Wilton (rwilton)" <[e-mail]> wrote:
> Hi Martin,
> 
> Please see comments inline ...
> 
> > -----Original Message-----
> > From: Martin Bjorklund <[e-mail]>
> > Sent: 22 August 2019 12:35
> > To: Rob Wilton (rwilton) <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> > 
> > Hi,
> > 
> > Some comments inline.
> > 
> > 
> > "Rob Wilton (rwilton)" <[e-mail]> wrote:
> > > Hi Vladimir,
> > >
> > > Thanks for your detailed review.  Sorry for the slow reply, I've been
> > > away.  I'm also about to be away again for a couple of days.
> > >
> > > Please see my comments inline ...
> > >
> > > I'll also track these issues to closure on
> > > https://github.com/netmod-wg/interface-extensions-yang/issues
> > >
> > > > -----Original Message-----
> > > > From: netmod <[e-mail]> On Behalf Of Vladimir
> > > > Vassilev
> > > > Sent: 13 August 2019 17:05
> > > > To: Kent Watsen <[e-mail]>; [e-mail]
> > > > Subject: Re: [netmod] WG Last Call:
> > > > draft-ietf-netmod-intf-ext-yang-07
> > > >
> > > > I have reviewed the draft. I have the following (19) IMO useful
> > > > proposals:
> > > >
> > > > 1. Dedicated module (ietf-if-oper-status-debounce.yang) for the
> > > > oper- status debouncing/dampening functionality currently in
> > > > ietf-interfaces-
> > > > common.yang.
> > >
> > > I don't think that we want a proliferation of too many separate YANG
> > > modules for small features.  Each of the areas of different
> > > functionality within this module are already conditional on
> > > if-feature, so I don't think that there is a strong justification to
> > > separating this out as a separate module.
> > 
> > I agree.
> > 
> > > > 4. Dedicated module (ietf-if-loopback.yang) for the loopback
> > > > functionality currently in ietf-interfaces-common.yang.
> > >
> > > Same answer as for 1. I don't think that we should have too many
> > > really small modules.
> > 
> > I agree.
> > 
> > 
> > > > 10. Introducing config true "forwarding-mode" leaf breaks clients
> > > > that support e.g. rfc8344 ietf-ip (which has its dedicated
> > > > forwarding leafs e.g.
> > > > /ietf-interfaces:interfaces/interface/ietf-ip:ipv4/forwarding ) by
> > > > introducing this new module with a new leaf they know nothing about.
> > > > I support this leaf as config false. If NETCONF was not
> > > > transactional a global leaf enabling the forwarding configuration
> > > > would be a feature.
> > > > But NETCONF is transactional.
> > >
> > > I don't get the relevance of transactions

Neither do I.


> > > , but it isn't intended to
> > > break existing clients/YANG modules.
> > >
> > > The idea of this leaf is that if it is configured then the system can
> > > use it to check other constraints.  E.g. to validate that an L2 QoS
> > > policy isn’t being configured on an L3 interface.  If the leaf isn't
> > > configured then those constraints are not checked.
> > 
> > Hmm.  Are you saying that this leaf doesn't have any direct effect in
> > the
> > server?
> 
> It depends on the device.  Some devices require a leaf like this (or
> similar) to correctly provision the services.  Other devices don't
> need it.

Hmm, is this really a property of the device implementation?  Isn't it
a property of the data models that describe these services?

It seems to me that the semantics of this leaf is a bit unclear,
esp. if we look at the sub-intf-vlan model which uses this leaf:

    container dot1q-vlan {
      must
        'count(../../if-cmn:forwarding-mode) = 0 or ' +
        'derived-from-or-self(../../if-cmn:forwarding-mode,' +
                              '"if-cmn:layer-3-forwarding")' 


This means that it is perfectly ok for a client to configure
"dot1q-vlan" without also setting forwarding-mode.



> > > > 19. ietf-if-common.yang and ietf-if-ethernet-like.yang instead of
> > > > ietf-
> > > > interfaces-common.yang and ietf-interfaces-ethernet-like.yang.
> > > > Setting a shorter naming precedent for future modules augmenting
> > > > ietf- interfaces.
> > >
> > > I'm not opposed to shorter names, but would be interested in the views
> > > of others in the WG.
> > 
> > I had a similar concern for the modules in the sub-intf-vlan draft (I
> > will
> > post my review of that doc later).
> > 
> > Currently we have:
> > 
> >   ietf-interfaces-common
> >   ietf-interfaces-ethernet-like
> >   ietf-if-l3-vlan
> >   ietf-flexible-encapsulation
> > 
> > I think we should have consistency, either:
> > 
> >   ietf-interfaces-common
> >   ietf-interfaces-ethernet-like
> >   ietf-interfaces-l3-vlan
> >   ietf-interfaces-flexible-encapsulation
> > 
> > or
> > 
> >   ietf-if-common
> >   ietf-if-ethernet-like
> >   ietf-if-l3-vlan
> >   ietf-if-flexible-encapsulation
> > 
> 
> I prefer the shorter names personally.

Ok.


/martin


> 
> Thanks,
> Rob
> 
> 
> > 
> > /martin
> > 
> > 
> > >
> > > Thanks again for the review.  It is appreciated.
> > >
> > > Rob
> > >
> > >
> > > >
> > > > /Vladimir
> > > >
> > > > On 10/07/2019 02.15, Kent Watsen wrote:
> > > > > All,
> > > > >
> > > > > This starts a twelve-day working group last call for
> > > > > draft-ietf-netmod-intf-ext-yang-07
> > > > >
> > > > > The working group last call ends on July 21 (the day before the
> > > > > NETMOD
> > > > 105 sessions).  Please send your comments to the working group
> > > > mailing list.
> > > > >
> > > > > Positive comments, e.g., "I've reviewed this document and believe
> > > > > it is
> > > > ready for publication", are welcome!  This is useful and important,
> > > > even from authors.
> > > > >
> > > > > Thank you,
> > > > > NETMOD Chairs
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod