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

[Fatai Zhang]

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.

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

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, ☺

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

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

[Mahesh Jethanandani]

> On Mar 22, 2017, at 8:21 AM, 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?
> 
Having sat on some of the meeting with Robert in IEEE, I would agree that the 
three proposals is the cleanest approach to splitting the work. It would have 
ideal that there was one model each for Ethernet interface and all the 
statistics, and one for POE, but ...
> 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

Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt

[Alex Campbell]

Hi,

In the description of /hardware-state/component, which describes the procedure 
for matching newly added hardware components with pre-configured entries in 
/hardware/component:

What happens if hardware-config is supported, and there is no entry with 
matching values for the nodes 'class', 'parent', and 'parent-rel-pos'? (i.e. 
step 1's condition is not true)
Why is mfg-name treated specially - and not, for example, serial-num?
Why is it recommended for implementations to warn about a mfg-name mismatch, 
but not a class mismatch?




From: netmod  on behalf of Martin Bjorklund 

Sent: Monday, 13 March 2017 8:46 p.m.
To: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt

Hi,

This version addresses the comments from Bart and Juergen.

I think that this document is now ready for WGLC.


/martin


internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the NETCONF Data Modeling Language of the IETF.
>
> Title   : A YANG Data Model for Hardware Management
> Authors : Andy Bierman
>   Martin Bjorklund
>   Jie Dong
>   Dan Romascanu
>   Filename: draft-ietf-netmod-entity-03.txt
>   Pages   : 40
>   Date: 2017-03-13
>
> Abstract:
>This document defines a YANG data model for the management of
>hardware on a single server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-entity-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-03
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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

Re: [netmod] uses and augment

[Juergen Schoenwaelder]

On Wed, Mar 22, 2017 at 02:26:53PM -0400, Dale R. Worley wrote:
> I've got a couple of questions about the interaction of "uses" and
> "augment".  I hope that these have straightforward answers that the old
> hands can tell me easily enough.
> 
> 1. Augmenting a grouping
> 
> 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.
> 
> For example:
> 
>  module foo {
>...
>grouping target {
>  leaf address {
>type inet:ip-address;
>description "Target IP address.";
>  }
>  leaf port {
>type inet:port-number;
> description "Target port number.";
>  }
>}
>  }
> 
>  module bar {
>...
>import foo {
>...
>}
>augment "/foo:target" {
>  leaf new-leaf {
>type string;
>  }
>}
> }
> 
>  module baz {
>...
>import foo {
>...
>}
>container main {
>  uses foo:target;
>}
> }
> 
> giving an effective schema:
> 
>container main {
>  leaf address {
>type inet:ip-address;
>description "Target IP address.";
>  }
>  leaf port {
>type inet:port-number;
> description "Target port number.";
>  }
>  leaf new-leaf {
>type string;
>  }
>}

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? In short, it is unclear where
the augmentation of the grouping applies and where not. 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.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

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 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 revised datastore draft will provide a conceptual framework 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 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.
> > > On 3/16/2017 2:24 PM, Mehmet Ersue wrote:
> > > > Lou,
> > . . .
> > > > I actually provided a very simple proposal. You guys can fill the
> > > > idea with minimal text better than me. I'm fine whatever the text
is.
> > > > If you think the high-level topic description a)-f) does already
> > > > define the WG item clearly you can simply say "this is achieved
> > > > with WG
> > > item XY".
> > > > If not, you can keep the high-level focus text but set
> > > > additionally the borders of the WG item with a few concrete words.
> > >
> > > I really can't tell for sure, but it feels to me that this comment
> > > boils down to a style comment and you have a preference for
> > > different contents in the charter.  I'd like to be sensitive to
> > > this.  As our style differs, having a concrete proposal on specific
> > > text changes would be really helpful in us (and the WG) evaluating
> > > the changes you'd like to see.  Without such specific examples and
> > > think we're left with the charter as currently proposed.  Perhaps
> > > someone else who
> > has similar feelings can chime in and provide proposed text.
> > >
> > > Anyone else have any comments or proposed changes?
> > I think the wording depends on the time period is for which the
> > charter is prepared.
> > I can try some text once I have time tomorrow.
> >
> > . . .
> > > > I think the DS draft provides a conceptual framework for diverse
> > > > DS usage scenarios to be used by many protocols, where IETF WGs
> > > > may actually decide using a subset of the DS framework for their
> > > > purpose and for their protocol standardization.
> > > > Based on this the conceptual framework cannot be standardized as
> > > > it is but the protocols using a consistent subset have to be
standardized.
> > > > Following this consideration I think the intended status of the DS
> > > > draft should be changed to: Informational RFC If you agree please
> > > > indicate this change accordingly.
> > >
> > > I think Juergen's reply to your previous message highlights that
> > > there is a difference of opinion here based on the technical
> > > specifics of the draft.  My position as chair is that I'll support
> > > whatever makes sense based on the document 

[netmod] uses and augment

[Dale R. Worley]

I've got a couple of questions about the interaction of "uses" and
"augment".  I hope that these have straightforward answers that the old
hands can tell me easily enough.

1. Augmenting a grouping

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.

For example:

 module foo {
   ...
   grouping target {
 leaf address {
   type inet:ip-address;
   description "Target IP address.";
 }
 leaf port {
   type inet:port-number;
description "Target port number.";
 }
   }
 }

 module bar {
   ...
   import foo {
 ...
   }
   augment "/foo:target" {
 leaf new-leaf {
   type string;
 }
   }
}

 module baz {
   ...
   import foo {
 ...
   }
   container main {
 uses foo:target;
   }
}

giving an effective schema:

   container main {
 leaf address {
   type inet:ip-address;
   description "Target IP address.";
 }
 leaf port {
   type inet:port-number;
description "Target port number.";
 }
 leaf new-leaf {
   type string;
 }
   }

This construct seems to be well-defined to me, other than that it's not
immediately clear what namespace baz:main/new-leaf is in.  (For some
reason, I reflexively think that it's in bar's namespace, not baz's, but
I can't state any reasoning for that.)

2.  "augment" as a substatement of "uses"

In section 7.17:

   The "augment" statement allows a module or submodule ...  to add to
   the nodes from a grouping in a "uses" statement.

When I first read this, I took it to mean that an "augment" substatement
adds a peer node to the set of nodes 'from a grouping in a "uses"
statement'.  But I suspect that it is intended to mean that an "augment"
only adds nodes *under* one of the nodes from the grouping.  There's an
ambiguity that could be fixed by better wording.

7.17 also says:

   If the "augment" statement is a substatement to the
   "uses" statement, the descendant form (defined by the rule
   "descendant-schema-nodeid" in Section 14) MUST be used.

My understanding is that "descendant-schema-nodeid" is an XPath
expression, and that the "context node" for its evaluation is the node
to which the "uses" statement adds nodes -- but that doesn't seem to be
stated anywhere.

(Those last two I should have caught in my Gen-ART review!)

Thanks for any information,

Dale

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

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

[Martin Bjorklund]

William Ivory  wrote:
> Hi Martin,
> 
> 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.


/martin


> 
> William
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com] 
> Sent: 22 March 2017 17:53
> To: William Ivory 
> Cc: netmod@ietf.org; Nick Brown 
> Subject: Re: [netmod] Interaction of 'when' and 'default' statements
> 
> William Ivory  wrote:
> > Hi,
> > 
> > I'm looking for clarification of the 'when' and 'default' statements 
> > on a leaf.  For example, if a leaf has a 'default', can it also have a 
> > 'when' statement that could cause it to disappear if the 'when'
> > condition evaluates to false?
> 
> Yes, and in that case the default doesn't apply.
> 
> > Section 8.3 or RFC 6020 isn't clear on how evaluation of constraints 
> > should be done here, and neither the section on the 'when' statement 
> > nor the 'default' section have any cross-references.
> 
> If the "when" expression evaluates to false, it's like if the whole node 
> doesn't exist.  A client can't set it etc.
> 
> 
> /martin
> 

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

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

[Bogaert, Bart (Nokia - BE/Antwerp)]

William,

The when clause determines whether the node will be instantiated or not.
Only when it is instantiated (when condition evaluates to true), the default
property comes into the picture.  At least, that is how I interpret it.

Best regards - Vriendelijke groeten,
Bart Bogaert

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of William Ivory
Sent: 22 March 2017 18:56
To: Martin Bjorklund 
Cc: Nick Brown ; netmod@ietf.org
Subject: Re: [netmod] Interaction of 'when' and 'default' statements

Hi Martin,

Thanks.  Can you point me at the part of RFC 6020 that explicitly states
that 'when' wins over 'default'?

William

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com]
Sent: 22 March 2017 17:53
To: William Ivory 
Cc: netmod@ietf.org; Nick Brown 
Subject: Re: [netmod] Interaction of 'when' and 'default' statements

William Ivory  wrote:
> Hi,
> 
> I'm looking for clarification of the 'when' and 'default' statements 
> on a leaf.  For example, if a leaf has a 'default', can it also have a 
> 'when' statement that could cause it to disappear if the 'when'
> condition evaluates to false?

Yes, and in that case the default doesn't apply.

> Section 8.3 or RFC 6020 isn't clear on how evaluation of constraints 
> should be done here, and neither the section on the 'when' statement 
> nor the 'default' section have any cross-references.

If the "when" expression evaluates to false, it's like if the whole node
doesn't exist.  A client can't set it etc.


/martin

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[William Ivory]

Hi Martin,

Thanks.  Can you point me at the part of RFC 6020 that explicitly states that 
'when' wins over 'default'?

William

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: 22 March 2017 17:53
To: William Ivory 
Cc: netmod@ietf.org; Nick Brown 
Subject: Re: [netmod] Interaction of 'when' and 'default' statements

William Ivory  wrote:
> Hi,
> 
> I'm looking for clarification of the 'when' and 'default' statements 
> on a leaf.  For example, if a leaf has a 'default', can it also have a 
> 'when' statement that could cause it to disappear if the 'when'
> condition evaluates to false?

Yes, and in that case the default doesn't apply.

> Section 8.3 or RFC 6020 isn't clear on how evaluation of constraints 
> should be done here, and neither the section on the 'when' statement 
> nor the 'default' section have any cross-references.

If the "when" expression evaluates to false, it's like if the whole node 
doesn't exist.  A client can't set it etc.


/martin

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

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

[Martin Bjorklund]

William Ivory  wrote:
> Hi,
> 
> I'm looking for clarification of the 'when' and 'default' statements
> on a leaf.  For example, if a leaf has a 'default', can it also have a
> 'when' statement that could cause it to disappear if the 'when'
> condition evaluates to false?

Yes, and in that case the default doesn't apply.

> Section 8.3 or RFC 6020 isn't clear on
> how evaluation of constraints should be done here, and neither the
> section on the 'when' statement nor the 'default' section have any
> cross-references.

If the "when" expression evaluates to false, it's like if the whole
node doesn't exist.  A client can't set it etc.


/martin

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

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

[William Ivory]

Hi,

I'm looking for clarification of the 'when' and 'default' statements on a leaf. 
 For example, if a leaf has a 'default', can it also have a 'when' statement 
that could cause it to disappear if the 'when' condition evaluates to false?  
Section 8.3 or RFC 6020 isn't clear on how evaluation of constraints should be 
done here, and neither the section on the 'when' statement nor the 'default' 
section have any cross-references.

Thanks,

William

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

Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt

[Benoit Claise]

Tim, William,

Are we good from a Broadband Forum point of view?
I remember some discussions during the last IETF meeting regarding this 
entity YANG module.


Regards, Benoit

Hi,

This version addresses the comments from Bart and Juergen.

I think that this document is now ready for WGLC.


/martin


internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

 Title   : A YANG Data Model for Hardware Management
 Authors : Andy Bierman
   Martin Bjorklund
   Jie Dong
   Dan Romascanu
Filename: draft-ietf-netmod-entity-03.txt
Pages   : 40
Date: 2017-03-13

Abstract:
This document defines a YANG data model for the management of
hardware on a single server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-entity-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] 802.3 Ethernet YANG (802.3cp) and IETF overlap

[Robert Wilton]

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



wilton_8023cf_ethernet_interface_statistics_3.pptx
Description: MS-Powerpoint 2007 presentation
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod