On 15/07/2021 16:05, Amanda Baber wrote:
Hi Tom,
I agree that the extra fourth column needs to be removed from the document. I just wanted to make it clear that it's not there because it was attempting to add the column. It was there because they were mistakenly informed that there was a column.
(Apologies for top posting.)
Amanda
That is nice and clear. It seems that a new document is needed and,
perhaps, another update to the Shepherd writeup in Working Group Summary
which seems to be more about the IPFix registry in general and not about
the subregistry for element 46 where it implies (to me) that a fourth
column is still expected for the subregistry; you say, that is not now
expected which is fine with me so I shall shut up.
Tom Petch
Amanda
On 7/15/21, 5:19 AM, "tom petch" <daedulus@xxxxxxxxxxxxx> wrote:
On 15/07/2021 02:09, Amanda Baber wrote:
> Hi Tom,
>
> This was introduced by IANA, not the authors: we mistook his subregistry entries for Information Elements entries and told him to use those IE-specific fields.
>
> A few days ago, with expert approval, we changed the names of the "References" and "Requester" fields in the Information Elements registry to "Additional Information" and "Reference."
>
> We're not aware of any plans to rename or add IPFIX subregistry fields.
Color me confused.
In the I-D which is in Last Call, now updated to -07, IANA
Considerations seeks to update the subregistry for 46 with four columns
for four new entries. The subregistry only has three columns. Hence my
comment that this is (still) a nonsense.
The shepherd writeup says that
'Both IANA and IE doctors confirmed that IE46 registry will be fixed ..
and a IANA note therein 01/07 says the columns have been renamed.
But
- it is the IPFix registry that has been updated AFAICT not the IE46
subregistry
- Mohamed posted a note to the Last Call list 7jul saying that the
subregistry will be updated but I see no sign of that
- this I-D is asking for action to the IE46 subregistry which is
impossible with the current columns in the IE46 subregistry.
Something needs to change IMHO.
Tom Petch
> Best regards,
>
> Amanda Baber
> Lead IANA Services Specialist
>
> On 7/8/21, 2:59 AM, "last-call on behalf of tom petch" <last-call-bounces@xxxxxxxx on behalf of daedulus@xxxxxxxxxxxxx> wrote:
>
> On 07/07/2021 13:29, mohamed.boucadair@xxxxxxxxxx wrote:
> > Hi Tom,
> >
> > Can you please clarify why that section is "a nonsense"?
>
> Because three and four are different, four into three will not go.
>
> The IANA registry has three columns; this I-D specifies an update to the
> registry with four columns (with no instructions to IANA as to how to
> resolve this). This makes no sense to me, ie it is nonsense!
>
> The Shepherd writeup explains that there is a secret, invisible fourth
> column which explains the discrepancy but the Last Call is for the I-D,
> not the Shepherd writeup and without the Shepherd writeup, the I-D makes
> no sense:-)
>
> IANA Considerations are an opportunity to involve IANA in updating a
> registry and fixing errors not just in adding new entries to a flawed
> registry.
>
> Tom Petch
>
> > As indicated in the write-up, that section includes sufficient information to proceed with the IANA assignments. The I-D cites itself as the codpoints requester, while it cites the RFCs that define the related mechanisms as the authoritative references. Citing RFC7012 here is not useful.
> >
> > The I-D includes required information taking into account the discussion with the IE experts and IANA. Hence the additional column.
> >
> > Please note that it is not the job of this I-D to fix issues related to the target registry. It is thus out of scope to discuss changing pointers to 5102 to 7012. FYI, 7012 discusses why reference to 5102 is maintained in the registry.
> >
> > Thank you.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : last-call [mailto:last-call-bounces@xxxxxxxx] De la part de tom
> >> petch
> >> Envoyé : mercredi 7 juillet 2021 10:46
> >> À : last-call@xxxxxxxx
> >> Cc : draft-ietf-opsawg-ipfix-mpls-sr-label-type@xxxxxxxx
> >> Objet : Re: [Last-Call] Last Call: <draft-ietf-opsawg-ipfix-mpls-sr-
> >> label-type-06.txt> (Export of MPLS Segment Routing Label Type
> >> Information in IP Flow Information Export (IPFIX)) to Informational
> >> RFC
> >>
> >> The IANA Considerations in this I-D are a nonsense; the I-D should
> >> not be published.
> >>
> >> I commented on this on the OPSAWG list and the document shepherd
> >> essentially agreed with me that the IANA Considerations are rubbish
> >> and pointed me to the Shepherd write-up which describes how this has
> >> been discussed with IANA and with IPFIX experts (the registry is
> >> Expert
> >> Review) and an agreement has been reached as to what IANA should do
> >> instead of what is described in this I-D; this would address some
> >> but not all of my comments and would IMHO introduce a further error.
> >>
> >> So publishing this I-D would leave a trail of misinformation to
> >> confuse those that come after.
> >>
> >> My specific comments were
> >>
> >> "2) The existing registry, and indeed the instructions setting up
> >> thereof, specifies three columns, Value Description Reference This
> >> I-D adds a fourth column, Requester What happens to that column for
> >> existing entries?
> >>
> >> 3) The Reference column for the existing entries points to RFC5102,
> >> the January 2008 Information Model for IPFIX; that RFC is obsoleted
> >> by
> >> RFC7012 which is the reference which IANA gives for the registry as
> >> a whole (which seems a good choice). For the new four entries here,
> >> the Reference is specified to be the RFC that defines the protocol
> >> which sets the MPLS label, nothing to do with the IPFIX RFC and
> >> nothing to do with this I-D in Last Call. Not exactly wrong, but
> >> seems inconsistent.
> >> Perhaps replace 5102 with 7012, make the Reference column for the
> >> new four values this I-D and make this I-D provide the link back to
> >> the protocol RFC (which sections 1 and 2 probably do already) and
> >> eliminate the fourth column.
> >>
> >> I disagree with the Shepherd writeup where it renames the Reference
> >> column to be something else. Reference is something widely used and
> >> well understood. AFAICT the RFC that created the registry (RFC5102)
> >> does not specify the columns or format of the registry and so this
> >> is not technically an update to that RFC.
> >>
> >> Tom Petch
> >>
> >> On 06/07/2021 14:30, The IESG wrote:
> >>>
> >>> The IESG has received a request from the Operations and Management
> >>> Area Working Group WG (opsawg) to consider the following document:
> >> -
> >>> 'Export of MPLS Segment Routing Label Type Information in IP Flow
> >>> Information Export (IPFIX)'
> >>> <draft-ietf-opsawg-ipfix-mpls-sr-label-type-06.txt> as
> >>> Informational RFC
> >>>
> >>> The IESG plans to make a decision in the next few weeks, and
> >> solicits
> >>> final comments on this action. Please send substantive comments to
> >> the
> >>> last-call@xxxxxxxx mailing lists by 2021-07-20. Exceptionally,
> >>> comments may be sent to iesg@xxxxxxxx instead. In either case,
> >> please
> >>> retain the beginning of the Subject line to allow automated
> >> sorting.
> >>>
> >>> Abstract
> >>>
> >>>
> >>> This document introduces new IP Flow Information Export
> >> (IPFIX) code
> >>> points to identify which traffic is being forwarded based on
> >> which
> >>> MPLS control plane protocol used within a Segment Routing
> >> domain. In
> >>> particular, this document defines four code points for the
> >> IPFIX
> >>> mplsTopLabelType Information Element for IS-IS, OSPFv2,
> >> OSPFv3, and
> >>> BGP MPLS Segment Routing extensions.
> >>>
> >>>
> >>>
> >>>
> >>> The file can be obtained via
> >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-__;!!PtGJab4!rq_CA9yxayGz-6vpxiKYqJvJnGofukvyXGnUM5L-_-2ZbbsdUBLAwTLf8NsHxeKVb48NC87X$
> >> label
> >>> -type/
> >>>
> >>>
> >>>
> >>> No IPR declarations have been submitted directly on this I-D.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> IETF-Announce mailing list
> >>> IETF-Announce@xxxxxxxx
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!PtGJab4!rq_CA9yxayGz-6vpxiKYqJvJnGofukvyXGnUM5L-_-2ZbbsdUBLAwTLf8NsHxeKVb5DMKBVe$
> >>> .
> >>>
> >>
> >> --
> >> last-call mailing list
> >> last-call@xxxxxxxx
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!PtGJab4!rq_CA9yxayGz-6vpxiKYqJvJnGofukvyXGnUM5L-_-2ZbbsdUBLAwTLf8NsHxeKVb5qmXt7-$
> >
> > _________________________________________________________________________________________________________________________
> >
> > 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.
> >
> > .
> >
>
> --
> last-call mailing list
> last-call@xxxxxxxx
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!PtGJab4!rq_CA9yxayGz-6vpxiKYqJvJnGofukvyXGnUM5L-_-2ZbbsdUBLAwTLf8NsHxeKVb5qmXt7-$
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
