> Le 25 juin 2024 à 10:29, Sipos, Brian J. <brian.si...@jhuapl.edu> a écrit :
>
> Scott,
> I see two major issues with your current proposal.
>
> The first is that a CLA is more than just a specific transport, it is also a
> profile and likely a whole protocol above that transport. For example, there
> are multiple versions of "TCPCL" which behave differently and have different
> capabilities. So just saying "I support TCP-over-IPv6" falls short of
> indicating what a node is actually capable of and whether or not I can expect
> to successfully make contact and transfer bundles with that peer.
>
> The second is that I think it's actually more appropriate to use DNS Service
> Discovery (DNS-SD) as a mechanism to register CLAs over DNS. I have drafted a
> profile of this in [1] which does not even require any new code point
> allocations; the existing DNS-SD and service name registries [2] already have
> what is needed for a node to register listening CLAs as services. The DNS-SD
> also works for both unicast and multicast DNS. In the specific profile of [1]
> there is a requirement that only BP routers register themselves, but that is
> more of a convenience than a strict necessity.
I agree with using DNS-SD instead. I for one, also suggested that years ago.
Marc.
>
> One possible extension to the DNS-SD profile is to define a service parameter
> ("bpnodeid" or similar) which would allow exposing the node's administrative
> EID in the DNS-SD registration. This opens the door to some security
> considerations about authenticating ownership of that EID, but it is a
> possible mechanism on a closed and trusted network.
>
> Another possibility is to use existing CERT RR [3] to store certificates
> asserting ownership of one or more EIDs, which are already defined as a PKIX
> profile in RFC 9174 [4]. My main concern with just having a bare EID (or part
> of an EID in this case, just the IPN node number) in DNS is that there is no
> way to assign a chain of trust to some authority of BP node naming.
>
> Thanks for consideration of this feedback,
> Brian S.
>
> [1]
> https://www.ietf.org/archive/id/draft-sipos-dtn-edge-zeroconf-01.html#section-3
> [2]
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
> [3] https://www.rfc-editor.org/rfc/rfc4398.html
> [4] https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.2
>
>> -----Original Message-----
>> From: Scott Johnson <sc...@spacelypackets.com>
>> Sent: Tuesday, June 25, 2024 5:57 AM
>> To: Erik Kline <ek.i...@gmail.com>
>> Cc: dnsop <dnsop@ietf.org>; sburleig...@gmail.com; d...@ietf.org
>> Subject: [EXT] [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
>> Protocol RFC9171
>>
>> APL external email warning: Verify sender forwardingalgori...@ietf.org before
>> clicking links or attachments
>>
>> Hi Erik,
>>
>> Cross posted to DTN list for any such discussion, if they so desire.
>> The draft in question is here:
>> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>>
>> Thanks,
>> ScottJ
>>
>> On Tue, 25 Jun 2024, Erik Kline wrote:
>>
>>> Speaking as the responsible AD for DTN, I think the DTN working group
>>> should probably have a discussion about what it wants to do (if
>>> anything) vis. DNS RRs.
>>>
>>> On Tue, Jun 25, 2024 at 08:27 Scott Johnson <sc...@spacelypackets.com>
>>> wrote:
>>> Hi Mark,
>>>
>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
>>>
>>>>
>>>>
>>>>> On 25 Jun 2024, at 16:36, Scott Johnson
>>> <sc...@spacelypackets.com> wrote:
>>>>>
>>>>> Hi Mark,
>>>>>
>>>>> Noted and changed. Good stuff, thanks. Updated draft
>>> (04) at datatracker using that verbiage:
>>>>>
>>> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>>>>>
>>>>> Is it appropriate to add an acknowledgments section or
>>> co-authors at this point?
>>>>
>>>> I’m not fussed either way.
>>>
>>> (05) of the draft adds a "Contributors" section.
>>>
>>>>
>>>>> As well, should I be asking for WG adoption (DNSOP or
>>> DTN WG), or as an Informational document, is Individual
>>> submission sufficient?
>>>>
>>>> I’ll leave that for the chairs to answer.
>>>
>>> Ack. Thank you so much for your time and attention to this
>>> document.
>>>
>>> ScottJ
>>>
>>>>
>>>>> Thanks,
>>>>> ScottJ
>>>>>
>>>>>
>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
>>>>>
>>>>>> Made the IPN description more specific.
>>>>>>
>>>>>>
>>>>>> Wire format
>>> encoding shall
>>>>>> be an unsigned 64-bit integer in network order.
>>> Presentation format, for these
>>>>>> resource records are either a 64 bit unsigned decimal
>>> integer, or two 32 bit
>>>>>> unsigned decimal integers delimited by a period with
>>> the most significant 32 bits
>>>>>> first and least significant 32 bits last. Values are
>>> not to be zero padded.
>>>>>>
>>>>>>> On 25 Jun 2024, at 15:22, Scott Johnson
>>> <sc...@spacelypackets.com> wrote:
>>>>>>>
>>>>>>> Hi Scott,
>>>>>>>
>>>>>>> Wire format of 64 bit unsigned integer it is for IPN.
>>>>>>> Updated draft (03) incorporating all changes posted
>>> at:
>>>>>>>
>>> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>>>>>>>
>>>>>>> Let me know if you see anything else, Mark, and
>>> thanks!
>>>>>>>
>>>>>>>
>>>>>>> ScottJ
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 24 Jun 2024, sburleig...@gmail.com wrote:
>>>>>>>
>>>>>>>> I've lost lock on the ipn-scheme RFC, but my own
>>> assessment is that always sending a single 64-bit unsigned
>>> integer would be fine. The application receiving the
>>> resource can figure out whether or not it wants to condense
>>> the value by representing it as two 32-bit integers in
>>> ASCII with leading zeroes suppressed and a period between
>>> the two. Internally it's always going to be a
>>> 64-bitunsigned integer, from which a 32-bit "allocator"
>>> number can be obtained by simply shifting 32 bits to the
>>> right; if the result is zero then we're looking at an
>>> old-style IPN node number.
>>>>>>>>
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Scott Johnson <sc...@spacelypackets.com>
>>>>>>>> Sent: Monday, June 24, 2024 8:26 PM
>>>>>>>> To: Mark Andrews <ma...@isc.org>;
>>> sburleig...@gmail.com
>>>>>>>> Cc: dnsop <dnsop@ietf.org>
>>>>>>>> Subject: Re: [DNSOP] IPN and CLA RRTYPEs to support
>>> Bundle Protocol RFC9171
>>>>>>>>
>>>>>>>> Hi Mark,
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 25 Jun 2024, at 10:32, Scott Johnson
>>> <sc...@spacelypackets.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Mark,
>>>>>>>>>>
>>>>>>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
>>>>>>>>>>
>>>>>>>>>>> An obvious correction “LTP--v6” -> “LTP-v6”
>>>>>>>>>>
>>>>>>>>>> Aha! Good eye.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For IPN why isn’t the wire format two network 64
>>> bit integers? That is 16 bytes. Also 2^64-1 is 20
>>> characters so 2 64-bit numbers separated by “." is 41
>>> characters. It’s not clear where then 21 comes from.
>>>>>>>>>>
>>>>>>>>>> EID is the basic unit of IPN naming, which is
>>> indeed two 64 bit integers separated by a ".". We are
>>> seeking to represent only the node-nbr component of an EID,
>>> as the service-nbr component is loosely analagous to a UDP
>>> or TCP port, for which there is one publicly defined
>>> service in the registry, and a collection of space agencies
>>> who lay claim to another chunk of them:
>>>>>>>>>>
>>> https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-service-
>> num
>>>>>>>>>> bers As such, there is no gain in including the
>>> second 64-bit
>>>>>>>>>> integer, representing service-nbr in the DNS
>>> records, and indeed, a loss of utility on the application
>>> level.
>>>>>>>>>>
>>>>>>>>>> The node-nbr component is presently, under RFC7116,
>>> a 64 bit unsigned integer. There is a draft from the DTN
>>> WG currently making it's way through the IESG which will
>>> amend the IPN naming scheme. Perhaps I should add it to
>>> normative references?
>>>>>>>>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/
>>>>>>>>>>
>>>>>>>>>> In effect it splits the node-nbr component into
>>> two-32 bit integers; Allocator Identifier and Node Number
>>> in the "Three-Element Scheme-Specific Encoding" of Section
>>> 6.1.2 over the above. Section 6.1.1 describes the
>>> "Two-Element Scheme-Specific Encoding" method which retains
>>> the use of a single 64-bit integer. Thus, a single 64 bit
>>> integer (20 characters) or two 32-bit integers (10
>>> characters each) delimited by a "."
>>>>>>>>>> makes 21 characters maximum. This preserves
>>> forwards compatibility with the proposed amended scheme,
>>> and does no harm if the scheme fails to achieve
>>> standardization.
>>>>>>>>>
>>>>>>>>> Or just 8 bytes on the wire with both possible input
>>> formats described.
>>>>>>>>> Machines using the records will just be converting
>>> ASCII values to a
>>>>>>>>> 64 bit integer. We may as well transmit it as
>>> that. Input validation
>>>>>>>>> will need to do the conversion anyway to ensure both
>>> fields will fit
>>>>>>>>> into 32 bits in the “.” separated case and 64 bits
>>> in the single value case.
>>>>>>>>> Length along is not sufficient to prevent undetected
>>> overflows. The
>>>>>>>>> only thing you need to determine is which format is
>>> the initial
>>>>>>>>> canonical presentation format. That can be changed
>>> with a later
>>>>>>>>> update if needed.
>>>>>>>>
>>>>>>>> I am tagging in Scott Burleigh, co-author of RFC9171
>>> on this point for clarification.
>>>>>>>> Section 4.2.5.1.2 of same indicates:
>>>>>>>>
>>>>>>>> "Encoding considerations:
>>>>>>>> For transmission as a BP endpoint ID, the
>>> scheme-specific part of a URI of the ipn scheme SHALL be
>>> represented as a CBOR array comprising two items. The first
>>> item of this array SHALL be the EID's node number (a number
>>> that identifies the node) represented as a CBOR unsigned
>>> integer.
>>>>>>>> The second item of this array SHALL be the EID's
>>> service number (a number that identifies some application
>>> service) represented as a CBOR unsigned integer. For all
>>> other purposes, URIs of the ipn scheme are encoded
>>> exclusively in US-ASCII characters."
>>>>>>>>
>>>>>>>> Having already established that we are transmitting
>>> the node-nbr component only, and not a full EID, I am not
>>> sure we are restricted to using only US-ASCII. ScottB,
>>> your opinion? CBOR might also be an option, but that would
>>> place a higher burden upon implementers, I think. Integer
>>> notation for wire format is fine by me.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Limit CLA characters to Letter Digit Hyphen rather
>>> than the full ASCII range.
>>>>>>>>>>
>>>>>>>>>> It is possible for a node to support multiple CLAs
>>> on the same IP
>>>>>>>>>> address and node number. Will this change allow
>>> multiple, comma
>>>>>>>>>> delimited values to be expressed in the CLA
>>> record? If so, can you
>>>>>>>>>> point me to an example so I can get the verbiage of
>>> the draft right?
>>>>>>>>>> If not, what do you recommend (in addition to my
>>> defining that in the
>>>>>>>>>> draft)? I like the idea of limiting the usable
>>> characters.
>>>>>>>>>
>>>>>>>>> Personally I would just use a TXT record wire format
>>> with the
>>>>>>>>> additional constraint that the values are restricted
>>> to Letter, Digits
>>>>>>>>> and interior Hyphens. The input format matches the
>>> TXT record with
>>>>>>>>> the above character value constraints. The
>>> canonical presentation
>>>>>>>>> form is space separated, unquoted, unescaped ASCII.
>>> This allow for
>>>>>>>>> long records to be split over multiple lines.
>>> Descriptive comments in the zone file.
>>>>>>>>> This take one extra octet over using comma separated
>>> values.
>>>>>>>>
>>>>>>>> Sold to the man from ISC :) This part works great;
>>> thank you! Updated draft pushed to datatracker at
>>> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Scott
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> e.g.
>>>>>>>>>
>>>>>>>>> example inputs
>>>>>>>>>
>>>>>>>>> @ CLA ( TCP-V4 ; TCP over IPv4
>>>>>>>>> TCP-V6 ) ; TCP over IPv6
>>>>>>>>>
>>>>>>>>> @ CLA “TCP-V4” TCP-V6
>>>>>>>>>
>>>>>>>>> Wire
>>>>>>>>>
>>>>>>>>> 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’ ‘4’ 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’
>>> ‘6’
>>>>>>>>>
>>>>>>>>> Canonical presentation
>>>>>>>>>
>>>>>>>>> @ CLA TCP-V4 TCP-V6
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Scott
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Mark
>>>>>>>>>>>
>>>>>>>>>>>> On 25 Jun 2024, at 08:19, Scott Johnson
>>> <sc...@spacelypackets.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> After reading the recent discussion about WALLET,
>>> I am hesitant to jump into the fray here, but this plainly
>>> is the correct group to help me get my logic and syntax
>>> right, so here goes:
>>>>>>>>>>>>
>>>>>>>>>>>> I submitted requests to IANA for IPN and CLA
>>> RRTYPEs, these representing the missing datasets necessary
>>> to make a BP overlay network connection from data found by
>>> DNS queries.
>>>>>>>>>>>>
>>>>>>>>>>>> For those not familiar, BP is a store and forward
>>> mechanism generally used in high latency situations where
>>> there does not exist constant end-to-end connectivity. It
>>> was designed for deep space networking, however has network
>>> segments and application uses which overlay the terrestrial
>>> Internet. There will arise similar use cases on the Moon
>>> (in the reasonably near future) and Mars whereby low
>>> latency, constant connectivity exists, thereby making use
>>> of DNS in these situations viable.
>>>>>>>>>>>>
>>>>>>>>>>>> My Expert Reviewer asked for an i-d, to clarify
>>> the requests, and that said i-d be sent to this list for
>>> review.
>>>>>>>>>>>>
>>>>>>>>>>>> Please find the approptiate draft here:
>>>>>>>>>>>>
>>> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>>>>>>>>>>>>
>>>>>>>>>>>> Relevant IANA requests:
>>>>>>>>>>>>
>>> https://tools.iana.org/public-view/viewticket/1364843
>>>>>>>>>>>>
>>> https://tools.iana.org/public-view/viewticket/1364844
>>>>>>>>>>>>
>>>>>>>>>>>> I have the BP community also reviewing this, but
>>> they are generally in agreement as to use.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Scott M. Johnson
>>>>>>>>>>>> Spacely Packets, LLC
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> DNSOP mailing list -- dnsop@ietf.org To
>>> unsubscribe send an email
>>>>>>>>>>>> to dnsop-le...@ietf.org
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Mark Andrews, ISC
>>>>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>>>>>>> PHONE: +61 2 9871 4742 INTERNET:
>>> ma...@isc.org
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> DNSOP mailing list -- dnsop@ietf.org To
>>> unsubscribe send an email to
>>>>>>>>>>> dnsop-le...@ietf.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Mark Andrews, ISC
>>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>>>>> PHONE: +61 2 9871 4742 INTERNET:
>>> ma...@isc.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> DNSOP mailing list -- dnsop@ietf.org
>>>>>>>> To unsubscribe send an email to dnsop-le...@ietf.org
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mark Andrews, ISC
>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>> PHONE: +61 2 9871 4742 INTERNET:
>>> ma...@isc.org
>>>>>>
>>>>>> _______________________________________________
>>>>>> DNSOP mailing list -- dnsop@ietf.org
>>>>>> To unsubscribe send an email to dnsop-le...@ietf.org
>>>>
>>>>
>>>> --
>>>> Mark Andrews, ISC
>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>> PHONE: +61 2 9871 4742 INTERNET:
>>> ma...@isc.org
>>>>
>>>> _______________________________________________
>>>> DNSOP mailing list -- dnsop@ietf.org
>>>> To unsubscribe send an email to
>>> dnsop-
>> leave@ietf.org_______________________________________________
>>> DNSOP mailing list -- dnsop@ietf.org
>>> To unsubscribe send an email to dnsop-le...@ietf.org
>>>
>>>
>>>
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
