Hello dnsop and v6ops,
I've written a draft that proposes updates to RFC 7050, which defined the
mechanism for discovering the network's IPv6 translation prefix using a DNS
query for ipv4only.arpa. RFC 7050 also defined "secure channel" such that
clients SHOULD use IPsec or similar to secure co
On Tue, 25 Jun 2024, Warren Kumari wrote:
This errata is correct.
Doh! Yes, it is…
Paul, would you mind being the one to mark it as Verified? I'm an author, and
while I don't really
see a much conflict of interest for an AD to mark an errata as verified, it's
probably cleaner if
some
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.
Hi Marc,
I agree with using DNS-SD instead. I for one, also suggested that years
ago.
Of course, you are free to use DNS-SD instead. What you choose to publish
in your zone files is your administrative perogative. One can presently
use either SLAAC or DHCPv6, or manual assignment to deploy
Hi Brian,
On Tue, 25 Jun 2024, Sipos, Brian J. wrote:
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 "
Hi Rick,
On Tue, 25 Jun 2024, Rick Taylor wrote:
Hi Scott,
Thanks for publishing this doc, it looks really interesting.
You are welcome. Thanks for taking the time to review.
One thing I am unclear about is what is the purpose of having a DNS
record mapping a dtn or ipn Node ID to an IP
The following errata report has been verified for RFC7344,
"Automating DNSSEC Delegation Trust Maintenance".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7997
--
Status: Verified
Type: Tech
> Le 25 juin 2024 à 10:29, Sipos, Brian J. 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 v
On Fri, Jun 21, 2024 at 11:13 PM, Paul Wouters wrote:
> This errata is correct.
>
> Paul
>
Doh! Yes, it is…
Paul, would you mind being the one to mark it as Verified? I'm an author,
and while I don't really see a much conflict of interest for an AD to mark
an errata as verified, it's probably
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
capabi
Hi Scott,
Thanks for publishing this doc, it looks really interesting.
One thing I am unclear about is what is the purpose of having a DNS record
mapping a dtn or ipn Node ID to an IP address. Is it so that 'routing' lookups
can be performed at BPAs when a next hop for a particular EID is not
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
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
wrote:
> Hi Mark,
>
> On Tue, 25 Jun 2024, Mark Andrews wrote:
>
> >
> >
> >> On 25 Jun 2024,
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
14 matches
Mail list logo
