Dear Paul,
Thanks for the quick reply. My understanding from https://datatracker.ietf.org/doc/html/rfc7011#section-6.1.1 is MUST be encoded using the default canonical format in network byte order Looking at https://www.rfc-editor.org/rfc/rfc7133.html#section-5.2 as example, which is the same case, a 3-bit value in a unsigned8 data type, I would expect that it would be encoded in network byte order (big-endian). So I tend to remove "The values are encoded in the first 3 bits of the IE" since it is redundant or if required replace with "The values are encoded in the first 3 bits of the IE as defined in section 6.1.1 of RFC 7011". What do you think? Regarding the registry. In the CCAMP interim Scott mentioned to clarify this with with ITU-T and you wrote that you have asked IANA for their advice. Did you get any response? I would expect that either Scott clarifies himself or gives me a pointer to whom to follow up which is my job as author. Or perhaps IANA already knows how to deal with ITU-T registries which would make it even easier. Best wishes Thomas -----Original Message----- From: Aitken, Paul <[email protected]> Sent: Friday, May 16, 2025 1:07 PM To: Graf Thomas, INI-NET-VNC-E2E <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: draft-netana-opsawg-ipfix-gpon-gem-00 Be aware: This is an external email. Thomas, "The values are encoded in the first 3 bits of the IE." Which are the "first" bits? Is it big-endian, little-endian, network bit order, right-to-left, or left-to-right? "The authors would like to thank Paul Aitken for their review" Thanks! But consider writing this in a non-pronoun way: "... for reviewing". Are you asking me / Scott to reach out to ITU-T? I would have expected the document authors to do that. P. ________________________________________ From: [email protected]<mailto:[email protected]> Sent: Friday, May 16, 2025 09:30 To: Aitken, Paul; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [**EXTERNAL**] RE: draft-netana-opsawg-ipfix-gpon-gem-00 Dear Paul and Scott, I merged the input from Paul on which bits should be encoded for the gponGemPti IE. https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fdiff%3Fdoc_1%3Ddraft-netana-opsawg-ipfix-gpon-gem-00%26url_2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fnetwork-analytics%2Fdraft-netana-opsawg-ipfix-gpon-gem%2Frefs%2Fheads%2Fmain%2Fdraft-netana-opsawg-ipfix-gpon-gem-01.txt&data=05%7C02%7CThomas.Graf%40swisscom.com%7C8f585d77f34343b1977408dd9469d1a9%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638829904414593909%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=owfQ0KIXVNRAN5PGMPcAdtzB4QoZVfuknZkCjfO5mgc%3D&reserved=0<https://author-tools.ietf.org/diff?doc_1=draft-netana-opsawg-ipfix-gpon-gem-00&url_2=https://raw.githubusercontent.com/network-analytics/draft-netana-opsawg-ipfix-gpon-gem/refs/heads/main/draft-netana-opsawg-ipfix-gpon-gem-01.txt> I understood that both of you wanted to reach out to the ITU-T wherever there is an existing GEM PTI (Section 8.3.1 G.984.3) registry where an IPFIX subregistry (https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fipfix%2Fipfix.xhtml&data=05%7C02%7CThomas.Graf%40swisscom.com%7C8f585d77f34343b1977408dd9469d1a9%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638829904414626718%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ygK1HajKb3%2B3K%2BnF0muZ1DiaeHpbqx9mTM9A4kMvlkg%3D&reserved=0<https://www.iana.org/assignments/ipfix/ipfix.xhtml>) could refer to. We like at the IPFIX IANA managed registry to avoid duplication wherever possible since later they will be hard to manage. The ITU-T registry should be machine readable since there are IPFIX data collection implementations (https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fopsawg%2FcgxHtKqO9Yks7wSFXr5HGDI0yUE%2F&data=05%7C02%7CThomas.Graf%40swisscom.com%7C8f585d77f34343b1977408dd9469d1a9%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638829904414642140%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CPJomVvCoXDpnIYvf5EX5gKP%2B5TRAT4sg7QtdEfvunQ%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/opsawg/cgxHtKqO9Yks7wSFXr5HGDI0yUE/>) which obtain the IPFIX definitions from the IANA registry automatically. Let me know wherever you had any feedback and wherever I can help in anyway like establishing a liaison between ITU-T and OPSAWG/CCAMP. Best wishes Thomas -----Original Message----- From: Graf Thomas, INI-NET-VNC-E2E Sent: Thursday, April 10, 2025 12:45 PM To: Aitken, Paul <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: draft-netana-opsawg-ipfix-gpon-gem-00 Dear Paul, That's very much appreciated. srhFlagsIPv6 is a good example which refers to https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fipv6-parameters%2Fipv6-parameters.xhtml%23segment-routing-header-flags&data=05%7C02%7CThomas.Graf%40swisscom.com%7C8f585d77f34343b1977408dd9469d1a9%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638829904414656127%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QPBHLclyzsVs8mAhjP8yBi9pRwQy9wjNlTn3w47Gwd0%3D&reserved=0<https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags>. If that would not be possible we would need to re-create the registry as in dataLinkFrameType and refer to the ITU-T document. The challenge I see is that all ITU-T documents are listed here: https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.itu.int%2Frec%2FT-REC-G%2Fen&data=05%7C02%7CThomas.Graf%40swisscom.com%7C8f585d77f34343b1977408dd9469d1a9%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638829904414667607%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MAemvqeua6qRiu8wLKePVZaQV0EGhi4bkC3YMvGd6j0%3D&reserved=0<https://www.itu.int/rec/T-REC-G/en> and for G.984.3 here https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.itu.int%2Frec%2FT-REC-G%2Frecommendation.asp%3Flang%3Den%26parent%3DT-REC-G.984.3&data=05%7C02%7CThomas.Graf%40swisscom.com%7C8f585d77f34343b1977408dd9469d1a9%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638829904414677519%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6gMMsqvTPFrvLQ426Tj%2F%2B2t2NDBtmbozPY3G9jYYRQM%3D&reserved=0<https://www.itu.int/rec/T-REC-G/recommendation.asp?lang=en&parent=T-REC-G.984.3>, but I wasn't able to find a registry. I will raise this today at the CCAMP interim and feedback when I have infos. Best wishes Thomas -----Original Message----- From: Aitken, Paul <[email protected]<mailto:[email protected]>> Sent: Thursday, April 10, 2025 10:43 AM To: Graf Thomas, INI-NET-VNC-E2E <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: draft-netana-opsawg-ipfix-gpon-gem-00 Be aware: This is an external email. Thomas, I agree that it's good to avoid duplicate registries. The IE definition could point directly to the corresponding ITU definitions. Even better, we could create a new IPFIX sub-registry which points to the ITU definition. In either case the definition should clearly say whether it's intended to only use the ITU definition at the the time of publication, or to follow all future updates. eg, if one of the Reserved values is defined in future. This could be the first time for such an IPFIX definition (where the full details are external to the registry), so I've asked IANA for their advice. P. On 09/04/25 06:16, [email protected]<mailto:[email protected]> wrote: > Dear Paul, > > Thanks for the review. Well spotted. I will consolidate the terminology in > section 2 once the document is mature and complete. > > I will extend the description in both IE's describing that the first 3 resp. > 12 bits are being used. > > Section 8.3.1 of > https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.itu.int%2Frec%2Fdologin_pub.asp%3Flang%3De%26id%3DT-REC-G.984.3-201401-I!!PDF-E%26type%3Ditems&data=05%7C02%7CThomas.Graf%40swisscom.com%7C8f585d77f34343b1977408dd9469d1a9%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638829904414688176%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FOZWRdB3hLeJN8TSC0VGbVNLhBobiJHKOPcGlDXO%2FbE%3D&reserved=0<https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.984.3-201401-I!!PDF-E&type=items> > defines the PTI registry. I like to avoid that we are replicating this in > IPFIX so that we have to maintain two registries. Would it be ok if I > describe under Additional Information where the registry is? What is your > recommendation? > > Best wishes > Thomas > > -----Original Message----- > From: Aitken, Paul <[email protected]<mailto:[email protected]>> > Sent: Tuesday, April 8, 2025 9:14 PM > To: > [email protected]<mailto:[email protected]> > Subject: draft-netana-opsawg-ipfix-gpon-gem-00 > > > Be aware: This is an external email. > > > > In section 2 the terminology can be reduced as many of those terms are not > used elsewhere in the document. > > In section 5.1.1. please describe how the 3 bits are encoded into the > unsigned8: which of the 8 bits are used, and what is the ordering? > > Likewise in section 5.1.2. please describe how the 12 bits are encoded into > the unsigned16. > > Thanks, > P.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
