[Sis-dtn] https://www.ietf.org/archive/id/draft-taylor-dtn-ipn-update-01.html

[Dr. Keith L Scott]

Greetings,

I’m not too enthusiastic about changing the ipn scheme at this point, and this still doesn’t address the ‘flatness’ of routing based on ipn EIDs.  That said, if we’re going to make changes, the sooner the better.


4.1 of the draft says that node number values >= 2**64 are reserved, but the range of CBOR unsigned integers is limited to 0..2**64-1 inclusive.  So how would we encode ‘reserved’ values in the ipn scheme (since it specifies CBOR encoding of the node numbers -- or is the idea that they just wouldn’t be encodable in the ipn scheme)?  Values >=2**64 also sort of conflicts with the text immediately above 5.3, right?


Is it better to RE-define the URI Scheme number 2 (ipn) as defined in the draft or to simply leave it (and current implementations) alone and define URI Scheme 3 to be ‘ipn+’ (ipn with authorities).  The major ‘con’ that’s immediately apparent would be that implementations that deal with the original ipn scheme might immediately need to deal with TWO schemes (ipn and ipn+); the pro would be that existing implementations don’t have to do anything.

I suspect redefinition the way it’s proposed in the draft will be easier for the space community.


                                v/r,

                                --keith


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