Hi Sandy, all, Just following up on this. Are we removing the following text from the Description field for 339 and 345?
For 339 informationElementDataType: "(previously the 'informationElementDataType' registry)" For 345 informationElementUnits: "(previously the 'informationElementDataType' registry)" "These types are registered in the [IANA IPFIX Information Element Units] subregistry." Please let us know if these removals are correct or if any other changes are required. Thanks, Sabrina On Mon Feb 17 13:30:39 2025, benoit.cla...@huawei.com wrote: > Hi Sandy, > > Your proposal works for me. > > Regards, Benoit > > > On 2/15/2025 12:54 AM, Sandy Ginoza wrote: > > Hi Paul, Authors, > > > > Thanks for checking in! > > > >> On Feb 10, 2025, at 1:54 PM, Aitken, Paul <pait...@ciena.com> wrote: > >> > >> 1. Has IANA updated the registries from the RFC-to-be? It looks like > >> updates from section 4 have already been applied, but the updates in > >> sections 5 and 6 have not. > > IANA has now completed the updates. > > > > > >> 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> > >>>> 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> > >>>>> 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]> > >>>>>> . > >>>>>> > >>>>>> 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 > >>>>>>> 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> > >>>>>>> > >>>>>>> Envoyé : jeudi 6 février 2025 10:45 > >>>>>>> À : BOUCADAIR Mohamed INNOV/NET > >>>>>>> <mohamed.boucad...@orange.com>; Sandy Ginoza > >>>>>>> <sgin...@staff.rfc-editor.org> > >>>>>>> > >>>>>>> Cc : RFC Editor > >>>>>>> <rfc-edi...@rfc-editor.org>; i...@iana.org; opsawg- > >>>>>>> a...@ietf.org; opsawg-cha...@ietf.org; thomas.g...@swisscom.com; > >>>>>>> Mahesh Jethanandani <mjethanand...@gmail.com>; > >>>>>>> auth48archive@rfc-editor.org; pait...@ciena.com; me > >>>>>>> <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 > >>>>>>> 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
