Re: [netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

[Kent Watsen]

Hi Benoit,

Section 4.2 of rfc6187bis says:

   The "" tag SHOULD be followed by a string 
   identifying the file name specified in Section 5.2 of 
   [RFC7950].

While Section 5.2 of RFC7950 says:

   The name of the file SHOULD be of the form:

 module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )

   "module-or-submodule-name" is the name of the module or 
   submodule, and the optional "revision-date" is the latest
   revision of the module or submodule, as defined by the
   "revision" statement (Section 7.1.9).

While the SHOULD statements provide a recommendation, the
square-brackets "[]" impart no bias, and the text is ambiguous.
That is, is the revision-date optional *only* because the 
revision statement is optional within the module?  What is 
the recommendation for when the revision statement is present?
The RFC7950 text isn't clear.

My opinion is that RFC7950 errata should state that the file 
name SHOULD include the revision-date when the revision 
statement appears within the module.

Kent // contributor


-ORIGINAL MESSAGE-

Dear all,

[Preparing the IETF hackathon]

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis#section-4.2
What is the guideline regarding:
  file "ietf-...@2016-03-20.yang"
 versus
  file "ietf-foo.yang"

Right now, we have a mix of behaviors.
This implies that the extracted YANG modules sometimes contains the 
revision, but not always.

Regards, Benoit

___
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

Re: [netmod] [CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF overlap

[Zhuangyan (Yan)]

The main point is that 802.3 defines PHY specs for Ethernet devices along with 
managed objects (which can be considered as management interface) to manage 
those phys by setting/reading registers.
Even 802.3 now agrees to add extra attributes from MIB but beyond Clause 30, 
those attributes are still needed to be supported by 802.3 hardware….

For the management of these devices, 802.3 will provide management interfaces 
according to the capability of their defined PHYs.  Previously, in form of 
MIBs, now in form of YANG modules.
But for the system level management, we think IETF is a more appropriate place 
to discuss since 802.3 is not expert in this.

For the Ethernet interface, as discussed, the system related or generic 
management are suggested to be included in Robert’s intf-ext-yang module.
For the PoE part, the power system management (including the power source and 
the poe port priority) is a system level management and would like to hear 
IETF’s thoughts on this as well.

Thank you for your comments.

Best Regards,

Yan

发件人: Robert Wilton [mailto:rwil...@cisco.com]
发送时间: 2017年3月23日 22:59
收件人: Fatai Zhang; netmod@ietf.org; cc...@ietf.org
抄送: Zhuangyan (Yan)
主题: Re: 答复: [CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF overlap

Hi Fatai,

Thanks for the comments/review.

Sorry, one correction in my email.  The 802.3 YANG project is only 802.3cf.  
Sometimes I have managed to mangle the name together with the 802.1 YANG 
project (802.1cp) ...

On 23/03/2017 03:51, Fatai Zhang wrote:
Hi Rob,

Thanks for sharing the information.

I think you are talking about two types of Yang models, one is Ethernet 
specific statistics, and the other one is Power over Ethernet.
We are trying to convert various MIBs that contain Ethernet related 
functionality to YANG.  Generally the MIBS were defined in IETF.  Some of them 
have been transferred to IEEE for ownership.

In the process of converting the content from MIBs to YANG we are taking the 
opportunity to refine the contents to better meet current requirements.  E.g. 
CSMA/CD collision counters are generally not of relevance on any current 
Ethernet hardware.



If my understanding is correct, I think your proposals are that some part of 
each of them should be defined in 802.3cp or 802.3cf, and the left part of each 
of them should be defined in IETF.
Basically, yes, that is correct.



I am a little concerned that how people can distinguish and judge which part 
(e.g., of Ethernet specific statistics or Power over Ethernet) should be 
defined in IEEE or IEFT?
A lot of the 802.3 Ethernet specification concerns functionality that is baked 
into the hardware.  The 820.3 specification defines (via Clause 30) an internal 
management API for configuration and retrieval of operational parameters from 
the hardware.

So, the 802.3cf plan is that all of the Ethernet related parts of YANG, or MIB, 
modules that just represent the values defined in clause 30 are expected to 
published as part of the 802.3 Ethernet YANG modules.

However, 802.3cf do not want their standard YANG models to map to parameters 
that are not covered by clause 30 (excepting a few more obvious omissions) 
because that might mean that the YANG module cannot be fully supported by 
current devices (e.g. if they don't have the actual hardware present to provide 
the necessary counters).

So, the proposal is that some parts of the Ethernet statistics get standardized 
in IETF instead (probably via NETMOD).

Concretely, my desire is for the following bits would be standardized in IETF:
  1) Histogram packet statistics (from RMON) (because vendors often support 
Ethernet frames up to 9k bytes, but the formal 802.3 specification only goes up 
to 2k).  To be added to draft-ietf-netmod-intf-ext-yang-04
  2) Some counters that more generally apply to Ethernet-like interfaces (e.g. 
LAG, IRB, or Pseudo-wire head-end interfaces).  This would include the number 
of packets dropped because they don't match the destination MAC address filter. 
 To be added to draft-ietf-netmod-intf-ext-yang-04.
  3) The parts of power management that relate to power supplies rather than 
Ethernet interfaces.  Yan has submitted a draft to NETMOD for this, 
draft-zhuang-netmod-yang-poe-management-01.  I've not reviewed this draft yet, 
but it may be that it should augment the entity YANG model 
(draft-ietf-netmod-entity-03).




For example, regarding Ethernet specific statistics, how people can exactly 
know which information could be better co-located in 802.3cp and which don’t  
relate to 802.3?
I think different people might have different understanding and then it will 
bring confusion to the industry.
Possibly this will be true, but once these base models are standardized, I'm 
not sure that they are likely to evolve particularly quickly.  I would think 
that if the work is being done in 802.3 then any associated YANG would be 
standardized there, similarly for IETF.



How about allow IETF define Yang models for 

Re: [netmod] tree diagrams - flags

[Dale R. Worley]

Martin Bjorklund  writes:
> Aha, ok.  This description is not a correct description of the YANG
> data tree (in which XPath expressions etc are evaluated).  There is
> not a single "list node" called "interfaces".  Look at an example of
  ^ I'm pretty sure you mean "interface" here.
> an XML instance document:
>
>   
> 
>   eth0
>   ...
> 
> 
>   eth1
>   ...
> 
>   
>
> This also reflects the data tree.

OK, yes, I'm recalling that now.  I run into mental interference because
there are at least three ways of looking at it:

- The Yang statement is named "list" -- a singular noun -- and not
something like "repeated" or "repeated container".  And compared to
ordinary programming languages, the semantics is "array-of-structures".
(The fact that Yang doesn't orthogonalize the array and the structure is
why Yang must also have a leaf-list statement.)  So the "obvious"
semantics of the name is that it's "the name" of "the list".

- The XML version doesn't have an overt representation of the array, but
does have an overt representation of each structure and uses the list
name as the label of each structure.  The XPath expressions are
evaluated within this version, so the absence of an explicit array node
is important.

- The JSON representation overtly represents both the array ([...]) and
the structures ({...}), and applies the name to the array, not the
structures.  (Which means that you can't evaluate XPath expressions
directly against the JSON representation.)

Thus you get the contrasting representations:

   list bar {
 key foo;
 leaf foo {
   type uint8;
 }
 leaf baz {
   type string;
 }
   }

   
 123
 zig
   
   
 zag
 o
   

   "bar": [
 {
   "foo": 123,
   "baz": "zig"
 },
 {
   "baz": "zag",
   "foo": 0
 }
   ]

each of which invites one to speak of the schema in somewhat different
ways.

The way you'd describe a tree diagram differs depending on which way
you're looking at the schema.

Dale

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

Re: [netmod] uses and augment

[Andy Bierman]

Hi,

I think the reason this was rejected is because you cannot control
which "uses" of the grouping should get the augmenting nodes.
They all get the nodes.  There is no way for the uses-stmt to "opt-in"
to the new changes, except manually:

   grouping foo { ... }

   grouping new-foo {
   uses foo;
   // add new nodes via augment or data-def-stmt;
   }

By forcing the "uses foo" to change to "uses new-foo",
the data model designer is explicitly accepting the new changes.

Note that import-without-revision can also cause the uses-stmt
to expand differently as the imported module changes over time.
This is a separate problem.


Andy


On Thu, Mar 23, 2017 at 5:50 PM, Dale R. Worley  wrote:

> Martin Bjorklund  writes:
> >> I notice that "augment" is not allowed to target a "grouping", despite
> >> that naively seems to be an operation that a module designer might like
> >> to do.  I expect that there is a reason why this is not allowed.
> >
> > There were lots of debate over this one when we first designed YANG.
> > The main reason for not allowing this is that it can easily have
> > unintended consequences.  Module A uses a grouping G b/c it fits the
> > purpose.  Later someone augments G with some nodes; at this point it
> > is not at all clear that the additional nodes are suitable for module
> > A.
>
> True...  But assuming that the grouping G has clean semantics, it
> corresponds to some facility in the device, which in some way or another
> appears in multiple places in the device's data model.  And a module
> that augments G adds semantics about that facility, and would only be
> implemented by a device for which the facility uniformly has that
> additional semantics.  So it would be suitable for every place where the
> grouping is used.
>
> It seems like this consideration applies to the "Yang mount" facility
> also -- if a module A augments another module B, and module B is mounted
> in several places in the full data model, then all the instances of
> module B will be augmented.
>
> > Ok.  Well, if you want to add a sibling node to the nodes in the
> > grouping it is trivial:
> >
> >   grouping foo {
> > leaf a { ... }
> >   }
> >
> >   uses foo;
> >   leaf b { ... }
> >
> > gives you:
> >
> >leaf a { ... }
> >leaf b { ... }
>
> Of course, that works.  But what I'm considering is a modification of
> the grouping which implicitly applies to all "uses" of that grouping --
> because you don't want to have duplicate declarations of the added nodes
> in every place the grouping is used.
>
> > Well, the syntax of descendant-schema-nodeid looks like an XPath path
> > expression in abbreviated form, but it is not defined in terms of
> > XPath, hence there is no text about any XPath context.  See also
> > section 6.5
>
> OK, "context node" isn't the right term, but the idea still applies --
> if the schema node identifier is descendant, the starting point for
> reckoning the descending path has to be specified.
>
> Juergen Schoenwaelder  writes:
> > On Wed, Mar 22, 2017 at 02:26:53PM -0400, Dale R. Worley wrote:
> > This is not at all clear. You only import 'foo' - so why would the
> > augment of /foo:target (which is not exactly defined either) done in
> > 'bar' apply to uses foo:target in baz?
>
> I'd say because that's what one would expect "augmenting" of a grouping
> to mean.  Again, it looks like there will be similar behavior in "Yang
> mount".
>
> > Augments are restricted to things that have a well defined name in the
> > data tree because this makes it clear what is being augmented. One
> > would have to create additional language constructs to make
> > augmentations of groupings work.
>
> It's clear that *groupings* have well-defined names, because "uses"
> statements can refer to them.  RFC 7950 section 7.13 isn't particularly
> clear about how the argument string of the statement is to be
> interpreted, but going back over 7950, I'm getting the idea that the
> names of groupings are not descendant-schema-nodeid's, that is, named
> based on where the grouping statement sits in the syntactic hierarchy,
> but are in a separate namespace which is flat regarding equality and
> inequality comparisons, but has elaborate scoping rules regarding which
> groupings are visible in which locations.
>
> OK, that clarifies why you can't apply "augment" to a grouping --
> groupings (and thus the things defined within them) don't have names
> that can be expressed by descendant-schema-nodeid's.
>
> Dale
>
> ___
> 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

Re: [netmod] uses and augment

[Dale R. Worley]

Martin Bjorklund  writes:
>> I notice that "augment" is not allowed to target a "grouping", despite
>> that naively seems to be an operation that a module designer might like
>> to do.  I expect that there is a reason why this is not allowed.
>
> There were lots of debate over this one when we first designed YANG.
> The main reason for not allowing this is that it can easily have
> unintended consequences.  Module A uses a grouping G b/c it fits the
> purpose.  Later someone augments G with some nodes; at this point it
> is not at all clear that the additional nodes are suitable for module
> A.

True...  But assuming that the grouping G has clean semantics, it
corresponds to some facility in the device, which in some way or another
appears in multiple places in the device's data model.  And a module
that augments G adds semantics about that facility, and would only be
implemented by a device for which the facility uniformly has that
additional semantics.  So it would be suitable for every place where the
grouping is used.

It seems like this consideration applies to the "Yang mount" facility
also -- if a module A augments another module B, and module B is mounted
in several places in the full data model, then all the instances of
module B will be augmented.

> Ok.  Well, if you want to add a sibling node to the nodes in the
> grouping it is trivial:
>
>   grouping foo {
> leaf a { ... }
>   }
>
>   uses foo;
>   leaf b { ... }
>
> gives you:
>
>leaf a { ... }
>leaf b { ... }

Of course, that works.  But what I'm considering is a modification of
the grouping which implicitly applies to all "uses" of that grouping --
because you don't want to have duplicate declarations of the added nodes
in every place the grouping is used.

> Well, the syntax of descendant-schema-nodeid looks like an XPath path
> expression in abbreviated form, but it is not defined in terms of
> XPath, hence there is no text about any XPath context.  See also
> section 6.5

OK, "context node" isn't the right term, but the idea still applies --
if the schema node identifier is descendant, the starting point for
reckoning the descending path has to be specified.

Juergen Schoenwaelder  writes:
> On Wed, Mar 22, 2017 at 02:26:53PM -0400, Dale R. Worley wrote:
> This is not at all clear. You only import 'foo' - so why would the
> augment of /foo:target (which is not exactly defined either) done in
> 'bar' apply to uses foo:target in baz?

I'd say because that's what one would expect "augmenting" of a grouping
to mean.  Again, it looks like there will be similar behavior in "Yang
mount".

> Augments are restricted to things that have a well defined name in the
> data tree because this makes it clear what is being augmented. One
> would have to create additional language constructs to make
> augmentations of groupings work.

It's clear that *groupings* have well-defined names, because "uses"
statements can refer to them.  RFC 7950 section 7.13 isn't particularly
clear about how the argument string of the statement is to be
interpreted, but going back over 7950, I'm getting the idea that the
names of groupings are not descendant-schema-nodeid's, that is, named
based on where the grouping statement sits in the syntactic hierarchy,
but are in a separate namespace which is flat regarding equality and
inequality comparisons, but has elaborate scoping rules regarding which
groupings are visible in which locations.

OK, that clarifies why you can't apply "augment" to a grouping --
groupings (and thus the things defined within them) don't have names
that can be expressed by descendant-schema-nodeid's.

Dale

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

Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap

[Zhuangyan (Yan)]

Hi all,

Sorry, a little behind this discussion… some conclusions from last week’s IEEE 
802.3cf meeting.

Yes, the 802.3cf project is not chartered to modify the Clause 30, but we 
discussed the possibility of having useful attributes from existing MIB but 
beyond Clause 30 for management.
The conclusion is yes, the group agreed to have those attributes in modules 
while P802.3cf (802.3.2) would add an annex to introduce those attributes and 
provide references to standards outside 802.3 as suggestions to Clause 30.

As a follow-up, the IEEE 802.3 will discuss and decide how to add those 
attributes from that annex to Clause 30.
If no features, then it can be done by submitting comments to Maintenance 
Group. If  those are new features, a new project or a existing project that can 
modify Clause 30 would be needed.
In such way, the YANG project itself would get along well with the project 
timeline.

Besides, for the 4 proposed attributes:
Row 17: In PFC frames (used in  ETHERLIKE MIB dot3HCInPFCFrames)
 Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames)
 Row 19: Total Octets received (good & bad) (used in RMON MIB etherStatsOctets)
 Row 25: Frames dropped as being too short. (combined value of two RMON MIB 
counters (etherStatsUndersizePkts + etherStatsFragments))

The Ethernet Interface module has been adopted with these attributes and 
included in D0.1  : ). But we haven’t put these attributes into the annex as 
suggested attributes to Clause 30.
You can submit comments to add them. And if more attributes are suggested, 
please feel free to propose.

Thank you very much~

Best Regards,

Yan


发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Robert Wilton
发送时间: 2017年3月24日 1:45
收件人: Dan Romascanu
抄送: cc...@ietf.org; Russ Housley; netmod@ietf.org
主题: Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap


Hi Dan,

Thanks for the advice.  Thankfully, David Law has been attending the 802.3cf 
task meetings, so he very much aware of the proposal to add new definitions to 
clause 30, and has offered to help find the best way through the 802.3 process 
to achieve the right technical goals.

Thanks,
Rob

On 23/03/2017 16:40, Dan Romascanu wrote:
Hi Robert,
Thank you for the answer.
If the current IEEE 802.3 project (cp) is not chartered to make changes in 
Clause 30 - these cannot be done, and you need a new project for this purpose. 
Take this into consideration, as this may become a dependency and a gating 
issue for the project timelines. I suggest that you discuss this with the IEEE 
802.3 chair David Law. I am also copying Russ who is now in charge with the 
IETF - IEEE relationship to make sure that he is aware about the issue.
Regards,
Dan

On Thu, Mar 23, 2017 at 5:36 PM, Robert Wilton 
> wrote:

Hi Dan,

On 23/03/2017 07:56, Dan Romascanu wrote:
Hi,
I largely agree with the proposals of the team.
I have only one comment / clarification related to the RMON objects which are 
proposed to be transferred under IEEE 802.3cp. As far as I remember there are 
some differences between the definitions in the RMON MIB for some of the 
objects and the Clause 30 definitions.
Unfortunately, yes there are differences.


What is the approach that you propose to take?
I'm trying to rationalize them all together (at least for the parts of the MIB 
that we want to carry forward into YANG).

Please see attached for a spreadsheet that shows the relationship between the 
proposed 802.3 YANG counters, the existing MIBs (IFMIB, RMON, and 
ETHERNET-LIKE), and 802.3 clause 30.  This doesn't yet cover the counters that 
I plan on adding to draft-ietf-netmod-intf-ext-yang-04 (Drop due to invalid 
destination MAC, of RMON style histogram counters).

There will also be some text added to the 802.3cf draft that should explain the 
relationship, possibly some of it may be lifted directly from 802.3.1.




Include in IEEE 802.3cp only those objects that strictly conform to Clause 30 
definitions, or modify / add definitions in Clause 30 in order to accommodate 
all the RMON statistics? If the later approach is to be taken - is IEEE 802.3cp 
chartered to make changes or add new definitions in Clause 30 of IEEE 802.3?

A bit of both - mostly the former approach, but with a few missing counters 
hopefully added to clause 30.

Specifically, I hoping that the following counters can be added to clause 30:
 Row 17: In PFC frames (used in  ETHERLIKE MIB dot3HCInPFCFrames)
 Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames)
 Row 19: Total Octets received (good & bad) (used in RMON MIB etherStatsOctets)
 Row 25: Frames dropped as being too short. (combined value of two RMON MIB 
counters (etherStatsUndersizePkts + etherStatsFragments))

I think that in principal there is some support for adding these to clause 30, 
and the appropriate folks in 802.3 will work out the easiest/best mechanism to 
achieve this.

Thanks,
Rob




Regards,
Dan

On Wed, Mar 22, 2017 at 5:21 

[netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

[Benoit Claise]

Dear all,

[Preparing the IETF hackathon]

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis#section-4.2
What is the guideline regarding:
 file "ietf-...@2016-03-20.yang"
versus
 file "ietf-foo.yang"

Right now, we have a mix of behaviors.
This implies that the extracted YANG modules sometimes contains the 
revision, but not always.


Regards, Benoit

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

Re: [netmod] Interaction of 'when' and 'default' statements

[Phil Shafer]

William Ivory writes:
>Yes, I'd noticed that.  Does this make the behaviour 'undefined' in YANG 1.0?

No, this was a clarification.  The text in 6020 was reasonably clear:

   The "when" statement makes its parent data definition statement
   conditional.  The node defined by the parent data definition
   statement is only valid when the condition specified by the "when"
   statement is satisfied.

And no default should be provided for any invalid node.  If the node
can't exist, the default can't either.

Thanks,
 Phil

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

Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap

[Robert Wilton]

Hi Dan,

Thanks for the advice.  Thankfully, David Law has been attending the 
802.3cf task meetings, so he very much aware of the proposal to add new 
definitions to clause 30, and has offered to help find the best way 
through the 802.3 process to achieve the right technical goals.


Thanks,
Rob


On 23/03/2017 16:40, Dan Romascanu wrote:

Hi Robert,

Thank you for the answer.

If the current IEEE 802.3 project (cp) is not chartered to make 
changes in Clause 30 - these cannot be done, and you need a new 
project for this purpose. Take this into consideration, as this may 
become a dependency and a gating issue for the project timelines. I 
suggest that you discuss this with the IEEE 802.3 chair David Law. I 
am also copying Russ who is now in charge with the IETF - IEEE 
relationship to make sure that he is aware about the issue.


Regards,

Dan


On Thu, Mar 23, 2017 at 5:36 PM, Robert Wilton > wrote:


Hi Dan,


On 23/03/2017 07:56, Dan Romascanu wrote:

Hi,

I largely agree with the proposals of the team.

I have only one comment / clarification related to the RMON
objects which are proposed to be transferred under IEEE 802.3cp.
As far as I remember there are some differences between the
definitions in the RMON MIB for some of the objects and the
Clause 30 definitions.

Unfortunately, yes there are differences.


What is the approach that you propose to take?

I'm trying to rationalize them all together (at least for the
parts of the MIB that we want to carry forward into YANG).

Please see attached for a spreadsheet that shows the relationship
between the proposed 802.3 YANG counters, the existing MIBs
(IFMIB, RMON, and ETHERNET-LIKE), and 802.3 clause 30.  This
doesn't yet cover the counters that I plan on adding to
draft-ietf-netmod-intf-ext-yang-04 (Drop due to invalid
destination MAC, of RMON style histogram counters).

There will also be some text added to the 802.3cf draft that
should explain the relationship, possibly some of it may be lifted
directly from 802.3.1.




Include in IEEE 802.3cp only those objects that strictly conform
to Clause 30 definitions, or modify / add definitions in Clause
30 in order to accommodate all the RMON statistics? If the later
approach is to be taken - is IEEE 802.3cp chartered to make
changes or add new definitions in Clause 30 of IEEE 802.3?


A bit of both - mostly the former approach, but with a few missing
counters hopefully added to clause 30.

Specifically, I hoping that the following counters can be added to
clause 30:
 Row 17: In PFC frames (used in  ETHERLIKE MIB dot3HCInPFCFrames)
 Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames)
 Row 19: Total Octets received (good & bad) (used in RMON MIB
etherStatsOctets)
 Row 25: Frames dropped as being too short. (combined value of two
RMON MIB counters (etherStatsUndersizePkts + etherStatsFragments))

I think that in principal there is some support for adding these
to clause 30, and the appropriate folks in 802.3 will work out the
easiest/best mechanism to achieve this.

Thanks,
Rob




Regards,

Dan


On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton > wrote:

Hi,

I'm participating in the 802.3 task force (802.3cf) to
produce standard YANG models for Ethernet interfaces and
protocols covered by the IEEE 802.3 Ethernet Working Group.

As part of my involvement with that group, I want to
highlight a couple of issues that arose in that forum that
may be of interest to various WGs in IETF.

This email, and accompanying slides, represents my personal
views, and do not represent any formal IEEE position.
However, both this email and the accompanying slides have
been reviewed in an 802.3cf task force meeting, and there
were no objections to the content, or my sending of this
email to IETF.

I also raised these issues (with an earlier set of slides) as
part of the IETF/IEEE liaison meeting on 31st January, and
the consensus was generally supportive of this approach, with
the agreed next steps to contact the NETMOD and CCAMP chairs,
which I have done, and the WGs (hence this email):


As part of that YANG modelling work, there is an aim to
define a clean boundary of what manageability data should be
specified within 802.3 and what belongs outside the 802.3
specifications.

The definition that the task force is converging on is that
everything related to Ethernet, covered by 802.3, that can be
expressed in terms of the 802.3 clause 30 manageability
definitions, should be modeled in 802.3.  I.e. broadly
everything that is 

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Hi Kent,

> We do, however, have a "YANG Next" discussion on the agenda, which may or may 
> not lead to the creation of a milestone for it.
It would be good to extend the charter proposal after this discussion with 
agreed goals for 7950bis.
We also need to know what exactly is going to be separated from 7950. E.g. one 
of the topics we discussed on the maillist was guidance on using YANG with 
specific protocols. This can be done in the protocol document.

> > > > >>>Oct 2017 - Submit draft-ietf-netmod-revised-datastores
> > > > >>> to IESG
Another question is whether this should be earlier, e.g. August.
As it is a high-priority topic needed at least by 2 WGs, we were saying that 
revised-datastores should be finalized within 4 months and NC/RC-bis will take 
another 4-5 months.

Thanks,
Mehmet

> -Original Message-
> From: Kent Watsen [mailto:kwat...@juniper.net]
> Sent: Wednesday, March 22, 2017 9:48 PM
> To: Mehmet Ersue ; 'Lou Berger' ;
> netmod@ietf.org
> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani'
> 
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Hi Mehmet,
> 
> From a charter perspective, we have:
> 
>  a) Maintaining the data modeling language YANG.  This effort
> entails periodically updating the specification to address
> new requirements as they arise.
> 
> From a milestone perspective, you are correct that we don't have a
> milestone for 7950bis as of yet.  We do, however, have a "YANG Next"
> discussion on the agenda, which may or may not lead to the creation of a
> milestone for it.
> 
> As for NETCONF/RESTCONF revisions depending on a 7950bis, if that is true,
> then it will likely force us to create the milestone in the near-term for it. 
>  That
> withstanding, I think that NETCONF WG could take the lead by
> moving/copying the NETCONF-specific parts from RFC7950 into an rfc6241bis.
> It would be nice if we could decouple the refactoring of these documents
> across our WGs.
> 
> Kent // co-chair hat
> 
> 
> 
> -ORIGINAL MESSAGE-
> Hi Kent, Lou,
> 
> as I see 7950bis has not been mentioned in the charter text and the
> milestones.
> As you know NETCONF and RESTCONF revisions are dependent on the timing
> of 7950bis.
> How is this essential deliverable and its timing going to be addressed in the
> charter?
> 
> Mehmet
> 
> > -Original Message-
> > From: Mehmet Ersue
> > Sent: Friday, March 17, 2017 11:51 PM
> > To: Lou Berger ; 'Kent Watsen'
> > ; netmod@ietf.org
> > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani'
> > 
> > Subject: RE: [netmod] draft netmod charter update proposal
> >
> > Hi Lou, Kent,
> >
> > I promised to provide some minimal text which can be used as WG item
> > description.
> > I'm fine with any fine tuning.
> >
> > See below:
> >
> >a) Maintaining the data modeling language YANG.  This effort entails
> >   periodically updating the specification to address new requirements
> >   as they arise. ADD > revision
> of RFC
> > 7950./>
> >
> >b) Maintaining the guidelines for developing YANG models.  This effort
> >   is primarily driven by updates made to the YANG specification.
> ADD > continuous effort has been recently addressed with a revision of RFC
> 6087./>
> >
> >c) Maintaining a conceptual framework in which YANG models are used.
> >   This effort entails describing the generic context that in YANG
> >   exists and how certain YANG statements interact in that context.
> >   An example of this is YANG's relationship with datastores.
> > ADD > for the
> handling
> > of datastores, which can be adopted by other WGs for their usage
> > scenario./>
> >
> > . . .
> >
> >e) Maintaining YANG models used as basic YANG building blocks.  This
> >   effort entails updating existing YANG models (ietf-yang-types and
> >   ietf-inet-types) as needed, as well as defining additional core YANG
> >   data models when necessary. ADD > work on the models for Syslog, ACL and Common Interface Extensions as
> > well as the model for hardware management. The Schema mount draft will
> > provide a mechanism to combine YANG modules into the schema defined
> in
> > other YANG modules./>
> >
> > BTW: There is no topic description (in a)-f) covering YANG module
> > classification.
> > I assume it can be added with a sentence to a) or b).
> >
> > Thanks,
> > Mehmet
> >
> > > -Original Message-
> > > From: Mehmet Ersue
> > > Sent: Thursday, March 16, 2017 11:59 PM
> > > To: Lou Berger ; 'Kent Watsen'
> > > ; netmod@ietf.org
> > > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani'
> > > 
> > > Subject: RE: [netmod] draft netmod charter update proposal
> > >
> > > > From: Lou Berger [mailto:lber...@labn.net] Mehmet,
> > > >see below.
> > > > 

Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap

[Dan Romascanu]

Hi Robert,

Thank you for the answer.

If the current IEEE 802.3 project (cp) is not chartered to make changes in
Clause 30 - these cannot be done, and you need a new project for this
purpose. Take this into consideration, as this may become a dependency and
a gating issue for the project timelines. I suggest that you discuss this
with the IEEE 802.3 chair David Law. I am also copying Russ who is now in
charge with the IETF - IEEE relationship to make sure that he is aware
about the issue.

Regards,

Dan


On Thu, Mar 23, 2017 at 5:36 PM, Robert Wilton  wrote:

> Hi Dan,
>
> On 23/03/2017 07:56, Dan Romascanu wrote:
>
> Hi,
>
> I largely agree with the proposals of the team.
>
> I have only one comment / clarification related to the RMON objects which
> are proposed to be transferred under IEEE 802.3cp. As far as I remember
> there are some differences between the definitions in the RMON MIB for some
> of the objects and the Clause 30 definitions.
>
> Unfortunately, yes there are differences.
>
> What is the approach that you propose to take?
>
> I'm trying to rationalize them all together (at least for the parts of the
> MIB that we want to carry forward into YANG).
>
> Please see attached for a spreadsheet that shows the relationship between
> the proposed 802.3 YANG counters, the existing MIBs (IFMIB, RMON, and
> ETHERNET-LIKE), and 802.3 clause 30.  This doesn't yet cover the counters
> that I plan on adding to draft-ietf-netmod-intf-ext-yang-04 (Drop due to
> invalid destination MAC, of RMON style histogram counters).
>
> There will also be some text added to the 802.3cf draft that should
> explain the relationship, possibly some of it may be lifted directly from
> 802.3.1.
>
>
>
> Include in IEEE 802.3cp only those objects that strictly conform to Clause
> 30 definitions, or modify / add definitions in Clause 30 in order to
> accommodate all the RMON statistics? If the later approach is to be taken -
> is IEEE 802.3cp chartered to make changes or add new definitions in Clause
> 30 of IEEE 802.3?
>
>
> A bit of both - mostly the former approach, but with a few missing
> counters hopefully added to clause 30.
>
> Specifically, I hoping that the following counters can be added to clause
> 30:
>  Row 17: In PFC frames (used in  ETHERLIKE MIB dot3HCInPFCFrames)
>  Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames)
>  Row 19: Total Octets received (good & bad) (used in RMON MIB
> etherStatsOctets)
>  Row 25: Frames dropped as being too short. (combined value of two RMON
> MIB counters (etherStatsUndersizePkts + etherStatsFragments))
>
> I think that in principal there is some support for adding these to clause
> 30, and the appropriate folks in 802.3 will work out the easiest/best
> mechanism to achieve this.
>
> Thanks,
> Rob
>
>
>
> Regards,
>
> Dan
>
>
> On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton  wrote:
>
>> Hi,
>>
>> I'm participating in the 802.3 task force (802.3cf) to produce standard
>> YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3
>> Ethernet Working Group.
>>
>> As part of my involvement with that group, I want to highlight a couple
>> of issues that arose in that forum that may be of interest to various WGs
>> in IETF.
>>
>> This email, and accompanying slides, represents my personal views, and do
>> not represent any formal IEEE position.  However, both this email and the
>> accompanying slides have been reviewed in an 802.3cf task force meeting,
>> and there were no objections to the content, or my sending of this email to
>> IETF.
>>
>> I also raised these issues (with an earlier set of slides) as part of the
>> IETF/IEEE liaison meeting on 31st January, and the consensus was generally
>> supportive of this approach, with the agreed next steps to contact the
>> NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email):
>>
>>
>> As part of that YANG modelling work, there is an aim to define a clean
>> boundary of what manageability data should be specified within 802.3 and
>> what belongs outside the 802.3 specifications.
>>
>> The definition that the task force is converging on is that everything
>> related to Ethernet, covered by 802.3, that can be expressed in terms of
>> the 802.3 clause 30 manageability definitions, should be modeled in 802.3.
>> I.e. broadly everything that is covered by 802.3.1 today.  But any
>> manageability information that cannot be related to clause 30 definitions
>> should be specified outside of 802.3.  Note, where appropriate, additional
>> clause 30 definitions may be added to fix any mistakes or glaring gaps.
>>
>>
>> To this end, there are a couple of areas between IETF and 802.3 that
>> don't necessarily look like they are entirely in the right place, in
>> particular:
>>
>> 1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related
>> content) some Ethernet specific statistics that would be better co-located
>> with the Ethernet interface 

Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap

[Robert Wilton]

Hi Dan,


On 23/03/2017 07:56, Dan Romascanu wrote:

Hi,

I largely agree with the proposals of the team.

I have only one comment / clarification related to the RMON objects 
which are proposed to be transferred under IEEE 802.3cp. As far as I 
remember there are some differences between the definitions in the 
RMON MIB for some of the objects and the Clause 30 definitions.

Unfortunately, yes there are differences.


What is the approach that you propose to take?
I'm trying to rationalize them all together (at least for the parts of 
the MIB that we want to carry forward into YANG).


Please see attached for a spreadsheet that shows the relationship 
between the proposed 802.3 YANG counters, the existing MIBs (IFMIB, 
RMON, and ETHERNET-LIKE), and 802.3 clause 30.  This doesn't yet cover 
the counters that I plan on adding to draft-ietf-netmod-intf-ext-yang-04 
(Drop due to invalid destination MAC, of RMON style histogram counters).


There will also be some text added to the 802.3cf draft that should 
explain the relationship, possibly some of it may be lifted directly 
from 802.3.1.




Include in IEEE 802.3cp only those objects that strictly conform to 
Clause 30 definitions, or modify / add definitions in Clause 30 in 
order to accommodate all the RMON statistics? If the later approach is 
to be taken - is IEEE 802.3cp chartered to make changes or add new 
definitions in Clause 30 of IEEE 802.3?


A bit of both - mostly the former approach, but with a few missing 
counters hopefully added to clause 30.


Specifically, I hoping that the following counters can be added to 
clause 30:

 Row 17: In PFC frames (used in  ETHERLIKE MIB dot3HCInPFCFrames)
 Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames)
 Row 19: Total Octets received (good & bad) (used in RMON MIB 
etherStatsOctets)
 Row 25: Frames dropped as being too short. (combined value of two RMON 
MIB counters (etherStatsUndersizePkts + etherStatsFragments))


I think that in principal there is some support for adding these to 
clause 30, and the appropriate folks in 802.3 will work out the 
easiest/best mechanism to achieve this.


Thanks,
Rob




Regards,

Dan


On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton > wrote:


Hi,

I'm participating in the 802.3 task force (802.3cf) to produce
standard YANG models for Ethernet interfaces and protocols covered
by the IEEE 802.3 Ethernet Working Group.

As part of my involvement with that group, I want to highlight a
couple of issues that arose in that forum that may be of interest
to various WGs in IETF.

This email, and accompanying slides, represents my personal views,
and do not represent any formal IEEE position.  However, both this
email and the accompanying slides have been reviewed in an 802.3cf
task force meeting, and there were no objections to the content,
or my sending of this email to IETF.

I also raised these issues (with an earlier set of slides) as part
of the IETF/IEEE liaison meeting on 31st January, and the
consensus was generally supportive of this approach, with the
agreed next steps to contact the NETMOD and CCAMP chairs, which I
have done, and the WGs (hence this email):


As part of that YANG modelling work, there is an aim to define a
clean boundary of what manageability data should be specified
within 802.3 and what belongs outside the 802.3 specifications.

The definition that the task force is converging on is that
everything related to Ethernet, covered by 802.3, that can be
expressed in terms of the 802.3 clause 30 manageability
definitions, should be modeled in 802.3. I.e. broadly everything
that is covered by 802.3.1 today.  But any manageability
information that cannot be related to clause 30 definitions should
be specified outside of 802.3.  Note, where appropriate,
additional clause 30 definitions may be added to fix any mistakes
or glaring gaps.


To this end, there are a couple of areas between IETF and 802.3
that don't necessarily look like they are entirely in the right
place, in particular:

1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet
related content) some Ethernet specific statistics that would be
better co-located with the Ethernet interface YANG model being
defined in 802.3cp. Hence, the proposal is to subsume the
appropriate Ethernet statistics from the RMON MIB into a single
combined reference set defined in 802.3cp.

2) The RMON MIB also defines some Ethernet specific statistics
that can't be defined as part of 802.3cf because they don't relate
to 802.3 clause 30 registers, but are still widely supported by
vendors, and should be modeled in YANG.  The proposal is that
definitions related to these counters could be added as part of
the Ethernet-like module draft-ietf-netmod-intf-ext-yang-03

Re: [netmod] 答复: [CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF overlap

[Robert Wilton]

Hi Fatai,

Thanks for the comments/review.

Sorry, one correction in my email.  The 802.3 YANG project is only 
802.3cf.  Sometimes I have managed to mangle the name together with the 
802.1 YANG project (802.1cp) ...



On 23/03/2017 03:51, Fatai Zhang wrote:


Hi Rob,

Thanks for sharing the information.

I think you are talking about two types of Yang models, one is 
Ethernet specific statistics, and the other one is Power over Ethernet.


We are trying to convert various MIBs that contain Ethernet related 
functionality to YANG.  Generally the MIBS were defined in IETF. Some of 
them have been transferred to IEEE for ownership.


In the process of converting the content from MIBs to YANG we are taking 
the opportunity to refine the contents to better meet current 
requirements.  E.g. CSMA/CD collision counters are generally not of 
relevance on any current Ethernet hardware.


If my understanding is correct, I think your proposals are that some 
part of each of them should be defined in 802.3cp or 802.3cf, and the 
left part of each of them should be defined in IETF.



Basically, yes, that is correct.


I am a little concerned that how people can distinguish and judge 
which part (e.g., of Ethernet specific statistics or Power over 
Ethernet) should be defined in IEEE or IEFT?


A lot of the 802.3 Ethernet specification concerns functionality that is 
baked into the hardware.  The 820.3 specification defines (via Clause 
30) an internal management API for configuration and retrieval of 
operational parameters from the hardware.


So, the 802.3cf plan is that all of the Ethernet related parts of YANG, 
or MIB, modules that just represent the values defined in clause 30 are 
expected to published as part of the 802.3 Ethernet YANG modules.


However, 802.3cf do not want their standard YANG models to map to 
parameters that are not covered by clause 30 (excepting a few more 
obvious omissions) because that might mean that the YANG module cannot 
be fully supported by current devices (e.g. if they don't have the 
actual hardware present to provide the necessary counters).


So, the proposal is that some parts of the Ethernet statistics get 
standardized in IETF instead (probably via NETMOD).


Concretely, my desire is for the following bits would be standardized in 
IETF:
  1) Histogram packet statistics (from RMON) (because vendors often 
support Ethernet frames up to 9k bytes, but the formal 802.3 
specification only goes up to 2k).  To be added to 
draft-ietf-netmod-intf-ext-yang-04
  2) Some counters that more generally apply to Ethernet-like 
interfaces (e.g. LAG, IRB, or Pseudo-wire head-end interfaces). This 
would include the number of packets dropped because they don't match the 
destination MAC address filter.  To be added to 
draft-ietf-netmod-intf-ext-yang-04.
  3) The parts of power management that relate to power supplies rather 
than Ethernet interfaces.  Yan has submitted a draft to NETMOD for this, 
draft-zhuang-netmod-yang-poe-management-01.  I've not reviewed this 
draft yet, but it may be that it should augment the entity YANG model 
(draft-ietf-netmod-entity-03).




For example, regarding Ethernet specific statistics, how people can 
exactly know which information could be better co-located in 802.3cp 
and which don’t  relate to 802.3?


I think different people might have different understanding and then 
it will bring confusion to the industry.


Possibly this will be true, but once these base models are standardized, 
I'm not sure that they are likely to evolve particularly quickly.  I 
would think that if the work is being done in 802.3 then any associated 
YANG would be standardized there, similarly for IETF.


How about allow IETF define Yang models for everything of Ethernet 
specific statistics since RMON MIB was already defined by IETF and 
IEEE define Yang models for everything of Power over Ethernet (since 
ownership already transferred to 802.3)?  I personally think this 
simple approach could make our life easier, J


I think that this approach may hit some of the issues above 
(particularly the relationship to hardware and clause 30 registers).


Thanks,
Rob



Just some loud thinking…

Thanks

Fatai

*发件人:*CCAMP [mailto:ccamp-boun...@ietf.org] *代表 *Robert Wilton
*发送时间:*2017年3月22日23:21
*收件人:*netmod@ietf.org; cc...@ietf.org
*主题:*[CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF overlap

Hi,

I'm participating in the 802.3 task force (802.3cf) to produce 
standard YANG models for Ethernet interfaces and protocols covered by 
the IEEE 802.3 Ethernet Working Group.


As part of my involvement with that group, I want to highlight a 
couple of issues that arose in that forum that may be of interest to 
various WGs in IETF.


This email, and accompanying slides, represents my personal views, and 
do not represent any formal IEEE position.  However, both this email 
and the accompanying slides have been reviewed in an 802.3cf task 
force meeting, and there were no objections to 

Re: [netmod] Interaction of 'when' and 'default' statements

[Dale R. Worley]

Martin Bjorklund  writes:
> William Ivory  wrote:
>> Thanks.  Can you point me at the part of RFC 6020 that explicitly
>> states that 'when' wins over 'default'?
>
> Section 7.6.1 of RFC 7950 says:
>
>Note that if the leaf or any of its ancestors has a "when" condition
>or "if-feature" expression that evaluates to "false", then the
>default value is not in use.

Or perhaps more to the point, beware that RFC 6020 does *not* have that
paragraph.

Dale

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

Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap

[Dan Romascanu]

Hi,

I largely agree with the proposals of the team.

I have only one comment / clarification related to the RMON objects which
are proposed to be transferred under IEEE 802.3cp. As far as I remember
there are some differences between the definitions in the RMON MIB for some
of the objects and the Clause 30 definitions. What is the approach that you
propose to take? Include in IEEE 802.3cp only those objects that strictly
conform to Clause 30 definitions, or modify / add definitions in Clause 30
in order to accommodate all the RMON statistics? If the later approach is
to be taken - is IEEE 802.3cp chartered to make changes or add new
definitions in Clause 30 of IEEE 802.3?

Regards,

Dan


On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton  wrote:

> Hi,
>
> I'm participating in the 802.3 task force (802.3cf) to produce standard
> YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3
> Ethernet Working Group.
>
> As part of my involvement with that group, I want to highlight a couple of
> issues that arose in that forum that may be of interest to various WGs in
> IETF.
>
> This email, and accompanying slides, represents my personal views, and do
> not represent any formal IEEE position.  However, both this email and the
> accompanying slides have been reviewed in an 802.3cf task force meeting,
> and there were no objections to the content, or my sending of this email to
> IETF.
>
> I also raised these issues (with an earlier set of slides) as part of the
> IETF/IEEE liaison meeting on 31st January, and the consensus was generally
> supportive of this approach, with the agreed next steps to contact the
> NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email):
>
>
> As part of that YANG modelling work, there is an aim to define a clean
> boundary of what manageability data should be specified within 802.3 and
> what belongs outside the 802.3 specifications.
>
> The definition that the task force is converging on is that everything
> related to Ethernet, covered by 802.3, that can be expressed in terms of
> the 802.3 clause 30 manageability definitions, should be modeled in 802.3.
> I.e. broadly everything that is covered by 802.3.1 today.  But any
> manageability information that cannot be related to clause 30 definitions
> should be specified outside of 802.3.  Note, where appropriate, additional
> clause 30 definitions may be added to fix any mistakes or glaring gaps.
>
>
> To this end, there are a couple of areas between IETF and 802.3 that don't
> necessarily look like they are entirely in the right place, in particular:
>
> 1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related
> content) some Ethernet specific statistics that would be better co-located
> with the Ethernet interface YANG model being defined in 802.3cp.  Hence,
> the proposal is to subsume the appropriate Ethernet statistics from the
> RMON MIB into a single combined reference set defined in 802.3cp.
>
> 2) The RMON MIB also defines some Ethernet specific statistics that can't
> be defined as part of 802.3cf because they don't relate to 802.3 clause 30
> registers, but are still widely supported by vendors, and should be modeled
> in YANG.  The proposal is that definitions related to these counters could
> be added as part of the Ethernet-like module draft-ietf-netmod-intf-ext-
> yang-03
> , or
> perhaps a related Ethernet module in the same draft.
>
> 3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from
> RFC 7460), was originally specified in IETF, but ownership later
> transferred to 802.3 (via RFC 7448).  Whilst working on the Power over
> Ethernet YANG model it has become clear that not all of the attributes
> defined in the MIB map to the underlying 802.3 clause 30 definitions.
> Further, it looks like parts of this YANG model would be better defined as
> extensions to the Entity YANG model being defined in NETMOD.  The proposal
> is that the parts of the Power over Ethernet YANG model that can be
> directly related to clause 30 definitions (e.g. *pethPsePortTable*)
> should be defined in 802.3cf, but that the remaining parts (e.g., 
> *pethMainPseObjects
> *) can hopefully be standardized in IETF.
>
>
> Do you have any comments, or concerns, on the 3 proposals above?
>
> Regards,
> Rob Wilton
>
> ___
> 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