Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion
Benoit Claise <[email protected]> Tue, 9 Jan 2018 17:01:56 +0100
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============3751721592659520628==
Content-Type: multipart/alternative;
boundary="------------F6BE62A56D6563CDB3254B79"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------F6BE62A56D6563CDB3254B79
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Hi Marta,
>
> Hello,
>
> I am reaching out to the IETF IPFIX mailing list on some issues I
> have run into with respect to RFC 6728 Configuration Data Model for
> the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP)
> Protocols
>
> 1. RFC 6728 doesnt meet the latest Yang Best Practices
> (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1).
> Leaf identifiers are camel case (e.g., destinationAddress instead
> of destination-address). Are there any ongoing efforts to update
> RFC 6728 to meet the latest best practices?
>
Not as far as I know.
Regards, Benoit
>
> 1.
>
> Identifiers SHOULD follow a consistent naming pattern throughout the
>
> module. Only lower-case letters, numbers, and dashes SHOULD be used
>
> in identifier names. Upper-case characters and the underscore
>
> character MAY be used if the identifier represents a well-known value
>
> that uses these characters.
>
> Identifiers SHOULD include complete words and/or well-known acronyms
>
> or abbreviations. Child nodes within a container or list SHOULD NOT
>
> replicate the parent identifier. YANG identifiers are hierarchical
>
> and are only meant to be unique within the the set of sibling nodes
>
> defined in the same module namespace.
>
> It is permissible to use common identifiers such as "name" or "id" in
>
> data definition statements, especially if these data nodes share a
>
> common data type.
>
> Identifiers SHOULD NOT carry any special semantics that identify data
>
> modelling properties. Only YANG statements and YANG extension
>
> statements are designed to convey machine readable data modelling
>
> properties. For example, naming an object "config" or "state" does
>
> not change whether it is configuration data or state data. Only
>
> defined YANG statements or YANG extension statements can be used to
>
> assign semantics in a machine readable format in YANG.
>
> 2. I generated the RFC 6728 yang tree (see attached). The tcp and
> udp exporting processes support a destinationIPAddress (line 400,
> 455) which is mandatory. The type is inet:ip-address.
> 1. A collector may be doing load balancing. Rather than managing
> ip-addresses, the collector may be using DNS (an exporter
> could resolve from the domain name where the collector is
> located).
> 2. The collector address may be learnt via other methods (e.g.,
> through DHCP options)
> 3. A choice statement to select what method to use seems more
> appropriate than what is presently in RFC 6728. For example
> (use some shorthand)
>
> choice destination-method{
>
> case destination-address{
>
> leaf destination-address// rw with type inet:host
>
> }
>
> case dhcp-acquired-address{
>
> container dcp-acquired-address{
>
> leaf destination-ip-address inet-address //ro
>
> }
>
> }
>
> However I cant augment to ietf-ipfix
> because destinationIPAddress is mandatory. Can the group suggest
> methods to (a) change the destinationIPAddress type and (b) allow a
> choice?
>
> 3. RFC 6728 mandates SCTP transport. I understand the logic behind
> this (IETF prefers use of SCTP). There are situations where sctp
> is unnecessary and not supported (e.g., point to point
> connection). During netconf negotiations you can announce your
> feature set (currently sctptransport is not a feature). Is there
> ongoing work in updating RFC 6728 to include sctptransport as a
> feature (so that the device can announce whether or not it
> supports sctptransport)?
>
> Regards
>
> Marta Seda
>
>
>
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix
--------------F6BE62A56D6563CDB3254B79
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Marta,<br>
</div>
<blockquote type="cite"
cite="mid:BY2PR0501MB173415D2260734074DD777CA9C1F0@BY2PR0501MB1734.namprd05.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:872497269;
mso-list-type:hybrid;
mso-list-template-ids:1513362094 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hello,<o:p></o:p></p>
<p class="MsoNormal">I am reaching out to the IETF IPFIX mailing
list on some issues I have run into with respect to RFC 6728
Configuration Data Model for the IP Flow Information Export
(IPFIX) and Packet Sampling (PSAMP) Protocols<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="margin-left:0in;mso-list:l0
level1 lfo1">RFC 6728 doesnt meet the latest Yang Best
Practices (<a
href="https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1"
moz-do-not-send="true">https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1</a>).
Leaf identifiers are camel case (e.g., destinationAddress
instead of destination-address). Are there any ongoing
efforts to update RFC 6728 to meet the latest best
practices?</li>
</ol>
</div>
</blockquote>
Not as far as I know.<br>
<br>
Regards, Benoit<br>
<blockquote type="cite"
cite="mid:BY2PR0501MB173415D2260734074DD777CA9C1F0@BY2PR0501MB1734.namprd05.prod.outlook.com">
<div class="WordSection1">
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="margin-left:0in;mso-list:l0
level1 lfo1"><o:p></o:p></li>
</ol>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> Identifiers SHOULD follow a
consistent naming pattern throughout the<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> module. Only lower-case letters,
numbers, and dashes SHOULD be used<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> in identifier names. Upper-case
characters and the underscore<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> character MAY be used if the
identifier represents a well-known value<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> that uses these characters.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> Identifiers SHOULD include
complete words and/or well-known acronyms<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> or abbreviations. Child nodes
within a container or list SHOULD NOT<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> replicate the parent identifier.
YANG identifiers are hierarchical<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> and are only meant to be unique
within the the set of sibling nodes<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> defined in the same module
namespace.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> It is permissible to use common
identifiers such as "name" or "id" in<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> data definition statements,
especially if these data nodes share a<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> common data type.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> Identifiers SHOULD NOT carry any
special semantics that identify data<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> modelling properties. Only YANG
statements and YANG extension<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> statements are designed to convey
machine readable data modelling<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> properties. For example, naming
an object "config" or "state" does<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> not change whether it is
configuration data or state data. Only<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> defined YANG statements or YANG
extension statements can be used to<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New";color:black"> assign semantics in a machine
readable format in YANG.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="MsoNormal" style="margin-left:0in;mso-list:l0
level1 lfo1">I generated the RFC 6728 yang tree (see
attached). The tcp and udp exporting processes support a
destinationIPAddress (line 400, 455) which is mandatory.
The type is inet:ip-address.
<o:p></o:p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoNormal" style="margin-left:0in;mso-list:l0
level2 lfo1">A collector may be doing load balancing.
Rather than managing ip-addresses, the collector may be
using DNS (an exporter could resolve from the domain
name where the collector is located).
<o:p></o:p></li>
<li class="MsoNormal" style="margin-left:0in;mso-list:l0
level2 lfo1">The collector address may be learnt via
other methods (e.g., through DHCP options)<o:p></o:p></li>
<li class="MsoNormal" style="margin-left:0in;mso-list:l0
level2 lfo1">A choice statement to select what method to
use seems more appropriate than what is presently in RFC
6728. For example (use some shorthand)<o:p></o:p></li>
</ol>
</li>
</ol>
<p class="MsoNormal" style="margin-left:1.0in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">choice
destination-method{<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">
case destination-address{<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">
leaf destination-address// rw with type inet:host
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"> }<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">
case dhcp-acquired-address{<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">
container dcp-acquired-address{<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">
leaf destination-ip-address inet-address //ro<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"> }<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">}<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> However I
cant augment to ietf-ipfix because destinationIPAddress is
mandatory. Can the group suggest methods to (a) change the
destinationIPAddress type and (b) allow a choice?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="3" type="1">
<li class="MsoNormal" style="margin-left:0in;mso-list:l0
level1 lfo1">RFC 6728 mandates SCTP transport. I understand
the logic behind this (IETF prefers use of SCTP). There are
situations where sctp is unnecessary and not supported
(e.g., point to point connection). During netconf
negotiations you can announce your feature set (currently
sctptransport is not a feature). Is there ongoing work in
updating RFC 6728 to include sctptransport as a feature (so
that the device can announce whether or not it supports
sctptransport)?
<o:p></o:p></li>
</ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Marta Seda<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
IPFIX mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ipfix">https://www.ietf.org/mailman/listinfo/ipfix</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------F6BE62A56D6563CDB3254B79--
--===============3751721592659520628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
--===============3751721592659520628==--