This works for me, as "(previously the "whatever" registry)" doesn't make sense
in the registry.
However removing this makes 6.12.2 a bit clumsy to read as this text is
repeated:
Description: A description of the abstract data type of an IPFIX
information element. These are taken from the abstract data types
defined in Section 3.1 of the IPFIX Information Model [RFC5102];
see that section for more information on the types described in
the "IPFIX Information Element Data Types" registry. These types are
registered in the "IPFIX Information Element Data Types" registry.
While comparing 6.12.2 and 6.14.2, I noticed that this text should have been
removed from #345 by 6.14.2, but is still in the registry:
These types are registered in the [IANA IPFIX Information Element
Units<https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-units>]
subregistry.
P.
________________________________
From: Sandy Ginoza
<sgin...@staff.rfc-editor.org><mailto:sgin...@staff.rfc-editor.org>
Sent: 14 February 2025 23:54
> 2. In 6.12.2., is this bracket useful? "(previously the
> "informationElementDataType" registry)". Same in 6.14.2: "(previously the
> "informationElementsUnits" registry)". The previous name is really only
> relevant if the reader has an old pointer using that name.
I had a tough time following the OLD/NEW text without understanding the
registry names. I find it beneficial to clearly document the change for the
reader, though I can see how it may not be helpful for the registry text itself.
Perhaps we could add a note to Section 6.12. informationElementDataType?
Original:
6.12. informationElementDataType
Perhaps:
6.12. informationElementDataType
Note that the "informationElementDataType” registry is renamed as the "IPFIX
Information Element Data Types” registry.
Then we would remove the following from the NEW text:
(previously the "informationElementDataType" registry)
Thanks,
RFC Editor/sg
>
>
> P.
>
> On 10/02/25 18:28, Sandy Ginoza wrote:
>> Hi IANA,
>>
>> We have updated the NEW text to refer to registry names with a [URL] to the
>> registry group per our earlier discussion. Please review and update the
>> related registries and let us know if you have any questions.
>>
>>
>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710-diff.html__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8XmTHugKQ$
>> [rfc-editor[.]org]
>>
>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710-rfcdiff.html__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8V50RN3BA$
>> [rfc-editor[.]org] (side-by-side view)
>>
>> Thank you,
>> RFC Editor/sg
>>
>>
>>
>>> On Feb 6, 2025, at 9:53 AM, Sandy Ginoza
>>> <sgin...@staff.rfc-editor.org><mailto:sgin...@staff.rfc-editor.org>
>>> wrote:
>>>
>>> Thanks for your quick reply, Benoit. Your approval has been noted and we
>>> will continue with publication shortly.
>>>
>>> Thanks,
>>> RFC Editor/sg
>>>
>>>
>>>> On Feb 6, 2025, at 9:44 AM, Benoit Claise
>>>> <benoit.cla...@huawei.com><mailto:benoit.cla...@huawei.com>
>>>> wrote:
>>>>
>>>> Approved.
>>>>
>>>> Thanks, Benoit
>>>>
>>>>
>>>> On 2/6/2025 6:32 PM, Sandy Ginoza wrote:
>>>>
>>>>> Hi Med, Benoit,
>>>>>
>>>>> Med, thanks for catching those mistaken updates in the OLD text - they
>>>>> have been reverted. With this update, we believe you approve the RFC for
>>>>> publication, so we have noted your approval on the AUTH48 page
>>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9710__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8XELp8zlQ$
>>>>>
>>>>> [rfc-editor[.]org]><https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9710__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8XELp8zlQ$[rfc-editor[.]org]>
>>>>> .
>>>>>
>>>>> Related to “subregistry” - we have all instances of “sub” in the NEW text.
>>>>>
>>>>> Benoit, please review and let us know if any additional updates are
>>>>> needed or if you approve the RFC for publication.
>>>>>
>>>>> The current files are available here:
>>>>>
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710.xml__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8XfXZvLMw$
>>>>> [rfc-editor[.]org]
>>>>>
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710.txt__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8XamMk7xA$
>>>>> [rfc-editor[.]org]
>>>>>
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710.pdf__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8VX7Jehxg$
>>>>> [rfc-editor[.]org]
>>>>>
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710.html__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8VXbGZwhw$
>>>>> [rfc-editor[.]org]
>>>>>
>>>>>
>>>>> Diffs showing most recent updates only:
>>>>>
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710-lastdiff.html__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8WOWfhmrw$
>>>>> [rfc-editor[.]org]
>>>>>
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710-lastrfcdiff.html__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8VmaAOzbw$
>>>>> [rfc-editor[.]org] (side by side)
>>>>>
>>>>> AUTH48 diffs:
>>>>>
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710-auth48diff.html__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8W82u381g$
>>>>> [rfc-editor[.]org]
>>>>>
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710-auth48rfcdiff.html__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8UQq_-RHA$
>>>>> [rfc-editor[.]org] (side by side)
>>>>>
>>>>> Comprehensive diffs:
>>>>>
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710-diff.html__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8XmTHugKQ$
>>>>> [rfc-editor[.]org]
>>>>>
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710-rfcdiff.html__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8V50RN3BA$
>>>>> [rfc-editor[.]org] (side by side)
>>>>>
>>>>> Thank you,
>>>>> RFC Editor/sg
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Feb 6, 2025, at 2:09 AM,
>>>>>> mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
>>>>>> wrote:
>>>>>>
>>>>>> Re-,
>>>>>> The except below is about 6.12.2, not 6.12.1 ;-)
>>>>>> It is better to use the full diff to see the change I was referring to:
>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9710-diff.html__;!!OSsGDw!Oa-ZD3kUOS8_Xhy-5sbrnTfX6gvL0hxBt9ygEHUXgq2uE6mNnUZTJx2AyZKPSypkZI8ZOzHpeD-NJ8XmTHugKQ$
>>>>>> [rfc-editor[.]org].
>>>>>> For subregistry/registry comment, I thought we are OK given that this
>>>>>> was prefixed with “previously”.
>>>>>> That’s said I agree with you that the use in the registry should be
>>>>>> consistent. There shouldn’t be any occurrence of “subregistry” when the
>>>>>> changes in RFC9710 are implemented.
>>>>>> Cheers,
>>>>>> Med
>>>>>> De : Benoit Claise
>>>>>> <benoit.claise=40huawei....@dmarc.ietf.org><mailto:benoit.claise=40huawei....@dmarc.ietf.org>
>>>>>>
>>>>>> Envoyé : jeudi 6 février 2025 10:45
>>>>>> À : BOUCADAIR Mohamed INNOV/NET
>>>>>> <mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>;
>>>>>> Sandy Ginoza
>>>>>> <sgin...@staff.rfc-editor.org><mailto:sgin...@staff.rfc-editor.org>
>>>>>>
>>>>>> Cc : RFC Editor
>>>>>> <rfc-edi...@rfc-editor.org><mailto:rfc-edi...@rfc-editor.org>;
>>>>>> i...@iana.org<mailto:i...@iana.org>;
>>>>>> opsawg-...@ietf.org<mailto:opsawg-...@ietf.org>;
>>>>>> opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>;
>>>>>> thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>; Mahesh
>>>>>> Jethanandani <mjethanand...@gmail.com><mailto:mjethanand...@gmail.com>;
>>>>>> auth48archive@rfc-editor.org<mailto:auth48archive@rfc-editor.org>;
>>>>>> pait...@ciena.com<mailto:pait...@ciena.com>; me
>>>>>> <benoit.cla...@huawei.com><mailto:benoit.cla...@huawei.com>
>>>>>>
>>>>>> Objet : Re: AUTH48: RFC-to-be 9710 <draft-ietf-opsawg-ipfix-fixes-12>
>>>>>> for your review
>>>>>>
>>>>>> Dear all, Med,
>>>>>>
>>>>>> On 2/6/2025 8:03 AM,
>>>>>> mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
>>>>>> wrote:
>>>>>> Hi Sandy, all,
>>>>>> Thank you for taking care of this.
>>>>>> ACK to remove the note for item 9.
>>>>>> The latest changes look great, except the ones made to "7.3.1 ": these
>>>>>> should be reverted back as that text echoes what was changed. BTW, a
>>>>>> similar revert back is needed to Section 6.12.1.
>>>>>> Which change(s) exactly in 6.12.1?
>>>>>> <image001.png>
>>>>>>
>>>>>> In this document, there is a consistent change from subregistry to
>>>>>> registry, so I guess we don't want to go back to this.
>>>>>> Btw, IANA, I still see a subregistry instance in the NEW text in section
>>>>>> 6.14.2. That's mistake, right?
>>>>>>
>>>>>> Regards, Benoit
>>>>>>
>>>>>> Assuming these changes are implemented, I approve the publication of
>>>>>> the document.
>>>>>> Cheers,
>>>>>> Med
>>>>>> ___________________________________________________________________________________________________________
>>>>>> _
>>>>>> 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.
>>>>>>
>>>>>>
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
