Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion
Andrew Feren <[email protected]> Mon, 15 Jan 2018 18:09:20 +0000
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
--===============1070291588913931549== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429PLXRDC01plxrloc_" --_000_8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429PLXRDC01plxrloc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In particular renaming identifiers would break any implementations of RFC 7= 373 "Textual Representation of IP Flow Information Export (IPFIX) Abstract = Data Types". -Andrew ________________________________ From: IPFIX [[email protected]] on behalf of Gerhard Muenz [muenz@net.= in.tum.de] Sent: Saturday, January 13, 2018 4:43 AM To: Benoit Claise; Aitken, Paul; 'Marta Seda' Cc: '[email protected]' Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion Marta, all, A few additional thoughts regarding your questions: 1) I would not expect that not following current naming convention hinders = implementation of RFC 6728. On the other hand, if we change just the names = of the identifiers, we lose interoperability with older implementations tha= t may exist. 2) I think that it is reasonable that destinationIPAddress is mandatory bec= ause network management systems should be able to query the IP address to w= hich an Exporting Process sends data. As Paul stated, RFC 6728 does not say= how the destination IP address is set. 3) SCTP is still a mandatory transport for a compliant implementation of an= IPFIX device, not a feature. See: https://tools.ietf.org/html/rfc7011#sect= ion-10.1<https://linkprotect.cudasvc.com/url?a=3Dhttps://tools.ietf.org/htm= l/rfc7011%23section-10.1&c=3DE,1,r3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27M= Byjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2Dh_-xePoq9GNzzaPGdY= j0o&typo=3D1> Best regards, Gerhard On 10.01.2018 08:33, Benoit Claise wrote: Hi, Marta, Benoit, 1. Are there efforts to update other RFCs to meet the latest YANG best prac= tices? Yes. Ex: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/<htt= ps://linkprotect.cudasvc.com/url?a=3Dhttps://datatracker.ietf.org/doc/draft= -ietf-netmod-rfc7223bis/&c=3DE,1,990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI_bfqIgW= 2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap_iznZ68ZknJgFbizFJolgU&= typo=3D1> The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores= -09<https://linkprotect.cudasvc.com/url?a=3Dhttps://datatracker.ietf.org/do= c/draft-ietf-netmod-revised-datastores/&c=3DE,1,ByKxVFeHf8k0Yb1kzzkQnQg33Vf= rR12Hy6dJzQTbkgStXZt3NzfCi7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-78uXEs5xDZq= l2y--4iDlmOUQ,&typo=3D1>) YANG modules 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? 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 =93Configuration Data Model for the IP Flow = Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols=94 1. RFC 6728 doesn=92t meet the latest Yang Best Practices (https://tools= .ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1<https://linkpr= otect.cudasvc.com/url?a=3Dhttps://urldefense.proofpoint.com/v2/url%3fu%3dht= tps-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23secti= on-2D4.3.1%26d%3dDwMD-g%26c%3dLFYZ-o9_HUMeMTSQicvjIg%26r%3df8F8yzrqBTw6EPtR= 1rbibO_VFIc-cdnjIJ9he_qu7xs%26m%3d0c5ATjuT0-4IlDzLYM9h_RbPjCBQUv_6aExRL_fl-= 5M%26s%3dHhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA_iQBzQ%26e%3d&c=3DE,1,5Zsm8ll= hIef_jTZU2aAY2fj_KvmJs-zBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b_L6CTmk_VY1-To7t8aT= M7RBz2ayGhe3OrxbBk7_Oy6I7gQSkKDC8Eig,,&typo=3D1>). Leaf identifiers are c= amel case (e.g., destinationAddress instead of destination-address). Are t= here any ongoing efforts to update RFC 6728 to meet the latest best practic= es? 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=92t augment to ietf-ipfix bec= ause 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. _______________________________________________ IPFIX mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipfix<https://linkprotect.cudasvc.com= /url?a=3Dhttps://www.ietf.org/mailman/listinfo/ipfix&c=3DE,1,QcSaORG4ENECoj= kXawtykKdqqGaKdIQCAXU_k7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyqMbCphIEyv8a= BgtyyQbbN31fnbrx9I,&typo=3D1> --_000_8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429PLXRDC01plxrloc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <style type=3D"text/css" id=3D"owaParaStyle"></style> </head> <body fpstyle=3D"1" ocsi=3D"0" bgcolor=3D"#FFFFFF"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">In particular renaming identifiers would break any implementations o= f RFC 7373 "Textual Representation of IP Flow Information Export (IPFI= X) Abstract Data Types".<br> <br> -Andrew<br> <br> <div style=3D"font-family: Times New Roman; color: #000000; font-size: 16px= "> <hr tabindex=3D"-1"> <div id=3D"divRpF1671" style=3D"direction: ltr;"><font size=3D"2" face=3D"T= ahoma" color=3D"#000000"><b>From:</b> IPFIX [[email protected]] on beh= alf of Gerhard Muenz [[email protected]]<br> <b>Sent:</b> Saturday, January 13, 2018 4:43 AM<br> <b>To:</b> Benoit Claise; Aitken, Paul; 'Marta Seda'<br> <b>Cc:</b> '[email protected]'<br> <b>Subject:</b> [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion<br> </font><br> </div> <div></div> <div><br> Marta, all,<br> <br> A few additional thoughts regarding your questions:<br> <br> 1) I would not expect that not following current naming convention hinders = implementation of RFC 6728. On the other hand, if we change just the names = of the identifiers, we lose interoperability with older implementations tha= t may exist.<br> <br> 2) I think that it is reasonable that destinationIPAddress is mandatory bec= ause network management systems should be able to query the IP address to w= hich an Exporting Process sends data. As Paul stated, RFC 6728 does not say= how the destination IP address is set.<br> <br> 3) SCTP is still a mandatory transport for a compliant implementation of an= IPFIX device, not a feature. See: <a class=3D"moz-txt-link-freetext" href=3D"https://linkprotect.cudasvc.com/= url?a=3Dhttps://tools.ietf.org/html/rfc7011%23section-10.1&c=3DE,1,r3o6= fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy= 81bK1Aq33fYFzGl5W-2Dh_-xePoq9GNzzaPGdYj0o&typo=3D1" target=3D"_blank"> https://tools.ietf.org/html/rfc7011#section-10.1</a><br> <br> Best regards,<br> Gerhard<br> <br> <br> <br> <div class=3D"moz-cite-prefix">On 10.01.2018 08:33, Benoit Claise wrote:<br= > </div> <blockquote type=3D"cite"> <div class=3D"moz-cite-prefix">Hi,<br> </div> <blockquote type=3D"cite"><style>=0A= <!--=0A= @font-face=0A= {font-family:"Cambria Math"}=0A= @font-face=0A= {font-family:Calibri}=0A= p.MsoNormal, li.MsoNormal, div.MsoNormal=0A= {margin:0cm;=0A= margin-bottom:.0001pt;=0A= font-size:11.0pt;=0A= font-family:"Calibri",sans-serif;=0A= color:black}=0A= a:link, span.MsoHyperlink=0A= {color:#0563C1;=0A= text-decoration:underline}=0A= a:visited, span.MsoHyperlinkFollowed=0A= {color:#954F72;=0A= text-decoration:underline}=0A= p.msonormal0, li.msonormal0, div.msonormal0=0A= {margin-right:0cm;=0A= margin-left:0cm;=0A= font-size:11.0pt;=0A= font-family:"Calibri",sans-serif;=0A= color:black}=0A= span.EmailStyle18=0A= {font-family:"Calibri",sans-serif;=0A= color:windowtext}=0A= span.EmailStyle19=0A= {font-family:"Calibri",sans-serif;=0A= color:windowtext}=0A= span.EmailStyle20=0A= {font-family:"Calibri",sans-serif;=0A= color:windowtext}=0A= .MsoChpDefault=0A= {font-size:10.0pt}=0A= @page WordSection1=0A= {margin:72.0pt 72.0pt 72.0pt 72.0pt}=0A= ol=0A= {margin-bottom:0cm}=0A= ul=0A= {margin-bottom:0cm}=0A= -->=0A= BODY {direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;}P = {margin-top:0;margin-bottom:0;}</style> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Marta, Benoit,</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> </p> </div> </div> </div> </blockquote> Yes. Ex: <a class=3D"moz-txt-link-freetext" href=3D"https://linkprotect.cud= asvc.com/url?a=3Dhttps://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223= bis/&c=3DE,1,990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI_bfqIgW2gpaEOYhngASoi8L= RRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap_iznZ68ZknJgFbizFJolgU&typo=3D1" ta= rget=3D"_blank"> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/</a><br> The goal is to specify NMDA-compliant (<a href=3D"https://linkprotect.cudas= vc.com/url?a=3Dhttps://datatracker.ietf.org/doc/draft-ietf-netmod-revised-d= atastores/&c=3DE,1,ByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfC= i7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-78uXEs5xDZql2y--4iDlmOUQ,&typo= =3D1" target=3D"_blank">draft-ietf-netmod-revised-datastores-09</a>) YANG modules<br> <blockquote type=3D"cite"> <div class=3D"WordSection1"> <div> <div> <p class=3D"MsoNormal"><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? </p> </div> </div> </div> </blockquote> This type of feedback should come from implementation experience.<br> <br> Regards, Benoit<br> <blockquote type=3D"cite"> <div class=3D"WordSection1"> <div> <div> <p class=3D"MsoNormal">Note that it's > 5 years old.</p> <p class=3D"MsoNormal"><br> Also see @PJ inline:<br> <br> <br> On 09/01/2018 16:01, Benoit Claise wrote:</p> </div> <blockquote style=3D"margin-top:5.0pt; margin-bottom:5.0pt"> <div> <p class=3D"MsoNormal">Hi Marta,</p> </div> <blockquote style=3D"margin-top:5.0pt; margin-bottom:5.0pt"> <p class=3D"MsoNormal">Hello,</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 =93Configuration= Data Model for the IP Flow Information Export (IPFIX) and Packet Sam= pling (PSAMP) Protocols=94</p> <p class=3D"MsoNormal"> </p> <ol start=3D"1" style=3D"margin-top:0cm" type=3D"1"> <li class=3D"MsoNormal" style=3D"margin-left:0cm">RFC 6728 doesn=92t meet t= he latest Yang Best Practices (<a href=3D"https://linkprotect.cudasvc.com/u= rl?a=3Dhttps://urldefense.proofpoint.com/v2/url%3fu%3dhttps-3A__tools.ietf.= org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1%26d%3dDw= MD-g%26c%3dLFYZ-o9_HUMeMTSQicvjIg%26r%3df8F8yzrqBTw6EPtR1rbibO_VFIc-cdnjIJ9= he_qu7xs%26m%3d0c5ATjuT0-4IlDzLYM9h_RbPjCBQUv_6aExRL_fl-5M%26s%3dHhi7V6njCF= NBbSsjC6sPgNfVu5DA8iQzdzsnA_iQBzQ%26e%3d&c=3DE,1,5Zsm8llhIef_jTZU2aAY2f= j_KvmJs-zBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b_L6CTmk_VY1-To7t8aTM7RBz2ayGhe3Orx= bBk7_Oy6I7gQSkKDC8Eig,,&typo=3D1" target=3D"_blank">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? </li></ol> </blockquote> <p class=3D"MsoNormal">Not as far as I know.<br> <br> Regards, Benoit<br> <br> </p> <blockquote style=3D"margin-top:5.0pt; margin-bottom:5.0pt"> <ol start=3D"2" style=3D"margin-top:0cm" type=3D"1"> <li class=3D"MsoNormal" style=3D"margin-left:0cm"> </li></ol> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"> </p> <p class=3D"MsoNormal"><span style=3D""> Identifiers SHOULD fol= low a consistent naming pattern throughout the</span></p> <p class=3D"MsoNormal"><span style=3D""> module. Only low= er-case letters, numbers, and dashes SHOULD be used</span></p> <p class=3D"MsoNormal"><span style=3D""> in identifier names.&n= bsp; Upper-case characters and the underscore</span></p> <p class=3D"MsoNormal"><span style=3D""> character MAY be used = if the identifier represents a well-known value</span></p> <p class=3D"MsoNormal"><span style=3D""> that uses these charac= ters.</span></p> <p class=3D"MsoNormal"><span style=3D""> </span></p> <p class=3D"MsoNormal"><span style=3D""> Identifiers SHOULD inc= lude complete words and/or well-known acronyms</span></p> <p class=3D"MsoNormal"><span style=3D""> or abbreviations. = ; Child nodes within a container or list SHOULD NOT</span></p> <p class=3D"MsoNormal"><span style=3D""> replicate the parent i= dentifier. YANG identifiers are hierarchical</span></p> <p class=3D"MsoNormal"><span style=3D""> and are only meant to = be unique within the the set of sibling nodes</span></p> <p class=3D"MsoNormal"><span style=3D""> defined in the same mo= dule namespace.</span></p> <p class=3D"MsoNormal"><span style=3D""> </span></p> <p class=3D"MsoNormal"><span style=3D""> It is permissible to u= se common identifiers such as "name" or "id" in</span><= /p> <p class=3D"MsoNormal"><span style=3D""> data definition statem= ents, especially if these data nodes share a</span></p> <p class=3D"MsoNormal"><span style=3D""> common data type.</spa= n></p> <p class=3D"MsoNormal"><span style=3D""> </span></p> <p class=3D"MsoNormal"><span style=3D""> Identifiers SHOULD NOT= carry any special semantics that identify data</span></p> <p class=3D"MsoNormal"><span style=3D""> modelling properties.&= nbsp; Only YANG statements and YANG extension</span></p> <p class=3D"MsoNormal"><span style=3D""> statements are designe= d to convey machine readable data modelling</span></p> <p class=3D"MsoNormal"><span style=3D""> properties. For = example, naming an object "config" or "state" does</spa= n></p> <p class=3D"MsoNormal"><span style=3D""> not change whether it = is configuration data or state data. Only</span></p> <p class=3D"MsoNormal"><span style=3D""> defined YANG statement= s or YANG extension statements can be used to</span></p> <p class=3D"MsoNormal"><span style=3D""> assign semantics in a = machine readable format in YANG.</span></p> <p class=3D"MsoNormal"> </p> <ol start=3D"3" style=3D"margin-top:0cm" type=3D"1"> <li class=3D"MsoNormal" style=3D"margin-left:0cm">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. </li></ol> <ol start=3D"3" style=3D"margin-top:0cm" type=3D"1"> <ol start=3D"1" style=3D"margin-top:0cm" type=3D"a"> <li class=3D"MsoNormal" style=3D"margin-left:0cm">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 coll= ector is located). </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> </p> <blockquote style=3D"margin-top:5.0pt; margin-bottom:5.0pt"> <blockquote style=3D"margin-top:5.0pt; margin-bottom:5.0pt"> <ol start=3D"4" style=3D"margin-top:0cm" type=3D"1"> <li class=3D"MsoNormal" style=3D"margin-left:0cm"> </li></ol> <ol start=3D"4" style=3D"margin-top:0cm" type=3D"1"> <ol start=3D"1" style=3D"margin-top:0cm" type=3D"a"> <li class=3D"MsoNormal" style=3D"margin-left:0cm"> </li><li class=3D"= MsoNormal" style=3D"margin-left:0cm">The collector address may be learnt vi= a other methods (e.g., through DHCP options) </li><li class=3D"MsoNormal" style=3D"margin-left:0cm">A choice statement t= o select what method to use seems more appropriate than what is presently i= n RFC 6728. For example (use some shorthand) </li></ol> </ol> <p class=3D"MsoNormal" style=3D"margin-left:72.0pt"> </p> <p class=3D"MsoNormal" style=3D"margin-left:72.0pt">choice destination-meth= od{</p> <p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  = ; case de= stination-address{</p> <p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  = ; &n= bsp;  = ; leaf destination-address// rw with type inet:host </p> <p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  = ; }</p> <p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  = ; case dh= cp-acquired-address{</p> <p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  = ; &n= bsp;  = ; container dcp-acquired-address{</p> <p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  = ; &n= bsp;  = ; &n= bsp; leaf destination-ip-address inet-address= //ro</p> <p class=3D"MsoNormal" style=3D"margin-left:72.0pt">  = ; }</p> <p class=3D"MsoNormal" style=3D"margin-left:72.0pt">}</p> <p class=3D"MsoNormal"> &nbs= p; &= nbsp; </p> <p class=3D"MsoNormal"> &nbs= p; &= nbsp; However I can= =92t augment to ietf-ipfix because destinationIPAddress is mandatory. = Can the group suggest methods to (a) change the destinationIPAddress type = and (b) allow a choice?</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> </p> <blockquote style=3D"margin-top:5.0pt; margin-bottom:5.0pt"> <blockquote style=3D"margin-top:5.0pt; margin-bottom:5.0pt"> <ol start=3D"5" style=3D"margin-top:0cm" type=3D"1"> <li class=3D"MsoNormal" style=3D"margin-left:0cm">RFC 6728 mandates SCTP tr= ansport. 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 includ= e sctptransport as a feature (so that the device can announce whether or no= t it supports sctptransport)? </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.</p> </div> </div> </blockquote> <br> <br> <fieldset class=3D"mimeAttachmentHeader" target=3D"_blank"></fieldset> <br> <pre>_______________________________________________=0A= IPFIX mailing list=0A= <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>=0A= <a class=3D"moz-txt-link-freetext" href=3D"https://linkprotect.cudasvc.com/= url?a=3Dhttps://www.ietf.org/mailman/listinfo/ipfix&c=3DE,1,QcSaORG4ENE= CojkXawtykKdqqGaKdIQCAXU_k7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyqMbCphIEy= v8aBgtyyQbbN31fnbrx9I,&typo=3D1" target=3D"_blank">https://www.ietf.org= /mailman/listinfo/ipfix</a>=0A= </pre> </blockquote> <br> </div> </div> </div> </body> </html> --_000_8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429PLXRDC01plxrloc_-- --===============1070291588913931549== 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 --===============1070291588913931549==--