[OPSAWG] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01

[Benoit Claise <[e-mail]>]

Dear IPFIX doctors, (IANA),

We would like to get your feedback regarding the IANA section in 
draft-ietf-opsawg-ipfix-srv6-srh-01.
Especially, the two following information elements:
srhFlagsIPv6: 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.1
srhSegmentEndpointBehavior: 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.11

I went to the IANA table in Philly and we discussed those. Hence I 
copied IANA here.
In the currentdraft-ietf-opsawg-ipfix-srv6-srh-01 
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01> 
version, we created two IPFIX subregistries, which mimic existing 
Segment Routing registries.
The main reason is that we are in favor of having a self contained IPFIX 
IANA registry, which we can download as a cron job in the collector. We 
discussed such a project with Michelle Cotton in the past (I know that 
Michelle moved on). On top of that, it might be beneficial for the IPFIX 
experts to review any changes coming from a registry we mimic, just to 
see if there are no new inconsistencies from an IPFIX point of view.

However, Med, in cc., has a valid point that the current IPFIX IANA 
entries are inconsistencies already.
Ex: destinationTransportPort points to a different registry
Ex: tcpControlBit. See 
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-rfc7125-update/
So he advocated that we don't duplicate, with an IPFIX subregistry, 
information stemming from a different source. Pointing to the existing 
registry (ex: "Segment Routing Header Flags") + a RFC reference is 
sufficient for him. Solving the self-contained IPFIX registry issue 
would be a (too) huge job at this point in time.

This is what we currently have in the draft:

    5.1
    <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.1>.
    srhFlagsIPv6

        Name:  srhFlagsIPv6

        ElementID:  TBD1

        Description:  This Information Element identifies the 8-bit flags
           defined in the SRH.  Values for this Information Element are
           listed in the "IPFIX IPv6 SRH Flags" registry, see [IANA-IPFIX  <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#ref-IANA-IPFIX>].
           srhFlagsIPv6 values must not be directly added to this "IPFIX IPv6
           SRH Flags" registry.  They must instead be added to the "Segment
           Routing Header Flags" registry.  Both the "IPFIX IPv6 SRH Flags"
           and the "Segment Routing Header Flags" registries must be kept in
           synch.  Initial values in the registry are defined by the table
           below.

           +--------+-------------------+--------------------------------------+
           | Value  |    Description    |              Reference               |
           +--------+-------------------+--------------------------------------+
           | 0-1    | Unassigned        |                                      |
           +--------+-------------------+--------------------------------------+
           | 2      | O-flag            |  [RFC-ietf-6man-spring-srv6-oam-13]  |
           +--------+-------------------+--------------------------------------+
           | 3-7    | Unassigned        |                                      |
           +--------+-------------------+--------------------------------------+

                        Table 2: "IPFIX IPv6 SRH Flags" registry


        Note to IANA:  Add a note to the "IPFIX SRV6 Endpoint Behavior"
           registry so that new values are echoed in the new "IPFIX SRv6
           EndPoint Behavior

        Abstract Data Type:  unsigned8

        Data Type Semantics:  flags

        Reference:  [RFC-to-be],RFC8754  <https://datatracker.ietf.org/doc/html/rfc8754>

This is what Med proposes:

    5.1
    <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.1>.
    srhFlagsIPv6

        Name:  srhFlagsIPv6

        ElementID:  TBD1

        Description:  This IE identifies the 8-bit flags defined in the SRH.
              Assigned flags and their meanings are provided in the "Segment Routing
              Header Flags" registry.

        Abstract Data Type:  unsigned8

        Data Type Semantics:  flags

        Reference:  [RFC-to-be],RFC8754  <https://datatracker.ietf.org/doc/html/rfc8754>


We basically agree that a registry lookup is required for the IPFIX 
Collector.
An IPFIX Exporter will export what he sees, regardless of the semantic 
or an IANA registry. The IPFIX Collector will report a potential problem 
if the observed value is not in the IANA registry (bug, IANA entry 
hijacked, another convention => if value not observed, I'll send an 
error code instead, etc)

Bottom line: we have two different ways to model the srhFlagsIPv6 and 
srhSegmentEndpointBehavior in IANA, with or without an IPFIX subregistry.
Can you share your views on the best way to register those IEs.

Thanks and regards, Benoit