Hi， Mukund, This is Johnson， I'm very sorry to cause you so much trouble. I think the draft of draft-muks-dns-message-fragments that you submitted to the IETF is quite interesting and shows the importance of dns packet fragmentation in th
Please help me return this to normal
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
was established by the holder of the
server’s private key
Why does my public IP address have me showing in new York city?
On Mon, Sep 18, 2023, 11:04 PM Paul Wouters wrote:
> On Mon, 18 Sep 2023, Von Johnson wrote:
>
> > Hello. Any updates?
>
> There will be no updates fr
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
ters.
Thanks,
Scott
Mark
On 25 Jun 2024, at 08:19, Scott Johnson 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 request
Hi Mark,
On Tue, 25 Jun 2024, Mark Andrews wrote:
On 25 Jun 2024, at 10:32, Scott Johnson 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
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
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? As well, should I be asking for WG adoption
Hi Mark,
On Tue, 25 Jun 2024, Mark Andrews wrote:
On 25 Jun 2024, at 16:36, Scott Johnson 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
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
al Message-
From: Scott Johnson [mailto:sc...@spacelypackets.com]
Sent: 25 June 2024 10:57
To: Erik Kline
Cc: dnsop; sburleig...@gmail.com; d...@ietf.org
Subject: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
Protocol RFC9171
Hi Erik,
Cross posted to DTN list for any such discussio
/www.rfc-editor.org/rfc/rfc9174.html#section-4.4.2
-Original Message-
From: Scott Johnson
Sent: Tuesday, June 25, 2024 5:57 AM
To: Erik Kline
Cc: dnsop ; sburleig...@gmail.com; d...@ietf.org
Subject: [EXT] [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
Protocol RFC9171
APL exte
itor.org/rfc/rfc9174.html#section-4.4.2
-Original Message-
From: Scott Johnson
Sent: Tuesday, June 25, 2024 5:57 AM
To: Erik Kline
Cc: dnsop ; sburleig...@gmail.com; d...@ietf.org
Subject: [EXT] [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
Protocol RFC9171
APL external ema
Hi All,
A new version of this draft (06) has been posted here:
https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
This includes edits from Scott Burleigh, as well as edits based on the
feedback from Brian and Rick, but for the references to specs for existing
CLAs in use in the wild
ScottJ
Rick
P.S. I'm sure Brian Sipos has a more flexible solution using his EID Patterns
under the `ipn.arpa` TLD, but I don't want to muddy the waters by trying to
introduce it now
-Original Message-
From: Scott Johnson [mailto:sc...@spacelypackets.com]
Sent: 26 June 2024
e Engineer; AX Enterprize, LLC
___
From: Rick Taylor
Sent: Wednesday, June 26, 2024 1:11 PM
To: Scott Johnson
Cc: Erik Kline ; dnsop ;
sburleig...@gmail.com ; d...@ietf.org
Subject: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bund
formation I placed in the
"Purpose" section of the draft, per your request, is all I am at liberty
and willing to disclose at this time.
Thanks,
ScottJ
Cheers,
Rick
-Original Message-
From: Scott Johnson [mailto:sc...@spacelypackets.com]
Sent: 26 June 2024 21:32
To
Hi Mark,
On Thu, 27 Jun 2024, Mark Andrews wrote:
I broached the possibility of CBOR in discussion on DNSOP before DTN
was CCed, making the above point to Scott Burleigh. Our conclusion
there, along with Mark Andrews, was that the current verbiage is the
current best course of action. I hav
Hi Paul,
Thanks for jumping in. Comments inline.
On Wed, 26 Jun 2024, Paul Vixie wrote:
Mark Andrews wrote on 2024-06-26 16:02:
...
Adding a new RRTYPE requires zero infrastructure upgrades. It’s a
database entry at IANA. Every DNS server on the planet should handle
these transpar
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
SRV 0 0 4556 host-b.example.com.
_ltp-deepspace._udp.host-b 86400 IN SRV 0 0 1113 host-b.example.com.
host-c 86400 IN A
host-c 86400 IN
_dtn-bundle._udp.host-c 86400 IN SRV 0 0 4556 host-c.example.com.
)
[RFC2782] https://www.rfc-editor.org/rfc/rfc2782.html
dtnrg-ipnd/),
I refreshed that draft when I completed updating the implementation to be
compliant with it.
https://datatracker.ietf.org/doc/draft-johnson-dtn-ipnd/
that
describes a peer discovery mechanism, not a CLA.
Agreed, but it is a mechanism that allows fully automated distributio
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
wrote:
Hi Rick,
As I have previously stated, I personally have lodged no
objection to
using CBOR
Hi All,
Please find a new version of this draft, revised per recommendations from
DNSOP and DTN members.
https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
I would be willing to entertain DTN WG taking up this document if there is
an alternate proposal for the syntax for CLA RRTYPE
exact venue for WG
adoption, given the scope of the concepts. As such will I refrain from
asking for WG adoption at this time, pending discussion from the DTN and
DNS communities.
Please find the draft here:
https://datatracker.ietf.org/doc/draft-johnson-interplanetary-dns/
I would also be
something else to do with my time, but for now, I manage to feed my kids
with pure research and development like this, so I think I am going to
keep at it ;)
Thanks,
ScottJ
--Ben
___
From: Nordgren, Bryce - FS, MT
Sent: M
e land and serving people
_______
From: Scott Johnson
Sent: Monday, July 22, 2024 3:00 AM
To: d...@ietf.org ; dnsop@ietf.org
Cc: ipnsig...@googlegroups.com ;
awg-ipn...@googlegroups.com
Subject: [dtn] An Interplanetary DNS Model
Hi Everyone,
Sorry for the 4-way cross posting, but I wanted to r
rification.
ScottJ
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
On 22. 7. 2024, at 14:25, Scott Johnson wrote:
Hi Bryce,
Interesting. This is the second r
Hi Lorenzo,
I may have accidentally trimmed the lists from my previous reply, thanks
for reincluding them!
On Tue, 23 Jul 2024, Lorenzo Breda wrote:
Il giorno mar 23 lug 2024 alle ore 08:16 Scott Johnson
ha scritto:
Hi Lorenzo,
On Mon, 22 Jul 2024, Lorenzo Breda wrote
ad of time, because I know what is coming ;)
ScottJ
--Ben
___
From: Scott Johnson
Sent: Wednesday, July 24, 2024 3:02 AM
To: Lorenzo Breda
Cc: d...@ietf.org ; dnsop@ietf.org
Subject: [DNSOP] Re: An Interplanetary DNS Model
Hi Lorenzo,
On Wed, 24 Jul 2024, Lorenzo Breda wrote:
Il giorno mer 24 lug 2024 alle ore 09:02 Scott Johnson
ha scritto:
Hi Lorenzo,
[omissis]
Pardon the background tangent;
It was pretty interesting.
Glad you enjoyed it.
I will now address your point regarding
Hi Marc,
On Wed, 24 Jul 2024, Marc Blanchet wrote:
Le 24 juill. 2024 à 11:42, Lorenzo Breda
a écrit :
Why are you against leaving the current TLDs implicitly on Earth
by default?
Right. One do not need a special TLD for space. We can use what we have
and it just works fine.
Hi Lorenzo,
On Wed, 24 Jul 2024, Lorenzo Breda wrote:
Il giorno mer 24 lug 2024 alle ore 22:24 Scott Johnson
ha scritto:
> it would
> be break signatures (eg on API payloads and on emails,
Funny you should mention email, as I am in the process of
construc
Hi Marc,
Why are you against leaving the current TLDs implicitly on Earth
by default?
Right. One do not need a special TLD for space. We can use what we have and it
just works fine.
I do not disagree with this notion as respects my proposed
architecture. 3rd level domains mapped to off-worl
Hi Lorenzo,
OK. I will ruminate on this for a bit. I think it will be workable, but
I need to examine system-wide ramifications before I can confirm that.
Thanks,
ScottJ
On Thu, 25 Jul 2024, Lorenzo Breda wrote:
It interacts with other email system as a regular email (with some
signatur
rum-TLS-BR-2.0.5.pdf
-Original Message-
From: Scott Johnson
Sent: Wednesday, July 24, 2024 4:44 PM
To: Marc Blanchet
Cc: Lorenzo Breda ; DTN WG ; dnsop
Subject: [EXT] [dtn] Re: [DNSOP] An Interplanetary DNS Model
APL external email warning: Verify sender forwardingalgori...@ietf.org befor
nt meaning
though). The DNS already provides a facility to have human-facing relative/unqualified
names while the tools resolve to and manage qualified names, so there isn't a need for
new terms or techniques here.
-Original Message-----
From: Scott Johnson
Sent: Thursday, July 25, 2
rely
on it to validate other RRSIGs for the entire 3600 seconds?
-Nick Johnson
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> current time.
>
> That last bullet point tells that if the signature's expiration time is
> smaller than the TTLs received in the response, the RRset is cached for
> at most the duration until the signature expires.
>
> On 7/24/19 7:50 AM, Nick Johnson wrote:
> &
istence?
For example, if I want to prove the nonexistence of a.b.c.example, isn't it
sufficient to validate an NSEC3 record that covers that name and is one
level higher (eg, somehash.b.c.example)? Why do I need to prove the
closest-encloser with a secon
On Fri, Oct 9, 2020 at 1:59 PM Shumon Huque wrote:
> On Thu, Oct 8, 2020 at 7:46 PM Nick Johnson 40ethereum@dmarc.ietf.org> wrote:
>
>> I'm reading RFC 5155, and I'm a bit puzzled by the requirement for
>> "closest encloser" proofs to prove nonexi
No, I left out RFCs only referenced by "obsoletes" metadata.
On Wed, 25 Apr 2018, 13:11 Paul Wouters, wrote:
>
>
> On Apr 25, 2018, at 06:37, Nick Johnson wrote:
>
>
> So I threw together a quick script
> <https://gist.github.com/Arachnid/c51b450b0c80eb2
Just discovered it lacks RFCs 4035 and 5702 as well. So it's definitely on
the conservative side.
On Wed, Apr 25, 2018 at 2:38 PM Paul Wouters wrote:
> On Wed, 25 Apr 2018, Nick Johnson wrote:
>
> > No, I left out RFCs only referenced by "obsoletes" metadata.
rary messages using their keys.
Are there domains that are globally reserved for the operator across all
TLDs? If not, does anyone have any recommendations on an alternative
authorisation or authentication mechanism?
-Nick Johnson
___
DNSOP mailing list
DNSOP
On Fri, Jun 14, 2019 at 2:30 PM Joe Abley wrote:
> On Jun 13, 2019, at 22:18, Nick Johnson
> wrote:
>
> > I'm working on a system that needs to authenticate a TLD owner/operator
> in order to take specific actions.
>
> Can you give an example of the actions?
&g
On Fri, Jun 14, 2019 at 2:51 PM Rubens Kuhl wrote:
>
>
> On 13 Jun 2019, at 23:18, Nick Johnson
> wrote:
>
> I'm working on a system that needs to authenticate a TLD owner/operator in
> order to take specific actions. We had intended to handle this by requiring
>
On Fri, Jun 14, 2019 at 3:02 PM Rubens Kuhl wrote:
>
>
> On 13 Jun 2019, at 23:56, Nick Johnson wrote:
>
> On Fri, Jun 14, 2019 at 2:51 PM Rubens Kuhl wrote:
>
>>
>>
>> On 13 Jun 2019, at 23:18, Nick Johnson <
>> nick=40ethereum@dmarc.ietf.o
On Fri, Jun 14, 2019 at 7:12 PM Shane Kerr
wrote:
> Nick,
>
> On 14/06/2019 04.18, Nick Johnson wrote:
> > I'm working on a system that needs to authenticate a TLD owner/operator
> > in order to take specific actions. We had intended to handle this by
> > requir
On Tue, Jun 18, 2019 at 10:15 PM Bjarni Rúnar Einarsson
wrote:
> The SOA record for a TLD contains two DNS names which should be
> under the control of the NIC: that of the primary master
> nameserver, and the e-mail of the responsible administrator
> (which includes a domain name).
>
This seems
49 matches
Mail list logo
