Re: [netmod] modelling of packet-action WG Last Call for draft-ietf-netmod-acl-model-11
Pardon my ignorance as this might have been asked before but why is the actions/packet-handling modelled as a choice? It would seem an identity would be better or perhaps even an enum? kll On Fri, Jul 07, 2017 at 06:34:28PM +, Kent Watsen wrote: > > > This is a notice to start a three week NETMOD WG last call for the > document: > > Network Access Control List (ACL) YANG Data Model > https://tools.ietf.org/html/draft-ietf-netmod-acl-model-11 > > Note: Three weeks is more than needed, especially given this > draft has been through Last Call before, but we understand > folks are busy these days. > > Please indicate your support or concerns by Friday, July 28, 2017. > > We are particularly interested in statements of the form: > * I have reviewed this draft and found no issues. > * I have reviewed this draft and found the following issues: ... > > As well as: > * I have implemented the data model in this draft. > * I am implementing the data model in this draft. > * I am considering to implement the data model in this draft. > * I am not considering to implement the data model in this draft. > > Thank you, > NETMOD WG Chairs > > > > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Kristian LarssonKLL-RIPE +46 704 264511k...@spritelink.net ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-16.txt
Tom, I am working with Mahesh to fix the Normative References. Regarding line length: I am using pyang 1.7.3 which is not complaining about line length in the model. But when I look at the draft I see that both the tree and the model exceed 80 characters. I will make a pass to shorten lines. Thanks, Clyde On 8/17/17, 4:54 AM, "t.petch" wrote: Clyde I like the introduction of and ; but I still hanker after Normative References to I-Ds, draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. I think that they are required. Also, in -15 and in -16, the line length seems to have gone wrong and is now too long; I notice it in the Description clauses. It was ok in -13. " Each line must be limited to 72 characters followed by the character sequence that denotes an end-of-line (EOL). This limit includes any left-side indentation. " Tom Petch Original Message - From: To: Cc: Sent: Saturday, August 12, 2017 3:17 AM > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Modeling WG of the IETF. > > Title : A YANG Data Model for Syslog Configuration > Authors : Clyde Wildes > Kiran Koushik > Filename: draft-ietf-netmod-syslog-model-16.txt > Pages : 30 > Date: 2017-08-11 > > Abstract: >This document defines a YANG data model for the configuration of a >syslog process. It is intended this model be used by vendors who >implement syslog in their systems. > > Editorial Note (To be removed by RFC Editor) > >This draft contains many placeholder values that need to be replaced >with finalized values at the time of publication. This note >summarizes all of the substitutions that are needed. No other RFC >Editor instructions are specified elsewhere in this document. > >Artwork in this document contains shorthand references to drafts in >progress. Please apply the following replacements: > >o "" --> the assigned RFC value for draft-ietf-netconf-keystore > >o "" --> the assigned RFC value for draft-ietf-netconf-tls- > client-server > >o "" --> the assigned RFC value for this draft > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-16 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-16 > > > 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
Re: [netmod] What is the best way to HW identities
Hi Martin,
Using this feedback, there is a basis to continue the work in BBF
What is the best way to continue with the sub-classes w.r.t. IANA, who needs
to initiate this? Your reply seems to suggest that irrespective of this
email, still something was required? Anyhow, BBF can define sub-identities
to continue and align later when there would be standardized HW
sub-identities.
Best regards, Bart
-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com]
Sent: Thursday, August 17, 2017 1:02 PM
To: Bogaert, Bart (Nokia - BE/Antwerp)
Cc: netmod@ietf.org; joey.b...@adtran.com; Pauwels, Ludwig (Nokia -
BE/Antwerp)
Subject: Re: [netmod] What is the best way to HW identities
Hi,
"Bogaert, Bart (Nokia - BE/Antwerp)" wrote:
> Hello,
>
>
>
> Within BBF we have had a discussion on the use of
> draft-ietf-netmod-entity-03, and we would appreciate to hear the
> opinion of IETF. More specific the discussion is on the use of the
> leaf 'class' and the leaf 'parent-rel-pos'.
>
>
>
> First some BBF context:
>
> - the systems for which BBF specifies YANG models can be built with
> various 'types of hardware', e.g. as pluggable item (module) it can
> contain boards and it can contain SFP/XFPs. As 'type of port' it can
> have connectors to terminate fastdsl links (supported over copper
> wires), and it can have positions to insert optical fibers (e.g. the
> position in the SFP in which one can plug the optical fiber).
>
>
>
> - in the data model we have the need for some conditional data: e.g.
> an SFP/XFP has some data that is defined in SFF-8472. This data is not
> applicable to boards. Hence we need to distinguish between these 2
> types of pluggable items. A 2nd example: for the optical fibers
> terminated by an SFP/XFP, we have specific data that is also defined
> in SFF-8472, e.g. the wavelength. This data is not applicable to
> fastdsl ports. On fastdsl ports we have specific data that relates to
> remote power feeding. Obviously there is no power feeding over the
> optical fiber. There might be other ports with (for now) no specific
> data, e.g. an rj45. Conclusion: need data conditional to the port type.
>
>
>
> In draft-ietf-netmod-entity-03 we read
>
> - "The "class" leaf is a YANG identity that describes the type of the
> hardware. Vendors are encouraged to either directly use one of the
> common IANA-defined identities, or derive a more specific identity
> from one of them.
>
>
>
> - As description for 'parent-rel-pos': "An indication of the relative
> position of this child component among all its sibling components.
> Sibling components are defined as components that share the same
> instance values of each of the 'parent' and 'class' nodes.
>
>
>
> Based on what we read in the first bullet a thought was to specialize
> the various hardware-class identities. Examples:
>
>
>
> identity board {
>
> base ianahw:module;
>
> description
>
> "A board is a special type of module that represents a physical
> item, commonly known as a board or a card.";
>
> }
>
>
>
> identity transceiver {
>
> base ianahw:module;
>
> description
>
> "A transceiver is a special type of module that represents a
> physical item like a pluggable SFP, an SFP+, or an XFP; or a soldered
> SFF.";
>
> }
>
>
>
> identity transceiver-link {
>
> base ianahw:port;
>
> description
>
> "A transceiver-link is a special type of port that terminates an
> optical fiber.";
>
> }
>
>
>
> identity rj45 {
>
> base ianahw:port;
>
> description
>
> "A RJ45 is a special type of port that terminates an electrical
> Ethernet link.";
>
> }
>
> identity fastdsl {
>
> base ianahw:port;
>
> description
>
> "A fastdsl is a special type of port that terminates a copper
> wire supporting a FAST or one of the DSL types link.";
>
> }
>
>
>
> The intention with this approach: the 'class' leaf is used to
> distinguish between all types of hardware. If hardware specific data
> is augmented to the hardware model, then it is using a 'when'
> condition referring to the value of the leaf 'class'.
>
>
>
> Based on the description of the parent-rel-pos it is understood that
> the value of this leaf is relative to the value of the class, so
> numbering of e.g. the various types of port supported by one board is
> independent of each other.
>
>
>
> Then the worry starts:
>
> - some of the BBF members understand this concept of specializing the
> hardware identities and use these values for the leaf class as the way
> to go, and take the impact on the numbering as a given.
>
>
>
> - Others think this impact on the parent-rel-pos is not the intention
> and assume a flat numbering of all childs within a parent
Good point. In the original model (i.e. the MIB), with fixed values for the
class, having separate numbering schemes for separate classes ma
Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-11
On Mon, Jul 17, 2017 at 05:11:48PM +0200, Juergen Schoenwaelder wrote: > On Mon, Jul 17, 2017 at 04:18:47PM +0200, Lou Berger wrote: > > All, > > > > Per our discussion in today's session, another version of this draft > > is needed to address open issues. As this revision will include > > technical changes, another LC will be needed after that version is > > published. > > > > Please do comment on this version, but be aware this version will *not* > > be submitted for publication. > > > > I planned to review this I-D but I will now wait for the next > version. ;-) However, a few things I already noted: > > - The identifiers are long, I think this was discussed before. I > suggest to replace 'source' with 'src' and 'destination' with > 'dst'; this will likely also make the tree diagram fit the > traditional RFC format again. > > I am not sure about the idea to spell out all the mixed-x-y-z > combinations. This may turn out costly to maintain long term. > > The naming is also inconsistent I think. My understanding is that > mixed-l2-l3-ipv4-acl really means mixed-eth-ipv4-acl. In fact, > ipv4-acl is actually l3 and possibly l4 since the grouping > acl-ip-header-fields uses acl-transport-header-fields. You can skip > the l4 portions since they are in a presence container. Note that this > is different from how you deal with l2 and l3 combinations. +1, this bothered me too when reading the model. IPv4 and IPv6 is explicitly named while L2 just implies Ethernet. Should have eth-ipv4-acl in the name, or eth-ipv6-acl.. or if we support matches for other L2 technology then include that in the name. While Ethernet is popular we do still have other L2 technologies. > I guess I > would generally prefer a solution that is more orthogonal > wrt. layering and likely not causing maintenance headaches in 5-10 > years from now. I don't immediately see a better way of doing it. It is rather tricky. > That said, I am not planning to implement this YANG module myself so > as long as multiple implementors think this is all good, it might be > sufficient to simply fix terminology and naming to be clear, concise > and consistent. I'm trying to implement it, as a user :) kll -- Kristian LarssonKLL-RIPE +46 704 264511k...@spritelink.net ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-16.txt
Clyde I like the introduction of and ; but I still hanker after Normative References to I-Ds, draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. I think that they are required. Also, in -15 and in -16, the line length seems to have gone wrong and is now too long; I notice it in the Description clauses. It was ok in -13. " Each line must be limited to 72 characters followed by the character sequence that denotes an end-of-line (EOL). This limit includes any left-side indentation. " Tom Petch Original Message - From: To: Cc: Sent: Saturday, August 12, 2017 3:17 AM > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Modeling WG of the IETF. > > Title : A YANG Data Model for Syslog Configuration > Authors : Clyde Wildes > Kiran Koushik > Filename: draft-ietf-netmod-syslog-model-16.txt > Pages : 30 > Date: 2017-08-11 > > Abstract: >This document defines a YANG data model for the configuration of a >syslog process. It is intended this model be used by vendors who >implement syslog in their systems. > > Editorial Note (To be removed by RFC Editor) > >This draft contains many placeholder values that need to be replaced >with finalized values at the time of publication. This note >summarizes all of the substitutions that are needed. No other RFC >Editor instructions are specified elsewhere in this document. > >Artwork in this document contains shorthand references to drafts in >progress. Please apply the following replacements: > >o "" --> the assigned RFC value for draft-ietf-netconf-keystore > >o "" --> the assigned RFC value for draft-ietf-netconf-tls- > client-server > >o "" --> the assigned RFC value for this draft > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-16 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-16 > > > 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
Re: [netmod] What is the best way to HW identities
Hi,
"Bogaert, Bart (Nokia - BE/Antwerp)" wrote:
> Hello,
>
>
>
> Within BBF we have had a discussion on the use of
> draft-ietf-netmod-entity-03, and we would appreciate to hear the opinion of
> IETF. More specific the discussion is on the use of the leaf 'class' and the
> leaf 'parent-rel-pos'.
>
>
>
> First some BBF context:
>
> - the systems for which BBF specifies YANG models can be built with various
> 'types of hardware', e.g. as pluggable item (module) it can contain boards
> and it can contain SFP/XFPs. As 'type of port' it can have connectors to
> terminate fastdsl links (supported over copper wires), and it can have
> positions to insert optical fibers (e.g. the position in the SFP in which
> one can plug the optical fiber).
>
>
>
> - in the data model we have the need for some conditional data: e.g. an
> SFP/XFP has some data that is defined in SFF-8472. This data is not
> applicable to boards. Hence we need to distinguish between these 2 types of
> pluggable items. A 2nd example: for the optical fibers terminated by an
> SFP/XFP, we have specific data that is also defined in SFF-8472, e.g. the
> wavelength. This data is not applicable to fastdsl ports. On fastdsl ports
> we have specific data that relates to remote power feeding. Obviously there
> is no power feeding over the optical fiber. There might be other ports with
> (for now) no specific data, e.g. an rj45. Conclusion: need data conditional
> to the port type.
>
>
>
> In draft-ietf-netmod-entity-03 we read
>
> - "The "class" leaf is a YANG identity that describes the type of the
> hardware. Vendors are encouraged to either directly use one of the common
> IANA-defined identities, or derive a more specific identity from one of
> them.
>
>
>
> - As description for 'parent-rel-pos': "An indication of the relative
> position of this child component among all its sibling components. Sibling
> components are defined as components that share the same instance values of
> each of the 'parent' and 'class' nodes.
>
>
>
> Based on what we read in the first bullet a thought was to specialize the
> various hardware-class identities. Examples:
>
>
>
> identity board {
>
> base ianahw:module;
>
> description
>
> "A board is a special type of module that represents a physical item,
> commonly known as a board or a card.";
>
> }
>
>
>
> identity transceiver {
>
> base ianahw:module;
>
> description
>
> "A transceiver is a special type of module that represents a physical
> item like a pluggable SFP, an SFP+, or an XFP; or a soldered SFF.";
>
> }
>
>
>
> identity transceiver-link {
>
> base ianahw:port;
>
> description
>
> "A transceiver-link is a special type of port that terminates an
> optical fiber.";
>
> }
>
>
>
> identity rj45 {
>
> base ianahw:port;
>
> description
>
> "A RJ45 is a special type of port that terminates an electrical
> Ethernet link.";
>
> }
>
> identity fastdsl {
>
> base ianahw:port;
>
> description
>
> "A fastdsl is a special type of port that terminates a copper wire
> supporting a FAST or one of the DSL types link.";
>
> }
>
>
>
> The intention with this approach: the 'class' leaf is used to distinguish
> between all types of hardware. If hardware specific data is augmented to the
> hardware model, then it is using a 'when' condition referring to the value
> of the leaf 'class'.
>
>
>
> Based on the description of the parent-rel-pos it is understood that the
> value of this leaf is relative to the value of the class, so numbering of
> e.g. the various types of port supported by one board is independent of each
> other.
>
>
>
> Then the worry starts:
>
> - some of the BBF members understand this concept of specializing the
> hardware identities and use these values for the leaf class as the way to
> go, and take the impact on the numbering as a given.
>
>
>
> - Others think this impact on the parent-rel-pos is not the intention and
> assume a flat numbering of all childs within a parent
Good point. In the original model (i.e. the MIB), with fixed values
for the class, having separate numbering schemes for separate classes
makes sense. For example, if a certain board has a set of ports, some
fans and a power supply, it makes sense that these are numbered
individually.
However, with specialized ports, this may or may not make sense.
It might be possible to define parent-rel-pos in a way that gives the
implementation some flexibility. For example, all ports could share
the same numbering scheme. The important thing in the current model
is that there must not exist two components with the same values for
'parent', 'class', and 'parent-rel-pos'. (strictly speaking, there is
no requirement that the parent-rel-pos is always monotonically
increasing amongst siblings, so maybe this is possible even today)
> , hence do not want to
> use the class leaf for fu
[netmod] What is the best way to HW identities
Hello,
Within BBF we have had a discussion on the use of
draft-ietf-netmod-entity-03, and we would appreciate to hear the opinion of
IETF. More specific the discussion is on the use of the leaf 'class' and the
leaf 'parent-rel-pos'.
First some BBF context:
- the systems for which BBF specifies YANG models can be built with various
'types of hardware', e.g. as pluggable item (module) it can contain boards
and it can contain SFP/XFPs. As 'type of port' it can have connectors to
terminate fastdsl links (supported over copper wires), and it can have
positions to insert optical fibers (e.g. the position in the SFP in which
one can plug the optical fiber).
- in the data model we have the need for some conditional data: e.g. an
SFP/XFP has some data that is defined in SFF-8472. This data is not
applicable to boards. Hence we need to distinguish between these 2 types of
pluggable items. A 2nd example: for the optical fibers terminated by an
SFP/XFP, we have specific data that is also defined in SFF-8472, e.g. the
wavelength. This data is not applicable to fastdsl ports. On fastdsl ports
we have specific data that relates to remote power feeding. Obviously there
is no power feeding over the optical fiber. There might be other ports with
(for now) no specific data, e.g. an rj45. Conclusion: need data conditional
to the port type.
In draft-ietf-netmod-entity-03 we read
- "The "class" leaf is a YANG identity that describes the type of the
hardware. Vendors are encouraged to either directly use one of the common
IANA-defined identities, or derive a more specific identity from one of
them.
- As description for 'parent-rel-pos': "An indication of the relative
position of this child component among all its sibling components. Sibling
components are defined as components that share the same instance values of
each of the 'parent' and 'class' nodes.
Based on what we read in the first bullet a thought was to specialize the
various hardware-class identities. Examples:
identity board {
base ianahw:module;
description
"A board is a special type of module that represents a physical item,
commonly known as a board or a card.";
}
identity transceiver {
base ianahw:module;
description
"A transceiver is a special type of module that represents a physical
item like a pluggable SFP, an SFP+, or an XFP; or a soldered SFF.";
}
identity transceiver-link {
base ianahw:port;
description
"A transceiver-link is a special type of port that terminates an
optical fiber.";
}
identity rj45 {
base ianahw:port;
description
"A RJ45 is a special type of port that terminates an electrical
Ethernet link.";
}
identity fastdsl {
base ianahw:port;
description
"A fastdsl is a special type of port that terminates a copper wire
supporting a FAST or one of the DSL types link.";
}
The intention with this approach: the 'class' leaf is used to distinguish
between all types of hardware. If hardware specific data is augmented to the
hardware model, then it is using a 'when' condition referring to the value
of the leaf 'class'.
Based on the description of the parent-rel-pos it is understood that the
value of this leaf is relative to the value of the class, so numbering of
e.g. the various types of port supported by one board is independent of each
other.
Then the worry starts:
- some of the BBF members understand this concept of specializing the
hardware identities and use these values for the leaf class as the way to
go, and take the impact on the numbering as a given.
- Others think this impact on the parent-rel-pos is not the intention and
assume a flat numbering of all childs within a parent, hence do not want to
use the class leaf for further specialization, hence want to introduce a new
separate leaf to contain the more detailed information, hence the
conditional data for the various types of hardware shall be defined with a
'when statement' referring to this new separate leaf.
The feedback we would appreciate from IETF:
- did IETF consider the need for additional conditional data?
- which approach is the IETF preference?
- in case the IETF preference is to specialize the hardware identities, does
IETF think it is worth to standardize them in IANA, or is the preference to
keep these identities within BBF?
Regards,
Bart
smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
