Some users seem to need an invitation to join this Slack instance. If you'd
like to be added, please email me off-list.
--Ben
From: Ben Schwartz
Sent: Friday, June 28, 2024 2:23 PM
To: DNSOP Working Group
Cc: shane.k...@ibm.com
Subject: [DNSOP] Re: Side Meetin
Clarification: while you may use your Datatracker login email to make an
account on the IETF Slack, this Slack instance is not connected to the
Datatracker. You can use any of the offered login flows to connect.
--Ben
From: Ben Schwartz
Sent: Friday, June 28, 20
Hi DNSOP,
The practice of DNS Load Balancing -- sending different answers to different
resolvers to optimize latency and avoid overload -- has been around for at
least 25 years, and remains as popular as ever. It's never really been
supported in the DNS standards though, and it particularly co
On Jun 26, 2024, at 13:31, James Mitchell wrote:
>
> Please find my comments below.
Thanks for the review, James. These all seem easy to deal with. Of particular
note:
> Looking ahead to the addition of the PublicKey element, we discussed whether
> to publish the PublicKey element for histo
Dear Tim Wicinski,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
dnsop Session 1 (1:30 requested)
Monday, 22 July 2024, Session III 1530-1700 America/Vancouver
Room Name: Regency C/D [Breakout
Scott et al,
After mulling it over for a little bit, I think your CLA-visibility need might
be met by using existing per-host SRV records. For what it's worth, I had the
same logical issue with how the original IPND drafts parameterize and expose
CLAs so my concern isn't specific to what you have d
+1
From: Jorge Amodio [mailto:jmamo...@gmail.com]
Sent: 28 June 2024 13:09
To: Scott Johnson
Cc: Rick Taylor; Erik Kline; dnsop; sburleig...@gmail.com; d...@ietf.org
Subject: Re: [dtn] Re: [DNSOP] Re: Re: Re: Re: Re: IPN and CLA RRTYPEs to
support Bundle Protocol RFC9171
Hi Scott,
Just a sugge
Hi Scott,
I think we are talking at cross-purposes.
I have no criticism of the valiant work you have done, and the circuitous route
you have been forced to follow to get to this point. The IETF needs more
people with your 'can do' attitude, it will help all of us meet our endlessly
slipping W
Hi Scott,
Just a suggestion, why not request a time slot during the next IETF WG
meeting and put together a brief presentation including some basic examples
showing how applications will benefit using this proposed DNS based
solution ?
Regards
Jorge
On Fri, Jun 28, 2024 at 4:12 AM Scott Johnson
Hi Alberto,
Like Scott B, I’m not going to “die on this hill”, but my issue is that an FQNN
is soon to no longer be semantically 1 integer, but 2.
I take the point that to enable compatibility with existing implementations,
the ipn-update (see
https://www.ietf.org/archive/id/draft-ietf-dtn-ipn
FWIW;
I support Scott’s view. Returning the FQNN (integer) is probably the best way
forward.
Rergards;
Alberto
From: sburleig...@gmail.com
Date: Thursday, June 27, 2024 at 1:07 PM
To: 'Rick Taylor' , 'Scott Johnson'
, 'Mark Andrews'
Cc: 'Erik Kline' , 'dnsop' , d...@ietf.org
Subject: [dtn]
Hi Rick,
As I have previously stated, I personally have lodged no objection to
using CBOR encoding of (node-nbr) in this case, and actually mentioned the
option myself. Here is the situation as I see it:
I have requested the creation in the IANA database of the IPN and CLA
RRTYPEs, by the m
I would strongly support what ScottJ has proposed, I would even say that
this is very pragmatic way to go forward. These new RRTYPEs make everything
quite clean (towards Bundle Protocol's integration as first class
citizen?). Even if not all DNS immediately support, most important thing is
what we
13 matches
Mail list logo
