Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion

[Benoit Claise <[e-mail]>]

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)
>     Leaf identifiers are camel case (e.g., destinationAddress instead
>     of destination-address).  Are there any ongoing efforts to update
>     RFC 6728 to meet the latest best practices?
>
Not as far as I know.

Regards, Benoit
>
> 1.
>
>    Identifiers SHOULD follow a consistent naming pattern throughout the
>
>    module.  Only lower-case letters, numbers, and dashes SHOULD be used
>
>    in identifier names.  Upper-case characters and the underscore
>
>    character MAY be used if the identifier represents a well-known value
>
>    that uses these characters.
>
>    Identifiers SHOULD include complete words and/or well-known acronyms
>
>    or abbreviations.  Child nodes within a container or list SHOULD NOT
>
>    replicate the parent identifier. YANG identifiers are hierarchical
>
>    and are only meant to be unique within the the set of sibling nodes
>
>    defined in the same module namespace.
>
>    It is permissible to use common identifiers such as "name" or "id" in
>
>    data definition statements, especially if these data nodes share a
>
>    common data type.
>
>    Identifiers SHOULD NOT carry any special semantics that identify data
>
>    modelling properties.  Only YANG statements and YANG extension
>
>    statements are designed to convey machine readable data modelling
>
>    properties.  For example, naming an object "config" or "state" does
>
>    not change whether it is configuration data or state data.  Only
>
>    defined YANG statements or YANG extension statements can be used to
>
>    assign semantics in a machine readable format in YANG.
>
>  2. I generated the RFC 6728 yang tree (see attached).  The tcp and
>     udp exporting processes support a destinationIPAddress (line 400,
>     455) which is mandatory. The type is inet:ip-address.
>      1. A collector may be doing load balancing. Rather than managing
>         ip-addresses, the collector may be using DNS (an exporter
>         could resolve from the domain name where the collector is
>         located).
>      2. The collector address may be learnt via other methods (e.g.,
>         through DHCP options)
>      3. A choice statement to select what method to use seems more
>         appropriate than what is presently in RFC 6728.  For example
>         (use some shorthand)
>
> choice destination-method{
>
> case destination-address{
>
> leaf destination-address// rw with type inet:host
>
>                 }
>
> case dhcp-acquired-address{
>
> container dcp-acquired-address{
>
> leaf destination-ip-address inet-address //ro
>
>                 }
>
> }
>
>                                 However I 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?
>
>  3. RFC 6728 mandates SCTP transport.  I understand the logic behind
>     this (IETF prefers use of SCTP).  There are situations where sctp
>     is unnecessary and not supported (e.g., point to point
>     connection).  During netconf negotiations you can announce your
>     feature set (currently sctptransport is not a feature).  Is there
>     ongoing work in updating RFC 6728 to include sctptransport as a
>     feature (so that the device can announce whether or not it
>     supports sctptransport)?
>
> Regards
>
> Marta Seda
>
>
>
> _______________________________________________
> IPFIX mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipfix