I have opened a pull request for this change:
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/127
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Fri, Mar 30, 2018 at 1:47 AM, Yoshiro YONEYA
wrote:
> Hi Shumon,
>
> Thank you for starting good document.
> I think this document is also useful for DNS provider transfer (or
> Registrar transfer) without causing DNSSEC insecure state. Good
> thing is that this document doesn't depend on EPP
Dear colleagues,
ICANN’s Office of the CTO is pleased to announce that IDS 2018 will be held
Friday, 13 July 2018 in Montreal, Quebec, Canada. (IETF102 is scheduled for the
following week in Montreal.)
The theme for the IDS 2018 is: “Attention, Domain Name System: Your 30 year
scheduled mainte
Folks,
With the latest round of tweaks, I think the next version of the draft
will be essentially complete.
Except for needing to cover URI RRsets (RFC7553).
Unfortunately I'm stumped and am not sure what text to include to handle
it. Help!
The 'global' (right-most) label appears to be pe
Tony Finch wrote:
Phillip Hallam-Baker wrote:
So don't you dare claim that software updates are essential, that is an
ideological position learned from a limited set of experience.
...
devices which cannot be updated by their makers must expire. see:
http://geer.tinho.net/geer.blackhat.
Phillip Hallam-Baker wrote:
> So don't you dare claim that software updates are essential, that is an
> ideological position learned from a limited set of experience.
My position is that software updates extend the lifetime of a device. If a
device depends on external services then there's no wa
On Fri, Mar 30, 2018 at 1:23 AM, Stuart Cheshire wrote:
> On 29 Feb 2016, at 14:27, John R Levine wrote:
>
> > The existing port and service registry already has all of the _service
> names, and is updated as people invent new services. What's the benefit of
> duplicating it rather than just poi
It is a hard problem and it is possible that there is actually no solution.
All these systems consist of a chain or a graph of signed assertions. There
is no intrinsic ground truth in PKI. All that you can do is to define a
particular key or set of keys as producing the ground truth for your
parti
Michael StJohns wrote:
>
> There are three questions I have about your solution -
> 1) Do you expect it to be usable each time a device boots?
Yes.
(It's only necessary to consult the witnesses if the device's stored trust
anchor doesn't work, for whatever reason. This might include an incorrec
>
>
> Not quite.
>content-type: application/dns-udpwireformat; original_transport=tcp
>
Yes. That's right. I will give a example like that.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi Paul,
It sounds reasonable as we discussed before.
Best regards,
Davey
On 26 March 2018 at 13:48, Paul Hoffman wrote:
> Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining a
> new media type seems like overkill, particularly given that it will be
> transporting *the exact s
I can agree with the argument that if implemented in a major open-source
DNS implementation it would weigh in more to the discussion, but
limiting to is far too restricting in my opinion.
Best regards,
Matthijs
On 03/28/2018 09:48 PM, Mukund Sivaraman wrote:
On Wed, Mar 28, 2018 at 05:29:1
12 matches
Mail list logo
