Subject: Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion

From: "Aitken, Paul" <[email-masked]>
Date: Tue, 9 Jan 2018 21:54:46 +0000

Marta, Benoit,

1. Are there efforts to update other RFCs to meet the latest YANG best practices?

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? 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 doesn't 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

  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 exporting 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 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.

  1.

     *
     *   The collector address may be learnt via other methods (e.g., through DHCP options)
     *   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 can't 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.

  1.  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.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 10 Jan 2018 08:33:53 +0100

Hi,
> 1. Are there efforts to update other RFCs to meet the latest YANG best 
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:
>
>
>         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 doesn’t 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.
>
>          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)
>
>         However I can’t 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)?
>
>

---

From: Gerhard Muenz <[email-masked]>
Date: Sat, 13 Jan 2018 10:43:32 +0100

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 that may exist.

2) I think that it is reasonable that destinationIPAddress is mandatory 
because network management systems should be able to query the IP 
address to which 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#section-10.1

Best regards,
Gerhard

On 10.01.2018 08:33, Benoit Claise wrote:
>> 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?
>>
>>         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”
>>
>> 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.
>> @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.
>>
>>             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)?
>>
>>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Andrew Feren <[email-masked]>
Date: Mon, 15 Jan 2018 18:09:20 +0000

In particular renaming identifiers would break any implementations of RFC 7373 "Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types".

-Andrew

________________________________
From: IPFIX [[email-masked]] on behalf of Gerhard Muenz [[email-masked]]
Sent: Saturday, January 13, 2018 4:43 AM
To: Benoit Claise; Aitken, Paul; 'Marta Seda'
Cc: [email-masked]'
Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion

Marta, all,

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 that may exist.

2) I think that it is reasonable that destinationIPAddress is mandatory because network management systems should be able to query the IP address to which 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#section-10.1<https://linkprotect.cudasvc.com/url?a=https://tools.ietf.org/html/rfc7011%23section-10.1&c=E,1,r3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2Dh_-xePoq9GNzzaPGdYj0o&typo=1>

Best regards,
Gerhard

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/<https://linkprotect.cudasvc.com/url?a=https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/&c=E,1,990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI_bfqIgW2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap_iznZ68ZknJgFbizFJolgU&typo=1>
The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores-09<https://linkprotect.cudasvc.com/url?a=https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/&c=E,1,ByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-78uXEs5xDZql2y--4iDlmOUQ,&typo=1>) 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

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 doesn’t meet the latest Yang Best Practices (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1<https://linkprotect.cudasvc.com/url?a=https://urldefense.proofpoint.com/v2/url%3fu%3dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1%26d%3dDwMD-g%26c%3dLFYZ-o9_HUMeMTSQicvjIg%26r%3df8F8yzrqBTw6EPtR1rbibO_VFIc-cdnjIJ9he_qu7xs%26m%3d0c5ATjuT0-4IlDzLYM9h_RbPjCBQUv_6aExRL_fl-5M%26s%3dHhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA_iQBzQ%26e%3d&c=E,1,5Zsm8llhIef_jTZU2aAY2fj_KvmJs-zBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b_L6CTmk_VY1-To7t8aTM7RBz2ayGhe3OrxbBk7_Oy6I7gQSkKDC8Eig,,&typo=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.

  1.

     *

                                However I can’t 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.

_______________________________________________
IPFIX mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipfix<https://linkprotect.cudasvc.com/url?a=https://www.ietf.org/mailman/listinfo/ipfix&c=E,1,QcSaORG4ENECojkXawtykKdqqGaKdIQCAXU_k7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyqMbCphIEyv8aBgtyyQbbN31fnbrx9I,&typo=1>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Jan 2018 19:50:43 +0100

I fail to see why this would be the case. (But I agree that renaming
identifiers for the sake of renaming them is having little value.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Marta Seda <[email-masked]>
Date: Mon, 15 Jan 2018 20:35:22 +0000

Just a few things to consider about RFC 6728 (which is Yang 1.0 compliant).  Following best practices is not the only issue with RFC 6728.  It does not support Yang 1.1 (or RFC 7895 Netconf library).  I am not promoting the idea of updating RFC 6728 (that is an IETF decision) but was trying to understand if there were any future plans to address the issues I brought up.    Some additional points to think about:

All SDOs (IEEE, IETF, BBF, MEF, etc) have migrated to Yang 1.1.  Yang 1.1 supports the ietf-library module (see https://tools.ietf.org/html/rfc7895).  In the "hypothetical" case where you were developing a brand new ipfix module, you could create multiple submodules (e.g., one for exporter, another for collector, etc).  A device would import only those modules it supports (and use the netconf library to explicitly show deviations).   That would be a "nice" improvement (right now RFC 6728 is one big module containing everything).  However going back to reality, it would be a non-backwards compatible change and backward compatibility issues may be the reason for deciding not to do changes to ipfix psamp yang.

If a vendor needs to support psamp, yang 1.1 and yang best practices, one option is to create their own yang module (and leave RFC 6728 behind) or promote the idea to another SDO (who may be creating new yang modules to support ipfix beyond what RFC 6728 defines today) to pick up the activity of reformulating psamp yang to take advantage of newer IETF functions (yang 1.1 and best practices).  That assumes of course if IETF decides there is no need to update RFC 6728 (which I think is what I am hearing in this thread - no updates in RFC 6728).

Regards,

Marta Seda
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, January 15, 2018 10:51 AM
To: Andrew Feren <[email-masked]>
Cc: Gerhard Muenz <[email-masked]>; Benoit Claise <[email-masked]>; Aitken, Paul <[email-masked]>; Marta Seda <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion

I fail to see why this would be the case. (But I agree that renaming identifiers for the sake of renaming them is having little value.)

/js

On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote:
> 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#section-10.1<https://linkprotect.c
> udasvc.com/url?a=https://tools.ietf.org/html/rfc7011%23section-10.1&c=
> E,1,r3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDoDzj1XgWt
> TXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2Dh_-xePoq9GNzzaPGdYj0o&typo=1>
> 
> Best regards,
> Gerhard
> 
> 
> 
> Yes. Ex: 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/<https:/
> /linkprotect.cudasvc.com/url?a=https://datatracker.ietf.org/doc/draft-
> ietf-netmod-rfc7223bis/&c=E,1,990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI_bfqI
> gW2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap_iznZ68ZknJgFbiz
> FJolgU&typo=1> The goal is to specify NMDA-compliant 
> (draft-ietf-netmod-revised-datastores-09<https://linkprotect.cudasvc.c
> om/url?a=https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-da
> tastores/&c=E,1,ByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7
> l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-78uXEs5xDZql2y--4iDlmOUQ,&typo=1>
> ) YANG modules
> 
> https://www.ietf.org/mailman/listinfo/ipfix<https://linkprotect.cudasv
> c.com/url?a=https://www.ietf.org/mailman/listinfo/ipfix&c=E,1,QcSaORG4
> ENECojkXawtykKdqqGaKdIQCAXU_k7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyq
> MbCphIEyv8aBgtyyQbbN31fnbrx9I,&typo=1>
> 
>

---

From: "Wayne Tackabury" <[email-masked]>
Date: Mon, 15 Jan 2018 21:10:01 +0000

Regarding SCTP, as of this writing, it is not and can not be mandatory.  Not many commercial collectors support it.  I've found this to be a bit of an "elephant in the room" on the RFC directions.

To be perfectly practical, as things have emerged since the days of RFC[s] 510x, SCTP has not been made sufficiently stable in linux kernel and user interfaces that it could support carrier-grade flow conveyance dependencies.  There are probably other nontechnical barriers to acceptance. To be sure, this is unfortunate, since SCTP still admirably meets the original design goals.

Without getting into it, where I'm aware of implementations that meed tp make use of the "messaging" benefits of SCTP over UDP, the less-than-standard path of TCP over some defacto standard port  has been used.  Others may know of different implementations, but this is based on subjective, but voluminous, input from implementations I've seen at customer sites and discussions with colleagues at different vendor enterprises.  Again, this is not an editorial on technical merit.

Regards,

Wayne

----- Original message -----
From: Juergen Schoenwaelder <[email-masked]>
Sent by: "IPFIX" <[email-masked]>
To: Andrew Feren <[email-masked]>
Cc: 'Marta Seda' <[email-masked]>, "Aitken, Paul" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion
Date: Mon, Jan 15, 2018 1:51 PM

/js

On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote:
> 3) SCTP is still a mandatory transport for a compliant implementation of an IPFIX device, not a feature. See: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7011-23section-2D10.1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=qunYBh7bv5ABGGsiP6-CjGVRw8xFMTnuuwuibkkNfBE&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__tools.ietf.org_html_rfc7011-2523section-2D10.1-26c-3DE-2C1-2Cr3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2D2Dh-5F-2DxePoq9GNzzaPGdYj0o-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=M0CgR7V3IlBqkpQDo2Brx-bewHWnHX_a5l7YChB32BI&e=>
>
> Best regards,
> Gerhard
>
>
>
> Yes. Ex: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=Dml5zgSWzeUBwS1XyKmCG-y3bWePHxpzt3PCej4w_zw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_-26c-3DE-2C1-2C990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI-5FbfqIgW2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap-5FiznZ68ZknJgFbizFJolgU-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=whhuVEyPDEyPYoboty-rb0h_RQBoHKqNmiQoGwpLBlw&e=>
> The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores-09<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised-2Ddatastores_-26c-3DE-2C1-2CByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-2D78uXEs5xDZql2y-2D-2D4iDlmOUQ-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=gGNMKyVcGZrZBCbVl5XjjnnyJnRDUxt8jU3e24fcQBU&e=>) YANG modules
>
>   1.  RFC 6728 doesn’t meet the latest Yang Best Practices (https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=SSYo4WM-xFfyPgrSh-cja-jQFQEucW4daULPdwg2zSI&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__urldefense.proofpoint.com_v2_url-253fu-253dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Dietf-2D2Dnetmod-2D2Drfc6087bis-2D2D15-2D23section-2D2D4.3.1-2526d-253dDwMD-2Dg-2526c-253dLFYZ-2Do9-5FHUMeMTSQicvjIg-2526r-253df8F8yzrqBTw6EPtR1rbibO-5FVFIc-2DcdnjIJ9he-5Fqu7xs-2526m-253d0c5ATjuT0-2D4IlDzLYM9h-5FRbPjCBQUv-5F6aExRL-5Ffl-2D5M-2526s-253dHhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA-5FiQBzQ-2526e-253d-26c-3DE-2C1-2C5Zsm8llhIef-5FjTZU2aAY2fj-5FKvmJs-2DzBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b-5FL6CTmk-5FVY1-2DTo7t8aTM7RBz2ayGhe3OrxbBk7-5FOy6I7gQSkKDC8Eig-2C-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=oj6Kq-4SRjuodk73yxC5K1cDKw8XP95L_H_m3ErUuQM&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
>
>
>   1.
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__www.ietf.org_mailman_listinfo_ipfix-26c-3DE-2C1-2CQcSaORG4ENECojkXawtykKdqqGaKdIQCAXU-5Fk7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyqMbCphIEyv8aBgtyyQbbN31fnbrx9I-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=cQFI-IsxLhklEI0w-JcCksB_YNvx9v06CpqsjQys0N8&e=>
>
>

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=cC8C3QfrkIEC1Vo-QLwKrh955-evz_Tr3MYoFDTmD1A&e=>

_______________________________________________
IPFIX mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=

---

From: Benoit Claise <[email-masked]>
Date: Mon, 15 Jan 2018 22:18:29 +0100

On 1/15/2018 10:10 PM, Wayne Tackabury wrote:
> Regarding SCTP, as of this writing, it is not and can not be 
> mandatory.  Not many commercial collectors support it.  I've found 
> this to be a bit of an "elephant in the room" on the RFC directions.
No disagreement.
http://www.claise.be/2015/06/from-netflow-to-ipfix-via-psamp-13-years-of-standardization-explained-2/

Regards, B.
> To be perfectly practical, as things have emerged since the days of 
> RFC[s] 510x, SCTP has not been made sufficiently stable in linux 
> kernel and user interfaces that it could support carrier-grade flow 
> conveyance dependencies. There are probably other nontechnical 
> barriers to acceptance. To be sure, this is unfortunate, since SCTP 
> still admirably meets the original design goals.
> Without getting into it, where I'm aware of implementations that meed 
> tp make use of the "messaging" benefits of SCTP over UDP, the 
> less-than-standard path of TCP over some defacto standard port  has 
> been used.  Others may know of different implementations, but this is 
> based on subjective, but voluminous, input from implementations I've 
> seen at customer sites and discussions with colleagues at different 
> vendor enterprises.  Again, this is not an editorial on technical merit.
> Regards,
> Wayne
>
>     Cc: 'Marta Seda' <[email-masked]>, "Aitken, Paul"
>     <[email-masked]>, "[email-masked]'" <[email-masked]>
>     > In particular renaming identifiers would break any
>     implementations of RFC 7373 "Textual Representation of IP Flow
>     Information Export (IPFIX) Abstract Data Types".
>     >
>     > -Andrew
>     >
>     > 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 that may exist.
>     >
>     > 2) I think that it is reasonable that destinationIPAddress is
>     mandatory because network management systems should be able to
>     query the IP address to which 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7011-23section-2D10.1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=qunYBh7bv5ABGGsiP6-CjGVRw8xFMTnuuwuibkkNfBE&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__tools.ietf.org_html_rfc7011-2523section-2D10.1-26c-3DE-2C1-2Cr3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2D2Dh-5F-2DxePoq9GNzzaPGdYj0o-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=M0CgR7V3IlBqkpQDo2Brx-bewHWnHX_a5l7YChB32BI&e=>
>     >
>     > Best regards,
>     > Gerhard
>     >
>     >
>     >
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=Dml5zgSWzeUBwS1XyKmCG-y3bWePHxpzt3PCej4w_zw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_-26c-3DE-2C1-2C990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI-5FbfqIgW2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap-5FiznZ68ZknJgFbizFJolgU-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=whhuVEyPDEyPYoboty-rb0h_RQBoHKqNmiQoGwpLBlw&e=>
>     (draft-ietf-netmod-revised-datastores-09<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised-2Ddatastores_-26c-3DE-2C1-2CByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-2D78uXEs5xDZql2y-2D-2D4iDlmOUQ-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=gGNMKyVcGZrZBCbVl5XjjnnyJnRDUxt8jU3e24fcQBU&e=>)
>     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?
>     > 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”
>     >
>     >
>     (https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=SSYo4WM-xFfyPgrSh-cja-jQFQEucW4daULPdwg2zSI&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__urldefense.proofpoint.com_v2_url-253fu-253dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Dietf-2D2Dnetmod-2D2Drfc6087bis-2D2D15-2D23section-2D2D4.3.1-2526d-253dDwMD-2Dg-2526c-253dLFYZ-2Do9-5FHUMeMTSQicvjIg-2526r-253df8F8yzrqBTw6EPtR1rbibO-5FVFIc-2DcdnjIJ9he-5Fqu7xs-2526m-253d0c5ATjuT0-2D4IlDzLYM9h-5FRbPjCBQUv-5F6aExRL-5Ffl-2D5M-2526s-253dHhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA-5FiQBzQ-2526e-253d-26c-3DE-2C1-2C5Zsm8llhIef-5FjTZU2aAY2fj-5FKvmJs-2DzBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b-5FL6CTmk-5FVY1-2DTo7t8aTM7RBz2ayGhe3OrxbBk7-5FOy6I7gQSkKDC8Eig-2C-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=oj6Kq-4SRjuodk73yxC5K1cDKw8XP95L_H_m3ErUuQM&e=>).
>     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.
>     >
>     >   1.  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.
>     >
>     >      *   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.
>     >
>     >
>     >
>     >   1.
>     >
>     >      *
>     >      *   A choice statement to select what method to use seems
>     more appropriate than what is presently in RFC 6728.  For example
>     (use some shorthand)
>     >
>     >                                 However I can’t 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.
>     >
>     >
>     >
>     >   1.  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)?
>     >
>     Fax:   +49 421 200 3103        
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=cC8C3QfrkIEC1Vo-QLwKrh955-evz_Tr3MYoFDTmD1A&e=>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jan 2018 02:39:48 +0100

What makes you believe one cannot list a YANG 1.0 module in
ietf-yang-library?

If someone wants to work on a 'better' IPFIX module (or modules), the
best approach is to write one and to post it as an I-D. And for
writing a replacement module (or modules), it will be beneficial to
have implementation experience.

/js