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://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-
label
-type/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
_________________________________________________________________________________________________________________________
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://www.ietf.org/mailman/listinfo/last-call
