[manet] IANA #1448940 MANET Registration request from 3GPP (manet-parameters)
"Dean, Justin CIV USN NRL WASHINGTON DC \(USA\)" <[email protected]> Mon, 4 May 2026 16:51:54 +0000
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <PH1P111MB139141C84B714A880CE505D7CE31A@PH1P111MB1391.NAMP111.PROD.OUTLOOK.COM> |
IANA has gotten a request from the 3GPP consortium for two RFC5444 allocations, a messaging type tlv value, which would create a message type specific TLV registry, and a message type specific TLV allocation from the newly created registry. I've included the specification from 3GPP that would be using these allocations along with my review. Input from the WG is requested. RFC5444 says allocations SHOULD have accompanying RFCs (not a MUST). I currently lean "no", for reasons outlined below, but I don't think it would be awful to allocate them either as adoption (even flawed adoption) is a positive for MANET. Justin Dean 3GPP Specification (24.554 v19.5.0): https://usg01.safelinks.protection.office365.us/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F24_series%2F24.554%2F24554-j50.zip&data=05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7Cc0ed6c8da5844e09aa0208de90203664%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C639106665974335314%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=IBPo%2FYEuWb5DSfyCH3XLq3ZPe2gTEGraPMWw2H3MZr4%3D&reserved=0 (8c.2.2.2, 10.8.2, 11.8.1) My review sans input from WG. -----Original Message----- From: Dean, Justin CIV USN NRL WASHINGTON DC (USA) Sent: Monday, April 13, 2026 2:00 PM To: [email protected] Subject: RE: [Non-DoD Source] [IANA #1448940] RE: MANET Registration from 3GPP (manet-parameters) 10.8.1 Should explicitly define the message type name. 5G_PROSE_MANET message (multi-hop, relay?) Proposed change: This document defines a new MANET message Type 5G_PROSE_MANET(3) and a message specific TLV block type 5G_PROSE_MANET_TLV(128). This clause defines a MANET message Type,5G_PROSE_MANET(3), based on the packet and message format of MANET specified in IETF RFC 5444.... 10.8.2.1 change 240 to 3 as indicated in prior email and remove the "NOTE". It's unclear to me where the TLV-E format is specified. It's listed as the format of the TLV block but I can't find where that is defined. It's used in other places throughout the document but I don't see any definition of it. 11.8 appears to be the definition of the TLV-E for the TLV block but I'm doing a little bit of guessing here. Proposed change: The multi-hop UE-to-UE discovery info parameter follows the message TLV format defined in IETF RFC 5444 [59]. This message TLV, type 5G_PROSE_MANET_TLV(128), is to be attached to a MANET message of type 5G_PROSE_MANET(3). The multi-hop UE-to-UE discovery info parameter has a minimum length of 14 octets and a maximum length of 65539 octets. Note: I'm okay with the format as defined BUT it really doesn't follow the spirit of using the messaging format to it's fullest potential. The address block field and address block TLVs if defined and used correctly would both add flexibility AND reduce overhead. That being said nothing is precluding further defining these usages. This should be made explicit in 10.8.1 and it sort of was but not cleanly. I propose adding to 10.8.1 "This document does not define the meaning or usage of any subtypes, attached address blocks or address block TLVs contained in this message. Any undefined TLVs, address blocks or address block tlvs should be ignored when processing. Messages with attached subtypes shall be fully ignored. Future specifications may define their usage while using the 5G_PROSE_MANET message type with the understanding that implementations of this specification version will ignore that content." With these changes I'm okay with approval though future updates and assignments should work harder to follow the spirit of RFC 8245 which I am ignoring a fair amount in my approval here. Justin Dean -----Original Message----- From: David Dong via RT <[email protected]> Sent: Friday, April 10, 2026 12:36 PM Cc: Dean, Justin CIV USN NRL WASHINGTON DC (USA) <[email protected]> Subject: [Non-DoD Source] [IANA #1448940] RE: MANET Registration from 3GPP (manet-parameters) Hi Justin, Following up on this; the 3GPP has recently updated their specification (thread with them copied below as well). Could you review their updated request? Specification (24.554 v19.5.0): https://usg01.safelinks.protection.office365.us/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F24_series%2F24.554%2F24554-j50.zip&data=05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7C7161aa794c124b12b80508de971f9426%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C639114359370424517%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=xcbKzZLhY2GsH1wJ61u%2FlHBBKuvIHSJDFk1mLKzeBE8%3D&reserved=0 (8c.2.2.2, 10.8.2, 11.8.1) It looks like to me in Message Types registry: 3GPP is now using 240 in the 224-255 Reserved for Experimental Use range and in Message TLV Types registry: 3GPP is now using 128 in the 128-223 Expert Review Reserved for Message Type Specific Message TLVs range. The IESG has asked us to request that reviews be returned within two weeks, which in this case would make the due date April 15th. Thank you. Best regards, David Dong IANA Services Sr. Specialist On Wed Apr 01 18:49:50 2026, david.dong wrote: > Hi Justin, > > Picking back up this thread from last December, the 3GPP has recently > updated their specification (thread with them copied below as well). > > Could you review their updated request? > > Specification (24.554 v19.5.0): > https://usg01.safelinks.protection.office365.us/?url=https%3A%2F%2Fwww > .3gpp.org%2Fftp%2FSpecs%2Farchive%2F24_series%2F24.554%2F24554-j50.zip > &data=05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7C7161aa794c124b12b8050 > 8de971f9426%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C6391143593704 > 46802%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C& > sdata=pcDaevb9l3vnUOdRCU1O7h57%2BOXqILXRh7CfDm%2Fkruo%3D&reserved=0 > (8c.2.2.2, 10.8.2, 11.8.1) > > It looks like to me in Message Types registry: > > 3GPP is now using 240 in the 224-255 Reserved for Experimental Use > range > > and in Message TLV Types registry: > > 3GPP is now using 128 in the 128-223 Expert Review Reserved for > Message Type Specific Message TLVs range. > > The IESG has asked us to request that reviews be returned within two > weeks, which in this case would make the due date April 15th. > > Thank you. > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Fri Dec 12 20:09:14 2025, [email protected] wrote: > > So I have way more questions than answers at this point. Regarding > > the default question of should they get an IANA allocation? If I am > > forced to give an answer. No. They seem to be using RFC5444 as a > > header but then roll their own internal message format (verify this > > is the case, 75% certain it is). > > The > > internal messaging format ignores recommendations and design > > philosophies listed in both RFC5444 (packetbb) and RFC 8245 (Rules > > for designing protocols using 5444). The document also does not > > appear to be an RFC but a 3GPP technical specification. In the IANA > > section of 5444 states: > > > > o The intention is that all registrations will be accompanied by a > > > published RFC. > > > > o In order to allow for registration prior to the RFC being > > approved > > > for publication, the Designated Expert can approve the > > > registration once it seems clear that an RFC is expected to be > > > published. > > > > > > They also define message TLVs for their message which again just > > rolls it's own message format internally. I am okay with this > > design, it's not great but it doesn't on the surface break anything. > > If their design truly is. > > > > 3GPP TS message is a manet packet formatted based on RFC5444 where > > that packet > > is: > > <packet> := <pkt-header><message> > > <message> := <msg-header><tlv-block> (they omit address blocks but > > say they use the same mechanism as NHDP and OLSR so?) <msg-header> > > := <msg-type=3GPPVAL><msg-flags><msg-addr-length><msg- > > size> > > <tlv-block> := <tlv-type=3GPP MULTI-HOP UE-TO-UE DISCOVERY > > INFOVAL> <tlv-flags> > > <length><value> > > <value> := <3GPP specific format> > > > > If that is the design then it's fine. Security TLVs won't work as > > intended > > as their value field changes on a hop by hop basis and the Security > > TLV design relies upon those values being immutable once sent by a > > sender (If I am wrong and they are not changed hop-by-hop than that > > will work just fine). > > > > If the design is <packet> = <pkt-header><message> where <message> is > > their own rolled thing (I think it is) then it's broken and parsers > > built on > > RFC5444 > > won't be able to process it. > > > > My other question is WHY they would like an IANA assignment. If they > > are designing something that can be reused then great but I'm not > > seeing that. If they aren't using the IANA protocol id and or > > multicast address then they can just pick whatever number they want > > and if they wanted to play nice they could select any of the 224-255 > > message type range that is reserved for experimental use. > > > > IF IANA and the MANET working group really wants to have this > > approved I could be convinced it would be okay IF: > > Their messages can be parsed by a generic RFC5444 parser without > > error. > > The message assignment name is generalized in nature. Something > > like “GENERALIZED PROTOCOL TYPE". (currently the only assigned types > > are HELLO and Topology Control) This message type assignment would > > create two separate registration tables, one for > > Message-Type-specific message TLV (val 128-223) and one for > > Message-Type-specific-address-block-TLV (val 128-223). > > Their message TLV type request would come from this newly created > > table, so TLV val of 128 with message type GENERALIZED PROTOCOL > > TYPE". > > This approach would allow other designers to use RFC5444 in the same > > “GENERALIZED PROTOCOL TYPE" way without eating up a whole bunch of > > message types, (e.g. consortum A could request TLV 129 and consortum > > B TLV 130, etc. > > from this newly defined Message TLV Type table, and IANA would have > > only assigned the one message type from the core space, GENERALIZED > > PROTOCOL TYPE). > > The assignment of the Message-Type-specific message TLV (val=128 > > 3GPP) > > also > > has an extended type field which could allow the 3GPP group to > > define more "unique to them messages” and have them be identified by > > different extended type value fields. It's a full 8 bits so they > > would have potentially > > 255 > > different formats to play with if they wanted without having to eat > > up a bunch of core message types. These extended fields would > > either have to be maintained by IANA or "given" out to the groups > > but the values are there to be used. > > > > I do think there is value in this generalized approach but I think > > it should be discussed within the MANET working group. I would > > advocate for its approval. > > > > TLDR: No, but there is an approach that might work. > > > > Justin Dean > > > > > > From: Sabrina Tanamal via RT <[email protected]> > > Date: Thursday, December 11, 2025 at 6:50 PM > > To: > > Cc: Dean, Justin CIV USN NRL WASHINGTON DC (USA) > > <[email protected]> > > Subject: [Non-DoD Source] [IANA #1430871] MANET Registration from > > 3GPP > > (manet-parameters) > > > > Hi Justin, > > > > Just sending a reminder about this request from last week. > > > > Thanks, > > Sabrina > > > > On Thu Dec 04 21:00:51 2025, sabrina.tanamal wrote: > > > Hi Justin, > > > > > > We’ve received a request from 3GPP to register the following > > > Message Type and Message TLV Type (details below). > > > > > > They’ve also provided a specification, which is attached for > > > reference. > > > > > > If this is OK, for the Message TLV Type registration, should we > > > allocate value 2 or 9 (there are couple of unassigned ranges > > > available in the registry)? > > > > > > If you are available, the due date for this request is December > > > 18th. > > > I've also sent you a separate message regarding the expert review > > > process since we've just listed you as the designated expert for > > > the MANET registries. > > > > > > Thanks, > > > Sabrina > > > > > > On Mon Sep 29 07:49:13 2025, [email protected] wrote: > > > > Dear IANA, > > > > > > > > 3GPP has a MANET registration to request. > > > > I checked RFC 5444 but I wasn’t sure where to submit this > > > > request… would you forward this to whom it may concern? > > > > > > > > Registration type: > > > > > > > > * New message type value for the "5G ProSe MANET discovery > > > > info" > > > > message > > > > * New Type value and Length value for defining new MANET TLV > > > > block > > > > for "Multi-hop UE-to-UE discovery info" IE IANA registry: > > > > MANET related registry (for MANET see IETF RFC 5444) Reference > > > > to the specification: > > > > See clause 10.8 and 11.8 of 3GPP TS 24.554 > > > > v19.2.1<https://usg01.safelinks.protection.office365.us/?url= > > https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F24_series%2F24. > > 554%2F24554- > > &data= > > 05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7C183a92b6eb2e44e42bf208de3 > > 91000c4%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C639010938266480 > > 761%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7 > > C > > &sdata=4VtqnU%2FOZxQqdj7DrRDYPyCcYdHxLeUKryxP3CX6ins%3D&reserved=0 > > > > j21.zip> > > > > > > > > Thank you very much for your kind consideration, hope you have a > > > > great week ahead 😊 > > > > > > > > Best regards, > > > > Dongwook Kim > > > > > > > > Dongwook Kim, Ph.D. – 3GPP Specifications Manager, 3GPP CT3 > > > > Secretary, 3GPP TSG CT Work Plan Coordinator ETSI ● > > > > https://usg01.safelinks.protection.office365.us/?url= > > http%3A%2F%2Fwww.etsi.org%2F&data= > > 05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7C183a92b6eb2e44e42bf208de3 > > 91000c4%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C639010938266497 > > 443%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7 > > C > > &sdata=5aHQdz3kpYhvCysEJ2lSGpFVlV%2BauljTlKxALWZPFZM%3D&reserved=0<h > > ttps:// > > usg01.safelinks.protection.office365.us/?url=http%3A%2F%2Fwww.etsi.o > > rg%2F&data > > = > > 05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7C183a92b6eb2e44e42bf208de3 > > 91000c4%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C639010938266508 > > 443%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7 > > C > > &sdata=PY9oVFBh5WueKLYIxLHzqvP%2F%2FLitVwrAMQDXooDSErg%3D&reserved=0 > > > > > ● > > > > [email protected]<mailto:[email protected]> > > > > 3GPP ● https://usg01.safelinks.protection.office365.us/?url= > > http%3A%2F%2Fwww.3gpp.org%2F&data= > > 05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7C183a92b6eb2e44e42bf208de3 > > 91000c4%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C639010938266518 > > 754%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7 > > C > > &sdata=%2Bq4yvWaEHxTluY0mhgLlBvEpO1o0KBzz0cGoq2GUxAE%3D&reserved=0<h > > ttps:// > > usg01.safelinks.protection.office365.us/?url=http%3A%2F%2Fwww.3gpp.o > > rg%2F&data > > = > > 05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7C183a92b6eb2e44e42bf208de3 > > 91000c4%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C639010938266528 > > 907%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7 > > C > > &sdata=%2FcPjXBClPOpGy886BntSDsOEBjwy4C%2BXUnCmJj3QhwU%3D&reserved=0 > > > > > / > > > > portal.3gpp.org<https://usg01.safelinks.protection.office365.us/ > > > > ?url= > > http%3A%2F%2Fwww.3gpp.org%2F&data= > > 05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7C183a92b6eb2e44e42bf208de3 > > 91000c4%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C639010938266539 > > 021%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7 > > C > > &sdata=EX4d2vC3r%2FYQJzZ3NfAWnj%2FLzX6msa1%2FCKW8KmuWG10%3D&reserved > > =0> > > > > Phone: +33 (0)4 92 94 49 67 > > > > Mobile: +33 (0)6 87 69 12 51 > > > > > > > > [image] > > > > > > > > > > > > This email may contain confidential information and is intended > > > > for the use of the addressee only. Any unauthorized use may be > > > > unlawful. > > > > If you receive this email by mistake, please advise the sender > > > > immediately by using the reply facility in your email software. > > > > Thank > > > > you for your co-operation. > > > > > > On Wed Apr 01 17:01:57 2026, [email protected] wrote: > > Hello David, > > > > Thank you for your kind reply :) > > I've communicated with the 3GPP experts and they indicated that they > > have not reached out to MANET experts at all. > > Here is their justification behind allocating such values: > > CT1 spec assigns the value from the 224-255 range for new msg type > > ‘5G ProSe MANET message’ > > <quote from IETF 5444> > > +---------+-------------+-------------------+ > > | Type | Description | Allocation Policy | > > +---------+-------------+-------------------+ > > | 0-223 | Unassigned | Expert Review | > > | 224-255 | Unassigned | Experimental Use | > > +---------+-------------+-------------------+ > > </quote> > > > > And for the new message specific TLV ‘Multi-hop UE-to-UE discovery > > info’, it follows: > > <quote from IETF 5444> > > +---------+-----------------------------+-------------------+ > > | Type | Description | Allocation Policy | > > +---------+-----------------------------+-------------------+ > > | 0-127 | Common to all Message Types | Reserved | > > | 128-223 | Message-Type-specific | See Below | > > | 224-255 | Common to all Message Types | Reserved | > > +---------+-----------------------------+-------------------+ > > </quote> > > > > Please let me know if you need anything more, thank you very much > > always for your kind consideration :) > > > > Best regards, > > Dongwook Kim > > > > -----Original Message----- > > From: David Dong via RT <[email protected]> > > Sent: 01 April 2026 09:24 > > To: Dongwook Kim <[email protected]> > > Subject: [IANA #1448940] RE: MANET Registration from 3GPP (manet- > > parameters) > > > > Hi Dongwook (filling in for Sabrina), > > > > Thank you for the notice. > > > > To clarify, are the registrations within what is listed as the "224- > > 255 Reserved for Experimental Use" range, or in the unassigned > > ranges in the Message Types and Message TLV Types registries? I see > > an experimental value of "240" in section 10.8.2 and a value of > > "128" in 11.8.1. > > > > Are the designated experts (Justin Dean, Christoper Dearlove as > > backup) already aware of these registrations? We'll reach out to > > Justin afterwards, just wanted to clarify first. > > > > Thank you! > > > > Best regards, > > > > David Dong > > IANA Services Sr. Specialist > > > > On Tue Mar 31 06:59:57 2026, [email protected] wrote: > > > Hello Sabrina, > > > > > > The IETF experts may know already but it was decided by 3GPP to > > > take the specific use range for the values that 3GPP wanted to > > > register. > > > I'm not sure how to proceed with this one (since it is already > > > "used" > > > by 3GPP), but if it is necessary to review, please refer to 24.554 > > > v19.5.0: > > > https://usg01.safelinks.protection.office365.us/?url=https%3A%2F%2 > > > Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F24_series%2F24.554%2F24554 > > > -&data=05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7C7161aa794c124b12 > > > b80508de971f9426%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C6391 > > > 14359370475213%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY > > > iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > > > 7C80000%7C%7C%7C&sdata=vJlRWRSR6GiN7vDJj4vC0JFQSpYfyovZj%2Fx2U7mtO > > > eM%3D&reserved=0 > > > j50.zip, > > > especially clauses 8c.2.2.2, 10.8.2, 11.8.1. > > > > > > Thank you very much for your consideration, hope you have a great > > > day! > > > > > > Best regards, > > > Dongwook Kim > > > > > > -----Original Message----- > > > From: Sabrina Tanamal via RT <[email protected]> > > > Sent: 14 January 2026 15:28 > > > To: Dongwook Kim <[email protected]> > > > Subject: [IANA #1430871] MANET Registration from 3GPP (manet- > > > parameters) > > > > > > Hi Dongwook, > > > > > > No problem. Thank you for letting us know. > > > > > > Best regards, > > > Sabrina > > > > > > On Wed Jan 14 07:30:51 2026, [email protected] wrote: > > > > Hello Sabrina, > > > > > > > > Sorry for the late reply. > > > > It seems that 3GPP experts would like to discuss this formally > > > > in a meeting. > > > > Therefore, please close the ticket for the time-being. I will > > > > follow- > > > > up with another ticket by replying to this thread. > > > > > > > > Thank you very much again :) > > > > > > > > Best regards, > > > > Dongwook Kim > > > > > > > > -----Original Message----- > > > > From: Sabrina Tanamal via RT <[email protected]> > > > > Sent: Tuesday, January 13, 2026 10:45 PM > > > > To: Dongwook Kim <[email protected]> > > > > Subject: [IANA #1430871] MANET Registration from 3GPP (manet- > > > > parameters) > > > > > > > > Hi Dongwook, > > > > > > > > I'm just following up on this request. Let us know if you need > > > > more time. > > > > > > > > Thank you, > > > > Sabrina > > > > > > > > On Mon Dec 22 22:50:54 2025, sabrina.tanamal wrote: > > > > > Hi Dongwook, > > > > > > > > > > No problem, and thank you for letting us know. > > > > > > > > > > We’ll follow up again in the new year. Wishing you a speedy > > > > > recovery. > > > > > > > > > > Best regards, > > > > > Sabrina > > > > > > > > > > On Mon Dec 22 22:39:31 2025, [email protected] wrote: > > > > > > Hello Sabrina, > > > > > > > > > > > > My apologies, I fell ill and still recovering. I will > > > > > > forward this to the 3GPP experts and get back to you ASAP. > > > > > > Given that it is Christmas holidays, I think it will be > > > > > > January 2026 at the earliest. > > > > > > > > > > > > Hope you have a great day! > > > > > > > > > > > > Best regards, > > > > > > Dongwook Kim > > > > > > > > > > > > Sent from > > > > > > Outlook<https://usg01.safelinks.protection.office365.us/?url > > > > > > =https%3A%2F%2Faka.ms%2Fqtex0l&data=05%7C02%7Cjustin.dean7.c > > > > > > iv%40us.navy.mil%7C7161aa794c124b12b80508de971f9426%7Ce3333e > > > > > > 00c8774b87b6ad45e942de1750%7C0%7C0%7C639114359370487961%7CUn > > > > > > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > > > > > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000 > > > > > > %7C%7C%7C&sdata=PD7jKkw3B6SzLqeHbWoZM%2BdYhwQVLjp2aNyBiuKcyc > > > > > > E%3D&reserved=0> for iOS ________________________________ > > > > > > From: Sabrina Tanamal via RT <[email protected]> > > > > > > Sent: Monday, December 22, 2025 10:05:58 PM > > > > > > To: Dongwook Kim <[email protected]> > > > > > > Subject: [IANA #1430871] MANET Registration from 3GPP > > > > > > (manet- > > > > > > parameters) > > > > > > > > > > > > Hi Dongwook, > > > > > > > > > > > > Just checking in on this request. Let us know if there's > > > > > > anything you'd like us to forward to the expert. > > > > > > > > > > > > Best regards, > > > > > > Sabrina > > > > > > > > > > > > On Mon Dec 15 17:37:24 2025, sabrina.tanamal wrote: > > > > > > > Hi Dongwook, > > > > > > > > > > > > > > Justin Dean, the newly appointed designated expert for the > > > > > > > MANET registries, has asked that we forward the review > > > > > > > below. > > > > > > > He’s also open to having a follow-up discussion if that > > > > > > > would be helpful. > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > Thanks, > > > > > > > Sabrina > > > > > > > > > > > > > > ==== > > > > > > > > > > > > > > So I have way more questions than answers at this point. > > > > > > > Regarding > > > > > > > the default question of should they get an IANA > > > > > > > allocation? > > > > > > > If I am forced to give an answer. No. They seem to be > > > > > > > using > > > > > > > RFC5444 > > > > > > > as a header but then roll their own internal message > > > > > > > format > > > > > > > (verify this is the case, 75% certain it is). The > > > > > > > internal messaging format ignores recommendations and > > > > > > > design philosophies listed in both RFC5444 > > > > > > > (packetbb) and RFC 8245 (Rules for designing protocols > > > > > > > using 5444). > > > > > > > The document also does not appear to be an RFC but a > > > > > > > 3GPP technical specification. In the IANA section of 5444 > > > > > > > states: > > > > > > > o The intention is that all registrations will be > > > > > > > accompanied by a > > > > > > > published RFC. > > > > > > > > > > > > > > o In order to allow for registration prior to the RFC > > > > > > > being approved for publication, the Designated Expert can > > > > > > > approve the registration once it seems clear that an RFC > > > > > > > is expected to be published. > > > > > > > > > > > > > > They also define message TLVs for their message which > > > > > > > again just rolls it's own message format internally. I am > > > > > > > okay with this design, it's not great but it doesn't on > > > > > > > the surface break anything. If their design truly is. > > > > > > > > > > > > > > 3GPP TS message is a manet packet formatted based on > > > > > > > RFC5444 > > > > > > > where that packet is: > > > > > > > <packet> := <pkt-header><message> <message> := > > > > > > > <msg-header><tlv-block> (they omit address blocks but say > > > > > > > they use the same mechanism as NHDP and OLSR so?) <msg- > > > > > > > header> > > > > > > > := <msg-type=3GPPVAL><msg-flags><msg-addr-length><msg- > > > > > > > size> > > > > > > > <tlv-block> := <tlv-type=3GPP MULTI-HOP UE-TO-UE DISCOVERY > > > > > > > INFOVAL> <tlv-flags><length><value> > > > > > > > <value> := <3GPP specific format> > > > > > > > > > > > > > > If that is the design then it's fine. Security TLVs won't > > > > > > > work > > > > > > > as > > > > > > > intended as their value field changes on a hop by hop > > > > > > > basis and > > > > > > > the Security TLV design relies upon those values being > > > > > > > immutable once sent by a sender (If I am wrong and they > > > > > > > are not changed hop-by-hop than that will work just fine). > > > > > > > > > > > > > > If the design is <packet> = <pkt-header><message> where > > > > > > > <message> is their own rolled thing (I think it is) then > > > > > > > it's broken and parsers built on RFC5444 won't be able to > > > > > > > process it. > > > > > > > > > > > > > > My other question is WHY they would like an IANA > > > > > > > assignment. > > > > > > > If they are designing something that can be reused then > > > > > > > great but I'm not seeing that. If they aren't using the > > > > > > > IANA protocol id and or multicast address then they can > > > > > > > just pick whatever number they want and if they wanted to > > > > > > > play nice they could select any of the > > > > > > > 224- > > > > > > > 255 > > > > > > > message type range that is reserved for experimental use. > > > > > > > > > > > > > > IF IANA and the MANET working group really wants to have > > > > > > > this approved I could be convinced it would be okay IF: > > > > > > > Their messages can be parsed by a generic RFC5444 parser > > > > > > > without error. > > > > > > > The message assignment name is generalized in nature. > > > > > > > Something > > > > > > > like “GENERALIZED PROTOCOL TYPE". (currently the only > > > > > > > assigned types are HELLO and Topology Control) This > > > > > > > message type assignment would create two separate > > > > > > > registration tables, one for Message-Type-specific message > > > > > > > TLV (val 128-223) and one for > > > > > > > Message-Type-specific-address-block-TLV (val 128-223). > > > > > > > Their message TLV type request would come from this newly > > > > > > > created table, so TLV val of 128 with message type > > > > > > > GENERALIZED PROTOCOL TYPE". > > > > > > > This approach would allow other designers to use RFC5444 > > > > > > > in the same “GENERALIZED PROTOCOL TYPE" way without eating > > > > > > > up a whole bunch of message types, (e.g. consortum A could > > > > > > > request TLV 129 and consortum B TLV 130, etc. from this > > > > > > > newly defined Message TLV Type table, and IANA would have > > > > > > > only assigned the one message type from the core space, > > > > > > > GENERALIZED PROTOCOL TYPE). > > > > > > > The assignment of the Message-Type- specific message TLV > > > > > > > (val=128 3GPP) also has an extended type field which could > > > > > > > allow the 3GPP group to define more "unique to them > > > > > > > messages” > > > > > > > and have them be identified by different extended type > > > > > > > value fields. > > > > > > > It's a full 8 bits so they would have potentially 255 > > > > > > > different formats to play with if they wanted without > > > > > > > having to eat up a bunch of core message types. > > > > > > > These extended fields would either have to be maintained > > > > > > > by IANA or "given" out to the groups but the values are > > > > > > > there to be used. > > > > > > > > > > > > > > I do think there is value in this generalized approach but > > > > > > > I think it should be discussed within the MANET working > > > > > > > group. > > > > > > > I would advocate for its approval. > > > > > > > > > > > > > > TLDR: No, but there is an approach that might work. > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > On Thu Dec 04 21:07:00 2025, sabrina.tanamal wrote: > > > > > > > > Hi Dongwook, > > > > > > > > > > > > > > > > The IESG has approved the new designated expert. I've > > > > > > > > assigned this request for review, and I'll let you know > > > > > > > > as soon as I have more information. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Sabrina > > > > > > > > > > > > > > > > On Tue Dec 02 09:34:46 2025, [email protected] wrote: > > > > > > > > > Dear Sabrina, > > > > > > > > > > > > > > > > > > Thank you for your update. > > > > > > > > > Please let me know when things progress further, > > > > > > > > > thank you very much always for your kind support :) > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Dongwook Kim > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Sabrina Tanamal via RT <iana-prot- > > > > > > > > > [email protected]> > > > > > > > > > Sent: Monday, December 1, 2025 7:46 PM > > > > > > > > > To: Dongwook Kim <[email protected]> > > > > > > > > > Subject: [IANA #1430871] MANET Registration from 3GPP > > > > > > > > > (manet- > > > > > > > > > parameters) > > > > > > > > > > > > > > > > > > Hi Dongwook, > > > > > > > > > > > > > > > > > > Apologies for the delay on this. The AD for the MANET > > > > > > > > > WG has suggested appointing a new designated expert. > > > > > > > > > > > > > > > > > > We’ve submitted a management item for the next formal > > > > > > > > > telechat on 12/04, and once the new expert is > > > > > > > > > approved, we’ll request a review. > > > > > > > > > We’ll keep you updated as soon as we have more > > > > > > > > > information. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Sabrina > > > > > > > > > > > > > > > > > > On Wed Nov 12 23:14:39 2025, sabrina.tanamal wrote: > > > > > > > > > > Hi Dongwook, > > > > > > > > > > > > > > > > > > > > We heard back from the expert, and it sounds like > > > > > > > > > > he's consulting with other experts about this > > > > > > > > > > request. We will let you know as soon as we have > > > > > > > > > > more information. > > > > > > > > > > > > > > > > > > > > Thank you for your patience. > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > Sabrina > > > > > > > > > > > > > > > > > > > > On Tue Nov 04 21:14:14 2025, sabrina.tanamal wrote: > > > > > > > > > > > Hi Dongwook, > > > > > > > > > > > > > > > > > > > > > > This note is just to let you know that I've > > > > > > > > > > > escalated your request to the Area Director. > > > > > > > > > > > > > > > > > > > > > > I'll keep you posted. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Sabrina > > > > > > > > > > > > > > > > > > > > > > On Fri Oct 24 22:06:06 2025, sabrina.tanamal wrote: > > > > > > > > > > > > Hi Dongwook, > > > > > > > > > > > > > > > > > > > > > > > > I just reached out to the expert again. If > > > > > > > > > > > > there’s no response by next week, I’ll escalate > > > > > > > > > > > > to the Area Director. > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your patience. > > > > > > > > > > > > > > > > > > > > > > > > Sabrina > > > > > > > > > > > > > > > > > > > > > > > > On Mon Oct 13 17:35:10 2025, sabrina.tanamal > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi Dongwook, > > > > > > > > > > > > > > > > > > > > > > > > > > This note is just to let you know that your > > > > > > > > > > > > > request is still with the designated expert. > > > > > > > > > > > > > If you have any questions, please don't > > > > > > > > > > > > > hesitate to contact us. > > > > > > > > > > > > > > > > > > > > > > > > > > We'll let you know as soon as we have more > > > > > > > > > > > > > information. > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > > > > > > > > > Sabrina Tanamal IANA Operations Manager > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed Oct 01 17:45:59 2025, sabrina.tanamal > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi Dongwook, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you for your reply. I've sent this on > > > > > > > > > > > > > > to the > > > > > > > > > > > > > > IESG- > > > > > > > > > > > > > > designated expert. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll keep you posted. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, Sabrina > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed Oct 01 13:08:19 2025, > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hello Sabrina, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you for your kind reply. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For #1, yes Message Type and Message TLV > > > > > > > > > > > > > > > Types > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For #2, it is a different version > > > > > > > > > > > > > > > (v19.3.0). > > > > > > > > > > > > > > > Please see attached for the correct > > > > > > > > > > > > > > > version. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also based on your email, I requested > > > > > > > > > > > > > > > further protocol types via website you’ve > > > > > > > > > > > > > > > indicated, please let me know if there is > > > > > > > > > > > > > > > any issue > > > > > > > > > > > > > > > ;) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dongwook Kim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Sabrina Tanamal via RT > > > > > > > > > > > > > > > <iana-prot- [email protected]> > > > > > > > > > > > > > > > Sent: Wednesday, October 1, 2025 2:02 AM > > > > > > > > > > > > > > > To: Dongwook Kim <[email protected]> > > > > > > > > > > > > > > > Subject: [IANA #1430871] MANET > > > > > > > > > > > > > > > Registration from 3GPP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Dongwook, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for contacting us. We have a couple > > > > > > > > > > > > > > > of questions before we send this request > > > > > > > > > > > > > > > to the IESG-designated > > > > > > > > > > > > > > > expert: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) Could you confirm that you are > > > > > > > > > > > > > > > requesting registrations in the Message > > > > > > > > > > > > > > > Types and Message TLV Types registries at > > > > > > > > > > > > > > > https://usg01.safelinks.protection.office3 > > > > > > > > > > > > > > > 65.us/?url=https%3A%2F%2Fwww.iana.org%2Fas > > > > > > > > > > > > > > > signments%2Fmanet-&data=05%7C02%7Cjustin.d > > > > > > > > > > > > > > > ean7.civ%40us.navy.mil%7C7161aa794c124b12b > > > > > > > > > > > > > > > 80508de971f9426%7Ce3333e00c8774b87b6ad45e9 > > > > > > > > > > > > > > > 42de1750%7C0%7C0%7C639114359370499468%7CUn > > > > > > > > > > > > > > > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > > > > > > > > > > > > > > > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO > > > > > > > > > > > > > > > IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C > > > > > > > > > > > > > > > %7C&sdata=vmj404qqugyKKanD6yqDVx33XyuAaTB% > > > > > > > > > > > > > > > 2BDkIiWuE6xEw%3D&reserved=0 parameters? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) Is this the correct link to the > > > > > > > > > > > > > > > specification?https://usg01.safelinks.prot > > > > > > > > > > > > > > > ection.office365.us/?url=https%3A%2F%2Fwww > > > > > > > > > > > > > > > .etsi.org%2Fdeliver%2Fets&data=05%7C02%7Cj > > > > > > > > > > > > > > > ustin.dean7.civ%40us.navy.mil%7C7161aa794c > > > > > > > > > > > > > > > 124b12b80508de971f9426%7Ce3333e00c8774b87b > > > > > > > > > > > > > > > 6ad45e942de1750%7C0%7C0%7C6391143593705109 > > > > > > > > > > > > > > > 99%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > > > > > > > > > > > > > > > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM > > > > > > > > > > > > > > > iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C8000 > > > > > > > > > > > > > > > 0%7C%7C%7C&sdata=%2BlNUKl%2FdF8e0T9CzfjXqR > > > > > > > > > > > > > > > S4%2FI9oQLU6O%2F1kAesPzK5Y%3D&reserved=0 > > > > > > > > > > > > > > > i_ > > > > > > > > > > > > > > > ts > > > > > > > > > > > > > > > /124500_12 > > > > > > > > > > > > > > > 4599/124554/17.02.01_60/ts_124554v170201p. > > > > > > > > > > > > > > > pdf > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A quick note for future requests: emailing > > > > > > > > > > > > > > > us at this address will always reach our > > > > > > > > > > > > > > > monitored ticketing system. > > > > > > > > > > > > > > > Alternatively, you can also submit > > > > > > > > > > > > > > > requests through our general form, > > > > > > > > > > > > > > > available at > > > > > > > > > > > > > > > https://usg01.safelinks.protection.office3 > > > > > > > > > > > > > > > 65.us/?url=https%3A%2F%2Fwww.iana.org%2Ffo > > > > > > > > > > > > > > > rm%2Fprotocol-&data=05%7C02%7Cjustin.dean7 > > > > > > > > > > > > > > > .civ%40us.navy.mil%7C7161aa794c124b12b8050 > > > > > > > > > > > > > > > 8de971f9426%7Ce3333e00c8774b87b6ad45e942de > > > > > > > > > > > > > > > 1750%7C0%7C0%7C639114359370522365%7CUnknow > > > > > > > > > > > > > > > n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl > > > > > > > > > > > > > > > YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > > > > > > > > > > > > > > > TWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C& > > > > > > > > > > > > > > > sdata=%2FTm1S3i9C7XabmWpKgVgV8FqG36QNRIeYW > > > > > > > > > > > > > > > %2FKvgcN8%2F0%3D&reserved=0 assignment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sabrina Tanamal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IANA Operations Manager > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon Sep 29 07:49:13 2025, > > > > > > > > > > > > > > > [email protected]<mailto:Dongwook.Kim@ > > > > > > > > > > > > > > > etsi > > > > > > > > > > > > > > > .o > > > > > > > > > > > > > > > rg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dear IANA, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3GPP has a MANET registration to request. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I checked RFC 5444 but I wasn’t sure > > > > > > > > > > > > > > > > where to submit this request… > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > would you forward this to whom it may > > > > > > > > > > > > > > > > concern? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Registration type: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * New message type value for the "5G > > > > > > > > > > > > > > > > ProSe > > > > > > > > > > > > > > > > MANET > > > > > > > > > > > > > > > > discovery info" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > message > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * New Type value and Length value for > > > > > > > > > > > > > > > > defining new MANET TLV block > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > for "Multi-hop UE-to-UE discovery info" > > > > > > > > > > > > > > > > IE > > > > > > > > > > > > > > > > IANA > > > > > > > > > > > > > > > > registry: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > MANET related registry (for MANET see > > > > > > > > > > > > > > > > IETF RFC > > > > > > > > > > > > > > > > 5444) > > > > > > > > > > > > > > > > Reference to the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > specification: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > See clause 10.8 and 11.8 of 3GPP TS > > > > > > > > > > > > > > > > 24.554 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > v19.2.1<https://usg01.safelinks.protecti > > > > > > > > > > > > > > > > on.office365.us/?url=https%3A%2F%2Fwww.3 > > > > > > > > > > > > > > > > gpp.org%2Fftp%2FSpecs%2Farchi&data=05%7C > > > > > > > > > > > > > > > > 02%7Cjustin.dean7.civ%40us.navy.mil%7C71 > > > > > > > > > > > > > > > > 61aa794c124b12b80508de971f9426%7Ce3333e0 > > > > > > > > > > > > > > > > 0c8774b87b6ad45e942de1750%7C0%7C0%7C6391 > > > > > > > > > > > > > > > > 14359370533379%7CUnknown%7CTWFpbGZsb3d8e > > > > > > > > > > > > > > > > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM > > > > > > > > > > > > > > > > CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > > > > > > > > > > > > > > > > joyfQ%3D%3D%7C80000%7C%7C%7C&sdata=s1493 > > > > > > > > > > > > > > > > QowqGhCwA%2BjFS1FtHfGbchtO1j%2FZG%2BZYs6 > > > > > > > > > > > > > > > > auE4%3D&reserved=0 > > > > > > > > > > > > > > > > ve > > > > > > > > > > > > > > > > /2 > > > > > > > > > > > > > > > > 4_series/2 > > > > > > > > > > > > > > > > 4.554/24554- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > j21.zip> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you very much for your kind > > > > > > > > > > > > > > > > consideration, hope you have a great > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > week ahead 😊 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dongwook Kim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dongwook Kim, Ph.D. – 3GPP > > > > > > > > > > > > > > > > Specifications Manager, 3GPP > > > > > > > > > > > > > > > > CT3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Secretary, 3GPP TSG CT Work Plan > > > > > > > > > > > > > > > > Coordinator ETSI ● > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://usg01.safelinks.protection.offic > > > > > > > > > > > > > > > > e365.us/?url=http%3A%2F%2Fwww.etsi.org%2 > > > > > > > > > > > > > > > > F&data=05%7C02%7Cjustin.dean7.civ%40us.n > > > > > > > > > > > > > > > > avy.mil%7C7161aa794c124b12b80508de971f94 > > > > > > > > > > > > > > > > 26%7Ce3333e00c8774b87b6ad45e942de1750%7C > > > > > > > > > > > > > > > > 0%7C0%7C639114359370544329%7CUnknown%7CT > > > > > > > > > > > > > > > > WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO > > > > > > > > > > > > > > > > iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > > > > > > > > > > > > > > > > WFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C > > > > > > > > > > > > > > > > &sdata=6c%2FkkXTiiRwPrNeyfppnj3vxP68ejzH > > > > > > > > > > > > > > > > iMh2iXQY%2FQLE%3D&reserved=0<https://usg > > > > > > > > > > > > > > > > 01.safelinks.protection.office365.us/?ur > > > > > > > > > > > > > > > > l=http%3A%2F%2Fwww.etsi.org%2F&data=05%7 > > > > > > > > > > > > > > > > C02%7Cjustin.dean7.civ%40us.navy.mil%7C7 > > > > > > > > > > > > > > > > 161aa794c124b12b80508de971f9426%7Ce3333e > > > > > > > > > > > > > > > > 00c8774b87b6ad45e942de1750%7C0%7C0%7C639 > > > > > > > > > > > > > > > > 114359370556397%7CUnknown%7CTWFpbGZsb3d8 > > > > > > > > > > > > > > > > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > > > > > > > > > > > > > > > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU > > > > > > > > > > > > > > > > IjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=yasQ > > > > > > > > > > > > > > > > mTp7WkpHOuilf3DZ8gC6%2BuADrBKFVuRgLfLAzV > > > > > > > > > > > > > > > > w%3D&reserved=0> ● > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [email protected]<mailto:[email protected]<mailto: > > > > > > > > > > > > > > > > [email protected]%3cmailto:dongwook. > > > > > > > > > > > > > > > > kim@ > > > > > > > > > > > > > > > > et > > > > > > > > > > > > > > > > si > > > > > > > > > > > > > > > > .org>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3GPP ● > > > > > > > > > > > > > > > > https://usg01.safelinks.protection.offic > > > > > > > > > > > > > > > > e365.us/?url=http%3A%2F%2Fwww.3gpp.org%2 > > > > > > > > > > > > > > > > F&data=05%7C02%7Cjustin.dean7.civ%40us.n > > > > > > > > > > > > > > > > avy.mil%7C7161aa794c124b12b80508de971f94 > > > > > > > > > > > > > > > > 26%7Ce3333e00c8774b87b6ad45e942de1750%7C > > > > > > > > > > > > > > > > 0%7C0%7C639114359370571337%7CUnknown%7CT > > > > > > > > > > > > > > > > WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO > > > > > > > > > > > > > > > > iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > > > > > > > > > > > > > > > > WFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C > > > > > > > > > > > > > > > > &sdata=SpYJKIuuT5hGN%2FuibDpAitsET6H5clC > > > > > > > > > > > > > > > > X77rcDqrnVdI%3D&reserved=0<https://usg01 > > > > > > > > > > > > > > > > .safelinks.protection.office365.us/?url= > > > > > > > > > > > > > > > > http%3A%2F%2Fwww.3gpp.org%2F&data=05%7C0 > > > > > > > > > > > > > > > > 2%7Cjustin.dean7.civ%40us.navy.mil%7C716 > > > > > > > > > > > > > > > > 1aa794c124b12b80508de971f9426%7Ce3333e00 > > > > > > > > > > > > > > > > c8774b87b6ad45e942de1750%7C0%7C0%7C63911 > > > > > > > > > > > > > > > > 4359370583093%7CUnknown%7CTWFpbGZsb3d8ey > > > > > > > > > > > > > > > > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMC > > > > > > > > > > > > > > > > IsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > > > > > > > > > > > > > > > > oyfQ%3D%3D%7C80000%7C%7C%7C&sdata=yEeW%2 > > > > > > > > > > > > > > > > BfutO3GPd31E7uk3rJJBGR7Qdks5Dl%2B5dRr0XQ > > > > > > > > > > > > > > > > w%3D&reserved=0> > > > > > > > > > > > > > > > > / > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > portal.3gpp.org<https://usg01.safelinks. > > > > > > > > > > > > > > > > protection.office365.us/?url=http%3A%2F% > > > > > > > > > > > > > > > > 2Fwww.3gpp.org%2F&data=05%7C02%7Cjustin. > > > > > > > > > > > > > > > > dean7.civ%40us.navy.mil%7C7161aa794c124b > > > > > > > > > > > > > > > > 12b80508de971f9426%7Ce3333e00c8774b87b6a > > > > > > > > > > > > > > > > d45e942de1750%7C0%7C0%7C6391143593705938 > > > > > > > > > > > > > > > > 74%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > > > > > > > > > > > > > > > > GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > > > > > > > > > > > > > > > > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > > > > > > > > > > > > > > > > 7C80000%7C%7C%7C&sdata=7VxVLDoG3f%2FwvP% > > > > > > > > > > > > > > > > 2BkNUs%2BmJNylbtdBoNbxvJ4rOERtoQ%3D&rese > > > > > > > > > > > > > > > > rved=0> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Phone: +33 (0)4 92 94 49 67 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Mobile: +33 (0)6 87 69 12 51 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [image] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This email may contain confidential > > > > > > > > > > > > > > > > information and is intended for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the use of the addressee only. Any > > > > > > > > > > > > > > > > unauthorized use may be unlawful. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you receive this email by mistake, > > > > > > > > > > > > > > > > please advise the sender > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > immediately by using the reply facility > > > > > > > > > > > > > > > > in your email software. > > > > > > > > > > > > > > > > Thank > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > you for your co-operation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ manet mailing list -- [email protected] To unsubscribe send an email to [email protected]
smime.p7s
(application/pkcs7-signature, 8.2 KB) - not displayed