[manet] Re: IANA #1448940 MANET Registration request from 3GPP (manet-parameters)

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.Justin
-------- 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) I read the document, or at least the relevant parts of it, and formed one views before reading Justin’s comments. However I read hi comment before writing them down. I am very much thinking similarly to Justin, but I’ll make my comments anyway.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.I think SHOULD means “unless you have a good reason”. 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.The message suggested is experimental. There are always issues when standards choose experimental blocks, the experiment has “escaped” and prevented others from using that allocation care-free. I haven’t 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’t think an allocated TLV Type for an unallocated message type makes sense. Both should be allocated or neither.If we go down the route of allocating a message type, those are limited (though we’re at such low numbers that not very limited). Nevertheles - and here I haven’t 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’s worth thinking if that’s a pattern to copy.Which lead to that this might be 5444 compliant, but it’s 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).As a small technical detail, if allocating a TLV - of any type - it’s worth being clear the nature of the TLV type and extension. This is less critical if message type specific, because to doesn’t 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?(If that isn’t clear, we’re probably here to help.)Hope that helpsChristopher Dearlove> On 4 May 2026, at 17:51, Dean, Justin CIV USN NRL WASHINGTON DC (USA) <[email protected]> wrote:> > 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>

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]