I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document adds new information elements for transmitting segment routing 
over IPv6 related information over IPFIX. 

The security considerations section claims:

   There exists no significant extra security considerations regarding
   allocation of these new IPFIX IEs compared to [RFC7012].

The first question is that if there is no significant extra security 
considerations, so what non-significant extra security considerations
there is?

On the other hand the 7012 security considerations say:

   The IPFIX information model itself does not directly introduce
   security issues.  Rather, it defines a set of attributes that may,
   for privacy or business issues, be considered sensitive information.

   For example, exporting values of header fields may make attacks
   possible for the receiver of this information; this would otherwise
   only be possible for direct observers of the reported Flows along the
   data path.

   The underlying protocol used to exchange the information described
   here must therefore apply appropriate procedures to guarantee the
   integrity and confidentiality of the exported information.  These
   protocols are defined in separate documents, specifically the IPFIX
   protocol document [RFC7011].

Meaning that this document should explain whether any of the attributes
it exports have any privacy concerns, or whether it exports header values
which attacker might not otherwise have.

So the security considerations should mention whether any of those 
information elements it export has any privacy concerns or not 
(and if so, add note that the protocol transporting these should
provide suitable security).

Also this document allows two ways of exporting same information
(srhSegmentIpv6BasicList and srhSegmentIPv6ListSection). This always
causes a question what can someone do if it provides both but the values
are different? Can it cause that one data collector parses one list
and another data collector uses the other list, and can it then cause
differences in the collectors behavior based on which one they used?

Are both of them allowed to be used at the same time? The operational
considerations say that:

   It is not expected that an exporter would support both
   srhSegmentIPv6BasicList and srhSegmentIPv6ListSection at the same
   time.

But it is not explained what happens if both are used at the same time, 
and what happens if both are used but the contents is different?