Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion
Benoit Claise <[email protected]> Wed, 10 Jan 2018 08:33:53 +0100
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============0818749360980981197==
Content-Type: multipart/alternative;
boundary="------------C8F2BFE7A4363DF54C351EBA"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------C8F2BFE7A4363DF54C351EBA
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Hi,
>
> Marta, Benoit,
>
>
> 1. Are there efforts to update other RFCs to meet the latest YANG best
> practices?
>
Yes. Ex: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/
The goal is to specify NMDA-compliant
(draft-ietf-netmod-revised-datastores-09
<https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/>)
YANG modules
>
>
> 2. Since the IPFIX WG closed, there has been little ongoing IPFIX work
> in the IETF. Is there a specific need to update RFC 6728 rather than
> just recognising it as a product of it's time?
>
This type of feedback should come from implementation experience.
Regards, Benoit
>
> Note that it's > 5 years old.
>
>
> Also see @PJ inline:
>
>
> On 09/01/2018 16:01, Benoit Claise wrote:
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=DwMD-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=f8F8yzrqBTw6EPtR1rbibO_VFIc-cdnjIJ9he_qu7xs&m=0c5ATjuT0-4IlDzLYM9h_RbPjCBQUv_6aExRL_fl-5M&s=Hhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA_iQBzQ&e=>).
> 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
>
> 2.
>
> 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.
>
> 3. 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).
>
>
> @PJ: Load balancing and DNS are independent. Load balancing IPFIX is
> probably a bad idea since templates need to be available on all
> collectors, and out of step sequence numbers in the data records would
> cause spurious reports of lost data. If DNS is used to obtain the
> collector's address, arguably it should be a one-time lookup rather
> than incurring a DNS lookup per export packet.
>
>
> 4.
>
> 1.
> 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?
>
>
> @PJ: The selection could also be done out of band so the exporter need
> not know how the address is determined. eg a configuration system
> could determine the address by any of these methods or otherwise, and
> impose that address using the current model.
>
> 5. 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)?
>
>
> @PJ Same answer as point (2) above, ie is this necessary and useful?
>
> P.
>
--------------C8F2BFE7A4363DF54C351EBA
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,<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">
<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;}
@font-face
{font-family:"Courier New \;color\:black";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:29032718;
mso-list-template-ids:1233440172;}
@list l0:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:872497269;
mso-list-type:hybrid;
mso-list-template-ids:1513362094 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:1164783985;
mso-list-template-ids:-776306644;}
@list l2:level1
{mso-level-start-at:3;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3
{mso-list-id:1771582518;
mso-list-template-ids:1900871068;}
@list l4
{mso-list-id:1854878191;
mso-list-template-ids:-1429025646;}
@list l4:level1
{mso-level-start-at:3;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5
{mso-list-id:1969050356;
mso-list-template-ids:1347075240;}
@list l5:level1
{mso-level-start-at:4;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6
{mso-list-id:2054763915;
mso-list-template-ids:-910232920;}
@list l6:level1
{mso-level-start-at:5;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7
{mso-list-id:2115901474;
mso-list-template-ids:-64084510;}
@list l7:level1
{mso-level-start-at:4;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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">Marta, Benoit,<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
1. Are there efforts to update other RFCs to meet the
latest YANG best practices?<br>
</p>
</div>
</div>
</div>
</blockquote>
Yes. Ex:
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/">https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/</a><br>
The goal is to specify NMDA-compliant (<a
href="https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/">draft-ietf-netmod-revised-datastores-09</a>)
YANG modules<br>
<blockquote type="cite"
cite="mid:[email protected]">
<div class="WordSection1">
<div>
<div>
<p class="MsoNormal">
<br>
2. Since the IPFIX WG closed, there has been little
ongoing IPFIX work in the IETF. Is there a specific need
to update RFC 6728 rather than just recognising it as a
product of it's time? </p>
</div>
</div>
</div>
</blockquote>
This type of feedback should come from implementation experience.<br>
<br>
Regards, Benoit<br>
<blockquote type="cite"
cite="mid:[email protected]">
<div class="WordSection1">
<div>
<div>
<p class="MsoNormal">Note that it's > 5 years old.<o:p></o:p></p>
<p class="MsoNormal"><br>
Also see @PJ inline:<br>
<br>
<br>
On 09/01/2018 16:01, Benoit Claise wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Hi Marta,<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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:0cm" start="1" type="1">
<li class="MsoNormal" style="margin-left:0cm;mso-list:l1
level1 lfo3">RFC 6728 doesnt meet the latest Yang
Best Practices (<a
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=DwMD-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=f8F8yzrqBTw6EPtR1rbibO_VFIc-cdnjIJ9he_qu7xs&m=0c5ATjuT0-4IlDzLYM9h_RbPjCBQUv_6aExRL_fl-5M&s=Hhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA_iQBzQ&e="
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?<o:p></o:p></li>
</ol>
</blockquote>
<p class="MsoNormal">Not as far as I know.<br>
<br>
Regards, Benoit<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<ol style="margin-top:0cm" start="2" type="1">
<li class="MsoNormal" style="margin-left:0cm;mso-list:l1
level1 lfo3"><o:p> </o:p></li>
</ol>
<p class="MsoNormal" style="margin-left:36.0pt"> <o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> Identifiers SHOULD follow
a consistent naming pattern throughout the</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> module. Only lower-case
letters, numbers, and dashes SHOULD be used</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> in identifier names.
Upper-case characters and the underscore</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> character MAY be used if
the identifier represents a well-known value</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> that uses these
characters.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> Identifiers SHOULD
include complete words and/or well-known acronyms</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> or abbreviations. Child
nodes within a container or list SHOULD NOT</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> replicate the parent
identifier. YANG identifiers are hierarchical</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> and are only meant to be
unique within the the set of sibling nodes</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> defined in the same
module namespace.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> It is permissible to use
common identifiers such as "name" or "id" in</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> data definition
statements, especially if these data nodes share a</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> common data type.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> Identifiers SHOULD NOT
carry any special semantics that identify data</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> modelling properties.
Only YANG statements and YANG extension</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> statements are designed
to convey machine readable data modelling</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> properties. For example,
naming an object "config" or "state" does</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> not change whether it is
configuration data or state data. Only</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> defined YANG statements
or YANG extension statements can be used to</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New
;color:black",serif"> assign semantics in a
machine readable format in YANG.</span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<ol style="margin-top:0cm" start="3" type="1">
<li class="MsoNormal" style="margin-left:0cm;mso-list:l1
level1 lfo3">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></li>
</ol>
<ol style="margin-top:0cm" start="3" type="1">
<ol style="margin-top:0cm" start="1" type="a">
<li class="MsoNormal"
style="margin-left:0cm;mso-list:l1 level2 lfo3">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>
</ol>
</ol>
</blockquote>
</blockquote>
<p class="MsoNormal"><br>
@PJ: Load balancing and DNS are independent. Load balancing
IPFIX is probably a bad idea since templates need to be
available on all collectors, and out of step sequence
numbers in the data records would cause spurious reports of
lost data. If DNS is used to obtain the collector's address,
arguably it should be a one-time lookup rather than
incurring a DNS lookup per export packet.<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<ol style="margin-top:0cm" start="4" type="1">
<li class="MsoNormal" style="margin-left:0cm;mso-list:l1
level1 lfo3"><o:p> </o:p></li>
</ol>
<ol style="margin-top:0cm" start="4" type="1">
<ol style="margin-top:0cm" start="1" type="a">
<li class="MsoNormal"
style="margin-left:0cm;mso-list:l1 level2 lfo3"><o:p> </o:p></li>
<li class="MsoNormal"
style="margin-left:0cm;mso-list:l1 level2 lfo3">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:0cm;mso-list:l1 level2 lfo3">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>
</ol>
<p class="MsoNormal" style="margin-left:72.0pt"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">choice
destination-method{<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">
case destination-address{<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">
leaf destination-address// rw with type inet:host
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">
}<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">
case dhcp-acquired-address{<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">
container dcp-acquired-address{<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">
leaf destination-ip-address inet-address //ro<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">
}<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">}<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>
</blockquote>
</blockquote>
<p class="MsoNormal"><br>
@PJ: The selection could also be done out of band so the
exporter need not know how the address is determined. eg a
configuration system could determine the address by any of
these methods or otherwise, and impose that address using
the current model.<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<ol style="margin-top:0cm" start="5" type="1">
<li class="MsoNormal" style="margin-left:0cm;mso-list:l1
level1 lfo3">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>
</blockquote>
</blockquote>
<p class="MsoNormal"><br>
@PJ Same answer as point (2) above, ie is this necessary and
useful?<br>
<br>
P.<o:p></o:p></p>
</div>
</div>
</blockquote>
<br>
</body>
</html>
--------------C8F2BFE7A4363DF54C351EBA--
--===============0818749360980981197==
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
--===============0818749360980981197==--