[Sis-dtn] IPN Node Number Assignment

Fri Jan 20 03:34:36 UTC 2023

BTW, I wrote that note below because when I was interacting with CCSDS people, specially in the early years of SANA, and even up to recently, people were not that used to registries and their management and the “interaction” with protocol specifications. This type of work is more “in place” and known in IETF.  So during CCSDS meetings, I often had to tell people that registries are there for the community and that all the rules are defined by and for the community. I found often that people did not know it and were taking everything that they see on the SANA web site as granted.  Hence my note. Again, if the current policy is not good enough, change it as you see fit.

Marc.

> Le 19 janv. 2023 à 22:26, Marc Blanchet <marc.blanchet at viagenie.ca> a écrit :
> 
> 
>> Le 19 janv. 2023 à 21:08, Vint Cerf <vint at google.com> a écrit :
>> 
>> this is a lot like IANA rules.
> 
> Exactly! One can only inspire from the great minds! ;-)
> 
> Marc.
> 
>> v
>> 
>> 
>> On Thu, Jan 19, 2023 at 3:02 PM Marc Blanchet via SIS-DTN <sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org>> wrote:
>>> FYI, I'm the “creator”  (I defined the idea (inspired by IANA), wrote the YB, be contracted to implement it) and have been the manager of SANA from the beginning until last year. So I’m not responding on behalf of SANA, but I can give some background…
>>> 
>>> All registries managed by SANA have an allocation/assignment policy. That policy is not defined by SANA but by the community (aka ccsds area or working group). In some ways, the wg who defines the registry is the “owner” of the registry; SANA is just the custodian: receive the requests, and apply the policy for allocations. So it is up to the working group to define or modify the policies. If the wg prefers an allocation by 5 and that the requestor has to send a banana to SANA, then it will be done that way ;-).  So if the current allocation policy is not good, make a resolution and modify it as you see fit.
>>> 
>>> Regards, Marc.
>>> 
>>>> Le 19 janv. 2023 à 02:36, Felix Flentge via SIS-DTN <sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org>> a écrit :
>>>> 
>>>> Hi,
>>>>  
>>>> I would like to discuss today or soon assignment of CBHE node numbers. As we get more and more (semi-)operational deployment, I think we all should make an effort to use assigned numbers (and not just numbers < 100 for convenience).
>>>>  
>>>> According to Bundle Protocol (iana.org) <https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-node-numbers> SANA is managing the range 16384-2097151.
>>>>  
>>>> In the (valuable) 2 byte range we have in SANA currently only one allocation:
>>>>  
>>>> 32768 - 33791
>>>> 
>>>> NASA George C. Marshall Space Flight Center [1.3.112.4.1.19.3] <https://sanaregistry.org/r/organizations/records/53>
>>>>  
>>>>  
>>>> As we are deploying more nodes operationally, I would like to discuss the allocation of these 2 bytes node numbers (I understand it may be a SANA thing but I would prefer to have some consensus in the DTN WG first before grabbing some numbers.
>>>>  
>>>> I could imagine to assign the lower allocation (16384 – 32767) for private use (ie non-interoperable mission use; bundles using these numbers shall never cross the border between networks under different operational authority).
>>>>  
>>>> For the higher 2-byte range, I would propose handing out blocks of 1024 numbers (like for MSFC) to CCSDS member agencies. 1024 numbers may seem a lot but it would allow to have some internal logic for assignment (e.g., a block for Earth-bound nodes; obviously such information shall not be used for routing)
>>>>  
>>>> Some questions:
>>>> Could an Agency request more than one block? Maybe only if well justified, e.g. if the other allocation is used up.
>>>> Should we have rules that at least some numbers in an allocation have to be used, otherwise the allocation will be freed up again (like frequencies)?
>>>> What about commercial entities that would like to deploy nodes?
>>>>  
>>>> Regards,
>>>> Felix
>>>>  
>>>> This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int <mailto:dpo at esa.int>). _______________________________________________
>>>> SIS-DTN mailing list
>>>> SIS-DTN at mailman.ccsds.org <mailto:SIS-DTN at mailman.ccsds.org>
>>>> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>>> 
>>> _______________________________________________
>>> SIS-DTN mailing list
>>> SIS-DTN at mailman.ccsds.org <mailto:SIS-DTN at mailman.ccsds.org>
>>> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>> 
>> 
>> -- 
>> Please send any postal/overnight deliveries to:
>> Vint Cerf
>> Google, LLC
>> 1900 Reston Metro Plaza, 16th Floor
>> Reston, VA 20190
>> +1 (571) 213 1346
>> 
>> 
>> until further notice
>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230119/d87880f0/attachment-0001.htm>