[manet] Re: IANA #1448940 MANET Registration request from 3GPP (manet-parameters)
Christopher Dearlove <[email protected]> Mon, 4 May 2026 23:27:00 +0100
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <[email protected]> |
--===============6976352349379964725== Content-Type: multipart/alternative; boundary="Apple-Mail=_BF8D5353-EE7A-4B54-A8B3-71EC71377361" --Apple-Mail=_BF8D5353-EE7A-4B54-A8B3-71EC71377361 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I indicated this was preferable. How hard we push them to do this is a = judgement call. I think a dialogue would be appropriate. > On 4 May 2026, at 23:24, bebemaster <[email protected]> wrote: >=20 >=20 > Chris I agree but would add one small detail that may be overlooked. = Them requesting a message type and a message specific TLV to contian = their own format doesn't necessarily preclude them from developing = address block usage and address block tlvs, ie use the format more = correctly. We may want to push back on the exclusion of the address = block usage, so future modifications that might use it correctly would = be able to do so without another type allocation. >=20 > Justin >=20 > -------- Original message -------- > From: Christopher Dearlove <[email protected]> > Date: 5/4/26 4:16 PM (GMT-05:00) > To: "Dean, Justin CIV USN NRL WASHINGTON DC (USA)" = <[email protected]> > Cc: [email protected] > Subject: [manet] Re: IANA #1448940 MANET Registration request from = 3GPP (manet-parameters) >=20 > I read the document, or at least the relevant parts of it, and formed = one views before reading Justin=E2=80=99s comments. However I read hi = comment before writing them down. I am very much thinking similarly to = Justin, but I=E2=80=99ll make my comments anyway. >=20 > First, I think it is to be encouraged that 3GPP are taking account of = work in the MANET WG. So I very much would prefer all comment to be = considered as encouraging but suggesting where can do better. >=20 > I think SHOULD means =E2=80=9Cunless you have a good reason=E2=80=9D. = And I think the point of wanting an RFC is so things are traceable etc. = And a 3GPP document serves that role as well, so no issue there. >=20 > The message suggested is experimental. There are always issues when = standards choose experimental blocks, the experiment has =E2=80=9Cescaped=E2= =80=9D and prevented others from using that allocation care-free. I = haven=E2=80=99t confirmed the that of this document, but that is an = issue. But then this doubles down on the issue by claiming a message = type specific TLV. I don=E2=80=99t think an allocated TLV Type for an = unallocated message type makes sense. Both should be allocated or = neither. >=20 > If we go down the route of allocating a message type, those are = limited (though we=E2=80=99re at such low numbers that not very = limited). Nevertheles - and here I haven=E2=80=99t read the document = well enough - it should be considered whether this is a narrow = information transport message or a broad one. For example, NHDP+OLRv2 = make do with just two message types - local and MANET-wide, containing = multiple type of information via different TLVs. It=E2=80=99s worth = thinking if that=E2=80=99s a pattern to copy. >=20 > Which lead to that this might be 5444 compliant, but it=E2=80=99s not = really compliant with the spirit at least of 8245. The point of 8245 was = to codify hard-won experience on how to use address blocks and = information attached them. This could really easily be converted to a = TLV without addresses itself - an address block TLV not a message TLV - = and attached to addresses. It even has the right form for that. This = would make it much more future proof (want new information? add another = TLV) and possibly more efficient (if information I repeated or addresses = can be compressed). >=20 > As a small technical detail, if allocating a TLV - of any type - = it=E2=80=99s worth being clear the nature of the TLV type and extension. = This is less critical if message type specific, because to doesn=E2=80=99t= impact on anyone else, but I this - as is often the case - allocating = one type and just type extension 0, or allocating one complete type = block, even if only extension 0 is defined now? >=20 > (If that isn=E2=80=99t clear, we=E2=80=99re probably here to help.) >=20 > Hope that helps >=20 > Christopher Dearlove >=20 > > On 4 May 2026, at 17:51, Dean, Justin CIV USN NRL WASHINGTON DC = (USA) <[email protected]> wrote: > >=20 > > 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. > >=20 > > Justin Dean > >=20 > > 3GPP=20 > > Specification (24.554 v19.5.0): = https://usg01.safelinks.protection.office365.us/?url=3Dhttps%3A%2F%2Fwww.3= gpp.org%2Fftp%2FSpecs%2Farchive%2F24_series%2F24.554%2F24554-j50.zip&data=3D= 05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7Cc0ed6c8da5844e09aa0208de9020366= 4%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C639106665974335314%7CUnknow= n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi= IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=3DIBPo%2FYEuWb5D= SfyCH3XLq3ZPe2gTEGraPMWw2H3MZr4%3D&reserved=3D0 (8c.2.2.2, 10.8.2, = 11.8.1) > >=20 > >=20 > > My review sans input from WG. > > -----Original Message----- > > From: Dean, Justin CIV USN NRL WASHINGTON DC (USA)=20 > > 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) > >=20 > > 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.... > >=20 > >=20 > > 10.8.2.1=20 > > change 240 to 3 as indicated in prior email and remove the "NOTE".=20= > >=20 > > 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. > >=20 > > 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. > >=20 > >=20 > > 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.=20 > >=20 > > 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." > >=20 > >=20 > > 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. > >=20 > > Justin Dean > > --Apple-Mail=_BF8D5353-EE7A-4B54-A8B3-71EC71377361 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;">I indicated this was preferable. How = hard we push them to do this is a judgement call. I think a dialogue = would be appropriate.<br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On 4 May 2026, at 23:24, bebemaster = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><meta http-equiv=3D"Content-Type"= content=3D"text/html; charset=3DUTF-8"><div dir=3D"auto"><div = dir=3D"auto"><br></div><div dir=3D"auto">Chris I agree but would add one = small detail that may be overlooked. Them requesting a message type and = a message specific TLV to contian their own format doesn't necessarily = preclude them from developing address block usage and address block = tlvs, ie use the format more correctly. We may want to push back on the = exclusion of the address block usage, so future modifications that might = use it correctly would be able to do so without another type = allocation.</div><div dir=3D"auto"><br></div><div = dir=3D"auto">Justin</div><div><br></div><div align=3D"left" dir=3D"auto" = style=3D"font-size: 100%;"><div>-------- Original message = --------</div><div>From: Christopher Dearlove = <[email protected]> </div><div>Date: 5/4/26 4:16 PM = (GMT-05:00) </div><div>To: "Dean, Justin CIV USN NRL WASHINGTON DC = (USA)" <[email protected]> = </div><div>Cc: [email protected] </div><div>Subject: [manet] Re: IANA = #1448940 MANET Registration request from 3GPP (manet-parameters) = </div><div><br></div></div>I read the document, or at least the relevant = parts of it, and formed one views before reading Justin=E2=80=99s = comments. However I read hi comment before writing them down. I am very = much thinking similarly to Justin, but I=E2=80=99ll make my comments = anyway.<br dir=3D"auto"><br dir=3D"auto">First, I think it is to be = encouraged that 3GPP are taking account of work in the MANET WG. So I = very much would prefer all comment to be considered as encouraging but = suggesting where can do better.<br dir=3D"auto"><br dir=3D"auto">I think = SHOULD means =E2=80=9Cunless you have a good reason=E2=80=9D. And I = think the point of wanting an RFC is so things are traceable etc. And a = 3GPP document serves that role as well, so no issue there.<br = dir=3D"auto"><br dir=3D"auto">The message suggested is experimental. = There are always issues when standards choose experimental blocks, the = experiment has =E2=80=9Cescaped=E2=80=9D and prevented others from using = that allocation care-free. I haven=E2=80=99t confirmed the that of this = document, but that is an issue. But then this doubles down on the issue = by claiming a message type specific TLV. I don=E2=80=99t think an = allocated TLV Type for an unallocated message type makes sense. Both = should be allocated or neither.<br dir=3D"auto"><br dir=3D"auto">If we = go down the route of allocating a message type, those are limited = (though we=E2=80=99re at such low numbers that not very limited). = Nevertheles - and here I haven=E2=80=99t read the document well enough - = it should be considered whether this is a narrow information transport = message or a broad one. For example, NHDP+OLRv2 make do with just two = message types - local and MANET-wide, containing multiple type of = information via different TLVs. It=E2=80=99s worth thinking if that=E2=80=99= s a pattern to copy.<br dir=3D"auto"><br dir=3D"auto">Which lead to that = this might be 5444 compliant, but it=E2=80=99s not really compliant with = the spirit at least of 8245. The point of 8245 was to codify hard-won = experience on how to use address blocks and information attached them. = This could really easily be converted to a TLV without addresses itself = - an address block TLV not a message TLV - and attached to = addresses. It even has the right form for that. This would make it much = more future proof (want new information? add another TLV) and possibly = more efficient (if information I repeated or addresses can be = compressed).<br dir=3D"auto"><br dir=3D"auto">As a small technical = detail, if allocating a TLV - of any type - it=E2=80=99s worth being = clear the nature of the TLV type and extension. This is less critical if = message type specific, because to doesn=E2=80=99t impact on anyone else, = but I this - as is often the case - allocating one type and just type = extension 0, or allocating one complete type block, even if only = extension 0 is defined now?<br dir=3D"auto"><br dir=3D"auto">(If that = isn=E2=80=99t clear, we=E2=80=99re probably here to help.)<br = dir=3D"auto"><br dir=3D"auto">Hope that helps<br dir=3D"auto"><br = dir=3D"auto">Christopher Dearlove<br dir=3D"auto"><br dir=3D"auto">> = On 4 May 2026, at 17:51, Dean, Justin CIV USN NRL WASHINGTON DC (USA) = <[email protected]> wrote:<br = dir=3D"auto">> <br dir=3D"auto">> 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.<br dir=3D"auto">> <br = dir=3D"auto">> Justin Dean<br dir=3D"auto">> <br dir=3D"auto">> = 3GPP <br dir=3D"auto">> Specification (24.554 v19.5.0): = https://usg01.safelinks.protection.office365.us/?url=3Dhttps%3A%2F%2Fwww.3= gpp.org%2Fftp%2FSpecs%2Farchive%2F24_series%2F24.554%2F24554-j50.zip&d= ata=3D05%7C02%7Cjustin.dean7.civ%40us.navy.mil%7Cc0ed6c8da5844e09aa0208de9= 0203664%7Ce3333e00c8774b87b6ad45e942de1750%7C0%7C0%7C639106665974335314%7C= Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX= aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=3DIBPo= %2FYEuWb5DSfyCH3XLq3ZPe2gTEGraPMWw2H3MZr4%3D&reserved=3D0 (8c.2.2.2, = 10.8.2, 11.8.1)<br dir=3D"auto">> <br dir=3D"auto">> <br = dir=3D"auto">> My review sans input from WG.<br dir=3D"auto">> = -----Original Message-----<br dir=3D"auto">> From: Dean, Justin CIV = USN NRL WASHINGTON DC (USA) <br dir=3D"auto">> Sent: Monday, April = 13, 2026 2:00 PM<br dir=3D"auto">> To: = [email protected]<br dir=3D"auto">> Subject: RE: = [Non-DoD Source] [IANA #1448940] RE: MANET Registration from 3GPP = (manet-parameters)<br dir=3D"auto">> <br dir=3D"auto">> 10.8.1 = Should explicitly define the message type name. 5G_PROSE_MANET = message (multi-hop, relay?)<br dir=3D"auto">> Proposed change:<br = dir=3D"auto">> This document defines a new MANET message Type = 5G_PROSE_MANET(3) and a message specific TLV block type = 5G_PROSE_MANET_TLV(128).<br dir=3D"auto">> 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....<br dir=3D"auto">> <br = dir=3D"auto">> <br dir=3D"auto">> 10.8.2.1 <br dir=3D"auto">> = change 240 to 3 as indicated in prior email and remove the "NOTE". <br = dir=3D"auto">> <br dir=3D"auto">> 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.<br = dir=3D"auto">> <br dir=3D"auto">> 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.<br dir=3D"auto">> Proposed change:<br dir=3D"auto">> = The multi-hop UE-to-UE discovery info parameter follows the message TLV = format defined in IETF RFC 5444 [59].<br dir=3D"auto">> This message = TLV, type 5G_PROSE_MANET_TLV(128), is to be attached to a MANET message = of type 5G_PROSE_MANET(3).<br dir=3D"auto">> The multi-hop UE-to-UE = discovery info parameter has a minimum length of 14 octets and a maximum = length of 65539 octets.<br dir=3D"auto">> <br dir=3D"auto">> <br = dir=3D"auto">> 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. <br dir=3D"auto">> <br dir=3D"auto">> I = propose adding to 10.8.1<br dir=3D"auto">> "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."<br = dir=3D"auto">> <br dir=3D"auto">> <br dir=3D"auto">> 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.<br dir=3D"auto">> <br = dir=3D"auto">> Justin Dean<br dir=3D"auto">><br = dir=3D"auto"></div></div></blockquote></div><br></body></html>= --Apple-Mail=_BF8D5353-EE7A-4B54-A8B3-71EC71377361-- --===============6976352349379964725== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWFuZXQgbWFp bGluZyBsaXN0IC0tIG1hbmV0QGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gbWFuZXQtbGVhdmVAaWV0Zi5vcmcK --===============6976352349379964725==--