Re: [OPSAWG] [IANA #1240167] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01

[[e-mail]]

Hi Amanda, all, 

One comment on this point: 

> When IANA links to this registry, will the link have to point to,
> e.g., https://www.iana.org/assignments/segment-routing/segment-
> routing#the-specific-registry, or would it be sufficient to point
> to https://www.iana.org/assignments/segment-routing (the registry
> group, rather than the specific registry within it)?

As far as the label of the sub-registry is provided, it is sufficient to point to the registry group. For this draft, this would be:
* "SRv6 Endpoint Behaviors" sub-registry under https://www.iana.org/assignments/segment-routing 
* "Segment Routing Header Flags" sub-registry under https://www.iana.org/assignments/ipv6-parameters/ 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Amanda Baber via RT <[e-mail]>
> Envoyé : vendredi 30 septembre 2022 04:59
> À : [e-mail]
> Cc : [e-mail]; BOUCADAIR Mohamed INNOV/NET
> <[e-mail]>; [e-mail]
> Objet : [IANA #1240167] IANA question regarding draft-ietf-opsawg-
> ipfix-srv6-srh-01
> 
> Hi Benoit, all,
> 
> > 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
> 
> We can keep separate registries in sync (although we don't
> currently have automation to ensure this), but is the intention
> for the IPFIX IPv6 SRH Flags and IPFIX SRV6 Endpoint Behavior
> registries to be contained within each IPFIX IE registration's
> Description field?
> 
> In 2020, with IE Doctor approval, all IPFIX IE Description field
> tables that constituted sub-registries were replaced with links to
> separate sub-registries located outside of the IPFIX Information
> Elements registry. You can see the list of sub-registries under
> the heading "Registries included below":
> 
> https://www.iana.org/assignments/ipfix
> 
> > 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).
> 
> I'm afraid we don't have any of Michelle's notes on this topic.
> What will you need IANA to do? We may need to put you in touch
> with IANA's technical director. In the future, the registries will
> be moved from an XML-based to a database-based registry system.
> 
> > 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>
> 
> When IANA links to this registry, will the link have to point to,
> e.g., https://www.iana.org/assignments/segment-routing/segment-
> routing#the-specific-registry, or would it be sufficient to point
> to https://www.iana.org/assignments/segment-routing (the registry
> group, rather than the specific registry within it)?
> 
> > 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
> 
> thanks,
> 
> Amanda Baber
> IANA Operations Manager


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.