Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion
"Aitken, Paul" <[email protected]> Tue, 9 Jan 2018 21:54:46 +0000
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
--===============4968432605741441424==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_A3625616CA873B4DAA779ABEFA624F1C8BE3CAgbcdcmbx03intlatt_"
--_000_A3625616CA873B4DAA779ABEFA624F1C8BE3CAgbcdcmbx03intlatt_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Marta, Benoit,
1. Are there efforts to update other RFCs to meet the latest YANG best prac=
tices?
2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in t=
he IETF. Is there a specific need to update RFC 6728 rather than just recog=
nising it as a product of it's time? 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 In=
formation Export (IPFIX) and Packet Sampling (PSAMP) Protocols"
1. RFC 6728 doesn't meet the latest Yang Best Practices (https://tools.i=
etf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1<https://urldefen=
se.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Dn=
etmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=3DDwMD-g&c=3DLFYZ-o9_HUMeMTSQic=
vjIg&r=3Df8F8yzrqBTw6EPtR1rbibO_VFIc-cdnjIJ9he_qu7xs&m=3D0c5ATjuT0-4IlDzLYM=
9h_RbPjCBQUv_6aExRL_fl-5M&s=3DHhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA_iQBzQ&e=
=3D>). 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.
1. I generated the RFC 6728 yang tree (see attached). The tcp and udp e=
xporting processes support a destinationIPAddress (line 400, 455) which is =
mandatory. The type is inet:ip-address.
* A collector may be doing load balancing. Rather than managing ip-=
addresses, the collector may be using DNS (an exporter could resolve from t=
he domain name where the collector is located).
@PJ: Load balancing and DNS are independent. Load balancing IPFIX is probab=
ly a bad idea since templates need to be available on all collectors, and o=
ut of step sequence numbers in the data records would cause spurious report=
s 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 expor=
t packet.
1.
*
* The collector address may be learnt via other methods (e.g., throu=
gh DHCP options)
* A choice statement to select what method to use seems more appropr=
iate than what is presently in RFC 6728. For example (use some shorthand)
choice destination-method{
case destination-address{
leaf destination-address// rw with type ine=
t:host
}
case dhcp-acquired-address{
container dcp-acquired-address{
leaf destination-ip-address=
inet-address //ro
}
}
However I can't augment to ietf-ipfix becau=
se 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 determi=
ne the address by any of these methods or otherwise, and impose that addres=
s using the current model.
1. RFC 6728 mandates SCTP transport. I understand the logic behind this=
(IETF prefers use of SCTP). There are situations where sctp is unnecessar=
y and not supported (e.g., point to point connection). During netconf nego=
tiations you can announce your feature set (currently sctptransport is not =
a feature). Is there ongoing work in updating RFC 6728 to include sctptran=
sport as a feature (so that the device can announce whether or not it suppo=
rts sctptransport)?
@PJ Same answer as point (2) above, ie is this necessary and useful?
P.
--_000_A3625616CA873B4DAA779ABEFA624F1C8BE3CAgbcdcmbx03intlatt_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"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 67698=
713 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=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"EN-GB" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Marta, Benoit,<o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal"><br>
1. Are there efforts to update other RFCs to meet the latest YANG best prac=
tices?<br>
<br>
2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in t=
he IETF. Is there a specific need to update RFC 6728 rather than just recog=
nising it as a product of it's time? Note that it's > 5 years old.<o:p><=
/o:p></p>
<p class=3D"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=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class=3D"MsoNormal">Hi Marta,<o:p></o:p></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Hello,<o:p></o:p></p>
<p class=3D"MsoNormal">I am reaching out to the IETF IPFIX mailing list &nb=
sp;on some issues I have run into with respect to RFC 6728 “Configura=
tion Data Model for the IP Flow Information Export (IPFIX) and Packet=
Sampling (PSAMP) Protocols”<o:p></o:p></p>
<p class=3D"MsoNormal"> <o:p></o:p></p>
<ol style=3D"margin-top:0cm" start=3D"1" type=3D"1">
<li class=3D"MsoNormal" style=3D"margin-left:0cm;mso-list:l1 level1 lfo3">R=
FC 6728 doesn’t meet the latest Yang Best Practices (<a href=3D"https=
://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft=
-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=3DDwMD-g&c=
=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Df8F8yzrqBTw6EPtR1rbibO_VFIc-cdnjIJ9he_qu7=
xs&m=3D0c5ATjuT0-4IlDzLYM9h_RbPjCBQUv_6aExRL_fl-5M&s=3DHhi7V6njCFNB=
bSsjC6sPgNfVu5DA8iQzdzsnA_iQBzQ&e=3D">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 desti=
nation-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=3D"MsoNormal">Not as far as I know.<br>
<br>
Regards, Benoit<br>
<br>
<o:p></o:p></p>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<ol style=3D"margin-top:0cm" start=3D"2" type=3D"1">
<li class=3D"MsoNormal" style=3D"margin-left:0cm;mso-list:l1 level1 lfo3"><=
o:p> </o:p></li></ol>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"> <o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> Identifiers SHOULD follow =
a consistent naming pattern throughout the</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> module. Only lower-c=
ase letters, numbers, and dashes SHOULD be used</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> in identifier names. =
Upper-case characters and the underscore</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> character MAY be used if t=
he identifier represents a well-known value</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> that uses these characters=
.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> </span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> Identifiers SHOULD include=
complete words and/or well-known acronyms</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> or abbreviations. Ch=
ild nodes within a container or list SHOULD NOT</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> replicate the parent ident=
ifier. YANG identifiers are hierarchical</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> and are only meant to be u=
nique within the the set of sibling nodes</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> defined in the same module=
namespace.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> </span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> It is permissible to use c=
ommon identifiers such as "name" or "id" in</span><o:p>=
</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> data definition statements=
, especially if these data nodes share a</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> common data type.</span><o=
:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> </span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> Identifiers SHOULD NOT car=
ry any special semantics that identify data</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> modelling properties. =
; Only YANG statements and YANG extension</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> statements are designed to=
convey machine readable data modelling</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> properties. For exam=
ple, naming an object "config" or "state" does</span><o=
:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> not change whether it is c=
onfiguration data or state data. Only</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> defined YANG statements or=
YANG extension statements can be used to</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co=
urier New ;color:black",serif"> assign semantics in a mach=
ine readable format in YANG.</span><o:p></o:p></p>
<p class=3D"MsoNormal"> <o:p></o:p></p>
<ol style=3D"margin-top:0cm" start=3D"3" type=3D"1">
<li class=3D"MsoNormal" style=3D"margin-left:0cm;mso-list:l1 level1 lfo3">I=
generated the RFC 6728 yang tree (see attached). The tcp and udp exp=
orting processes support a destinationIPAddress (line 400, 455) which is ma=
ndatory. The type is inet:ip-address.
<o:p></o:p></li></ol>
<ol style=3D"margin-top:0cm" start=3D"3" type=3D"1">
<ol style=3D"margin-top:0cm" start=3D"1" type=3D"a">
<li class=3D"MsoNormal" style=3D"margin-left:0cm;mso-list:l1 level2 lfo3">A=
collector may be doing load balancing. Rather than managing ip-addre=
sses, the collector may be using DNS (an exporter could resolve from the do=
main name where the collector is located).
<o:p></o:p></li></ol>
</ol>
</blockquote>
</blockquote>
<p class=3D"MsoNormal"><br>
@PJ: Load balancing and DNS are independent. Load balancing IPFIX is probab=
ly a bad idea since templates need to be available on all collectors, and o=
ut of step sequence numbers in the data records would cause spurious report=
s of lost data. If DNS is used to
obtain the collector's address, arguably it should be a one-time lookup ra=
ther than incurring a DNS lookup per export packet.<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<ol style=3D"margin-top:0cm" start=3D"4" type=3D"1">
<li class=3D"MsoNormal" style=3D"margin-left:0cm;mso-list:l1 level1 lfo3"><=
o:p> </o:p></li></ol>
<ol style=3D"margin-top:0cm" start=3D"4" type=3D"1">
<ol style=3D"margin-top:0cm" start=3D"1" type=3D"a">
<li class=3D"MsoNormal" style=3D"margin-left:0cm;mso-list:l1 level2 lfo3"><=
o:p> </o:p></li><li class=3D"MsoNormal" style=3D"margin-left:0cm;mso-l=
ist:l1 level2 lfo3">The collector address may be learnt via other methods (=
e.g., through DHCP options)<o:p></o:p></li><li class=3D"MsoNormal" style=3D=
"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.&n=
bsp; For example (use some shorthand)<o:p></o:p></li></ol>
</ol>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt"> <o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">choice destination-meth=
od{<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  =
; case de=
stination-address{<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  =
; &n=
bsp;  =
; leaf destination-address// rw with type inet:host
<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  =
; }<o:p><=
/o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  =
; case dh=
cp-acquired-address{<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  =
; &n=
bsp;  =
; container dcp-acquired-address{<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  =
; &n=
bsp;  =
; &n=
bsp; leaf destination-ip-address inet-address=
//ro<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  =
; }<o:p><=
/o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">}<o:p></o:p></p>
<p class=3D"MsoNormal"> &nbs=
p; &=
nbsp; <o:p></o:p></p>
<p class=3D"MsoNormal"> &nbs=
p; &=
nbsp; However I can&#=
8217;t augment to ietf-ipfix because destinationIPAddress is mandatory.&nbs=
p; Can the group suggest methods to (a) change the destinationIPAddress typ=
e and (b) allow a choice?<o:p></o:p></p>
</blockquote>
</blockquote>
<p class=3D"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 determi=
ne the address by any of these methods or otherwise, and impose that addres=
s using the current model.<br>
<br>
<o:p></o:p></p>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<ol style=3D"margin-top:0cm" start=3D"5" type=3D"1">
<li class=3D"MsoNormal" style=3D"margin-left:0cm;mso-list:l1 level1 lfo3">R=
FC 6728 mandates SCTP transport. I understand the logic behind this (=
IETF prefers use of SCTP). There are situations where sctp is unneces=
sary and not supported (e.g., point to point connection).
During netconf negotiations you can announce your feature set (currently s=
ctptransport is not a feature). Is there ongoing work in updating RFC=
6728 to include sctptransport as a feature (so that the device can announc=
e whether or not it supports sctptransport)?<o:p></o:p></li></ol>
</blockquote>
</blockquote>
<p class=3D"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>
</body>
</html>
--_000_A3625616CA873B4DAA779ABEFA624F1C8BE3CAgbcdcmbx03intlatt_--
--===============4968432605741441424==
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
--===============4968432605741441424==--