[Sis-dtn] IPN Node Number Assignment

[Vint Cerf]

this is a lot like IANA rules.
v


On Thu, Jan 19, 2023 at 3:02 PM Marc Blanchet via SIS-DTN <
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> 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). _______________________________________________
> SIS-DTN mailing list
> 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
> 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/a9cf1bf2/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3995 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230119/a9cf1bf2/attachment-0001.bin>