Warren,
I am still wondering about the:
3 * (DNSKEY RRSIG Signature Validity) / 2
Term in the draft, which I see survived the update.
Why is this not just the DNSKEY RRSIG Signature Validity? In principle
once the signature has expired it cannot be used to replay the old
DNSKEY RRset right?
On Fri, Feb 3, 2017 at 9:14 PM, Warren Kumari wrote:
> Hi all,
>
> Was and I have updated this document to make it clearer and more
> readable. Please take a read and let us know if any parts are unclear,
> if you have any other feedback, etc.
>
> Is this close to done?
> W
>
> On Fri, Feb 3, 201
Ted,
What RFC are you referring to?
Why do you think .ARPA is for services?
It's for infrastructure and homenet wants to join the infrastructure.
It is waste of time arguing if name A or B is better take the one you can get
faster.
Ólafur
On February 5, 2017 10:22:35 PM CST, Ted Lemon wrote
> On 6 Feb 2017, at 15:29, Ólafur Gudmundsson wrote:
>
> It is waste of time arguing if name A or B is better take the one you can get
> faster.
+100
Says he wishing the arguments over A or B (for some definition of both) would
just go away and never return.
> On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson wrote:
>
> Ted,
>
> What RFC are you referring to?
>
> Why do you think .ARPA is for services?
> It's for infrastructure and homenet wants to join the infrastructure.
>
> It is waste of time arguing if name A or B is better take the one you c
On 06/02/2017 15:29, Ólafur Gudmundsson wrote:
> Ted,
>
> What RFC are you referring to?
>
> Why do you think .ARPA is for services?
> It's for infrastructure and homenet wants to join the infrastructure.
>
> It is waste of time arguing if name A or B is better take the one you
> can get faste
Ralph,
A WG can come to a consensus on a topic without all information available.
Now go back and see if reality changes consensus.
Just my .02 cents.
Ólafur
On February 6, 2017 9:52:53 AM CST, Ralph Droms wrote:
>
>
>> On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson
>wrote:
>>
>> Ted,
>>
On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson wrote:
> What RFC are you referring to?
I wasn't referring to an RFC—I was referring to the homenet naming architecture
document that we've been working on.
> Why do you think .ARPA is for services?
> It's for infrastructure and homenet wants to j
On Feb 6, 2017, at 10:57 AM, Ólafur Gudmundsson wrote:
> A WG can come to a consensus on a topic without all information available.
> Now go back and see if reality changes consensus.
I presented a detailed explanation of the tradeoffs, which the working group
considered. If you think somethin
On 02/06/2017 01:11 PM, Shane Kerr wrote:
> Warren,
>
> I am still wondering about the:
>
>3 * (DNSKEY RRSIG Signature Validity) / 2
>
> Term in the draft, which I see survived the update.
>
> Why is this not just the DNSKEY RRSIG Signature Validity? In principle
> once the signature has ex
On 06/02/2017 16:12, Suzanne Woolf wrote:
> Hi,
>
> Before this goes any further, I’m not sure an incomplete rehashing of
> the consensus in another WG is a good use of our time.
+1 :)
> For now, let’s keep it relevant to the decision this WG has to make,
> about what to do with .alt and wheth
Hi,
Before this goes any further, I’m not sure an incomplete rehashing of the
consensus in another WG is a good use of our time.
For now, let’s keep it relevant to the decision this WG has to make, about what
to do with .alt and whether it’s important to us to accommodate cases like
.homenet.
> On Feb 6, 2017, at 11:15 AM, Ray Bellis wrote:
>
>> For now, let’s keep it relevant to the decision this WG has to make,
>> about what to do with .alt and whether it’s important to us to
>> accommodate cases like .homenet. So far, it seems that the .homenet case
>> is much like “locally-served
On 06/02/2017 16:18, Suzanne Woolf wrote:
>> Yes, that's right, with the caveat that all existing locally
>> served zones are in the reverse space - there's no forward zones
>> registered (yet).
>
> Could you clarify why that’s relevant?
>
> Does it just come down to the assumption that revers
On 2 Feb 2017, at 13:48, Suzanne Woolf wrote:
>> (Webex details will follow)
This Webex will be recorded for those of us who cannot attend, yes?
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Ray Bellis wrote:
>
> Yes, that's right, with the caveat that all existing locally served
> zones are in the reverse space - there's no forward zones registered (yet).
There are several :-) RFC 6761 specifies localhost, invalid, test as
locally served zones. RFC 6762 specifies local. RFC 7686 spe
In article you write:
>> Yes, that's right, with the caveat that all existing locally served
>> zones are in the reverse space - there's no forward zones registered (yet).
>
>Could you clarify why that�s relevant?
Perhaps because the management rules follow more or less mechanically
from the mana
On 06/02/2017 16:55, Tony Finch wrote:
> Ray Bellis wrote:
>>
>> Yes, that's right, with the caveat that all existing locally served
>> zones are in the reverse space - there's no forward zones registered (yet).
>
> There are several :-) RFC 6761 specifies localhost, invalid, test as
> locally
> This message opens a Working Group Last Call for:
>
> "Special-Use Names Problem Statement"
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/
> Proposed status: informational
>
> Starts: 2 Feb. 2017
> Ends: 23 Feb. 2017 (3 weeks)
>
> Discussion should go to the mailing list.
>
>
Dear Olaf M. Kolkman, Matthijs Mekking, R. (Miek) Gieben:
An IPR disclosure that pertains to your RFC entitled "DNSSEC Operational
Practices, Version 2" (RFC6781) was submitted to the IETF Secretariat on
and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://
Thanks for your review and comments, Russ. I've extracted the issues from your
review and entered them in the GitHub issue tracker for the document.
- Ralph
> On Feb 6, 2017, at 2:21 PM, Russ Housley wrote:
>
>>
>> This message opens a Working Group Last Call for:
>>
>> "Special-Use Names P
> On Feb 3, 2017, at 9:10 PM, Andrew Sullivan wrote:
>
> On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote:
>> Mark, I don't think you've actually given an answer to my question.
>> I understood that .ALT was for alternative naming systems, not for
>> DNS locally-served zones. We simpl
In message <203e2636-1391-4100-9b1a-4f2dcc9a3...@gmail.com>, Ralph Droms writes:
>
> > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan wrote:
> >
> > On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote:
> >> Mark, I don't think you've actually given an answer to my question.
> >> I understoo
TL;DR: it is possible to have a signed DNAME in the root for alt (to
empty.as112.arpa), AND have a local signed alt. Things under this local alt
can be signed or unsigned.
On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews wrote:
>
> In message mail.gmail.com>
> , Brian Dickson writes:
> >
> >- I
> On 06/02/2017 16:55, Tony Finch wrote:
> > Ray Bellis wrote:
> >>
> >> Yes, that's right, with the caveat that all existing locally served
> >> zones are in the reverse space - there's no forward zones registered (yet).
> >
> > There are several :-) RFC 6761 specifies localhost, invalid, test as
In message
, Brian
Dickson writes:
>
> TL;DR: it is possible to have a signed DNAME in the root for alt (to
> empty.as112.arpa), AND have a local signed alt. Things under this local alt
> can be signed or unsigned.
So now there is the problem of distributing trust anchors for the
locally signe
Mark,
I don't think the use cases for most of the sandbox involving alt, and/or the
homenet use case, requires support for validating stubs. If stubs aren't
already validating, the incremental addition of a local alt, only requires
distribution of the trust anchor to the resolvers. That is a so
In message <3581be55-b178-4298-8ee8-73fd16b42...@gmail.com>, Brian Dickson
writes:
> Mark,
>
> I don't think the use cases for most of the sandbox involving alt, and/or
> the homenet use case, requires support for validating stubs. If stubs
> aren't already validating, the incremental addition
The suggestion of DNAME to empty.as112.arpa involves some subtle details, which
IMHO may in combination be the right mix here.
The DNAME target is an insecure empty zone.
This avoids the validation issue, and facilitates use of local "alt" namespaces.
The default response to queries under alt w
In message <99431a77-7b62-4655-89ef-faa32f2a8...@gmail.com>, Brian Dickson
writes:
> The suggestion of DNAME to empty.as112.arpa involves some subtle details,
> which IMHO may in combination be the right mix here.
>
> The DNAME target is an insecure empty zone.
>
> This avoids the validation issu
On Mon, Feb 6, 2017 at 11:27 PM, Mark Andrews wrote:
>
> In message <99431a77-7b62-4655-89ef-faa32f2a8...@gmail.com>, Brian
> Dickson writes:
> > The suggestion of DNAME to empty.as112.arpa involves some subtle details,
> > which IMHO may in combination be the right mix here.
> >
> > The DNAME ta
31 matches
Mail list logo
