On 7/12/13 8:19 AM, Warren Kumari wrote:
On Jul 8, 2013, at 3:32 PM, Patrik Fältström wrote:
On 8 jul 2013, at 20:49, "Dickson, Brian" wrote:
However, maybe something like a "PNS" (parent NS) in the child, where the
child is authoritative for the data, could signal {change | validation}
(d
On Jul 8, 2013, at 3:32 PM, Patrik Fältström wrote:
>
> On 8 jul 2013, at 20:49, "Dickson, Brian" wrote:
>
>> However, maybe something like a "PNS" (parent NS) in the child, where the
>> child is authoritative for the data, could signal {change | validation}
>> (depending on the RRR requireme
Hello for the first time!
I'm a bit new to this IETF stuff, but a
long time "participant" in the world of DNS. I was pointed to this
list by a friend, and in reading some of the more recent threads I felt
compelled to jump in (I hope this sort of participation is copacetic).
On Tue, 9 Jul 20
On 8 Jul 2013, at 18:03, Olafur Gudmundsson wrote:
> John,
>
> Thanks for a excellent and timely review we just about pushing out a new
> version when it arrived.
>
> We have accepted most of your edits and suggestions except when the text was
> already removed/reworded.
>
> Instead I wan
On Jul 11, 2013, at 3:54 AM, Antoin Verschuren
wrote:
> I've given Ed's words a really good thought, and slept a night over it.
> I think the reason why some of us don't feel comfortable with many of
> the assumptions in our requirements is because we try to avoid a
> framework we as technician
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Op 10-07-13 15:19, Edward Lewis schreef:
> These are concerns that are not well defined and I've off and on
> tried to find a more rigorous framework from which to hang them.
> But Antoin sums up the "operator" view that - the world is more
> complica
On Tue, 9 Jul 2013, Dickson, Brian wrote:
to a different set, tools are likely better than doing it manually. CDS
addresses the DS/DNSKEY part, but leaves the NS part unchanged.
It's a problem which I presume exists or might exist, which goes along
with the CDS problem: how do you automate "X",
On Wed, 10 Jul 2013, Edward Lewis wrote:
These are concerns that are not well defined and I've off and on tried to find a more
rigorous framework from which to hang them. But Antoin sums up the "operator"
view that - the world is more complicated than a simple solution away from
completeness.
On Jul 9, 2013, at 3:46, Antoin Verschuren wrote:
> I know you all wish the world was simpler, but it isn't, We've tried.
I'd voiced support for CDS before and have even gone as far as visiting with
Olafur and Warren to work on the mechanism.
But since the last conversation, I'm not as optimis
On 7/8/13 9:39 PM, "Andrew Sullivan" wrote:
>On Mon, Jul 08, 2013 at 06:49:53PM +, Dickson, Brian wrote:
>>
>> Thoughts?
>
>My immediate thought is, "What problem is this trying to solve?"
Automating NS changes on the parent side, via child-signed-and-signalled
in-zone data. If the CDS keys
On Jul 9, 2013, at 5:56 AM, Antoin Verschuren wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Op 09-07-13 10:05, Patrik Fältström schreef:
>>
>> The registry get an EPP update via a secure channel to change the
>> NS. They can at that time (before the new zone is published) issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Op 09-07-13 10:05, Patrik Fältström schreef:
>
> The registry get an EPP update via a secure channel to change the
> NS. They can at that time (before the new zone is published) issue
> queries for CDS at the suggested new target of the NS, and if the
On 9 jul 2013, at 09:46, Antoin Verschuren wrote:
> Signed PGP part
> Op 08-07-13 20:28, Patrik Fältström schreef:
>
> > One such situation is what is to happen when NS records changes in
> > the parent zone.
> >
> > An immediate reaction is that change of NS records should trigger
> > fetch o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Op 08-07-13 20:49, Dickson, Brian schreef:
> Upon receiving a change request for the NS set, the zone publisher
> could check the child for matching PNS records.
>
> Facilitates automation, just as CDS would.
>
> Thoughts?
That's why I said I liked
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Op 08-07-13 20:28, Patrik Fältström schreef:
> One such situation is what is to happen when NS records changes in
> the parent zone.
>
> An immediate reaction is that change of NS records should trigger
> fetch of CDS record from the child zone so th
On Mon, Jul 08, 2013 at 06:49:53PM +, Dickson, Brian wrote:
>
> Thoughts?
My immediate thought is, "What problem is this trying to solve?"
In the DNSSSEC case, the problem is that you're trying not to break
the chain of trust, and you need a mechanism that is cryptographically
securable to m
On 8 jul 2013, at 20:49, "Dickson, Brian" wrote:
> However, maybe something like a "PNS" (parent NS) in the child, where the
> child is authoritative for the data, could signal {change | validation}
> (depending on the RRR requirements), would do the trick?
Might solve some events, but I do not
On 7/8/13 2:28 PM, "Patrik Fältström" wrote:
>I have also had a look at this document which I in general do believe is
>sound, although there are a few events I would like to have described in
>the document. Reason for this is that I see it being really important
>that it is implemented the sam
I have also had a look at this document which I in general do believe is sound,
although there are a few events I would like to have described in the document.
Reason for this is that I see it being really important that it is implemented
the same way in all usage scenarios.
One such situation
John,
Thanks for a excellent and timely review we just about pushing out a new
version when it arrived.
We have accepted most of your edits and suggestions except when the text was
already removed/reworded.
Instead I want to focus on your Q1: "How will a ``Child'' know if the
``Parent'' is
Hi,
I have read draft draft-kumari-ogud-dnsop-cds-02. (Unfortunately, I have not
had time to read all the on list discussion, so apologies if I duplicate
comments)
IMHO:
Section 1.2 and 2.2.1 (Highlighted roles) should be combined and used
consistently through-out.
Section 2.1 refers to part
On Jul 1, 2013, at 9:25 AM, Matthijs Mekking wrote:
> Hi Olafur,
>
> On 06/28/2013 08:18 PM, Olafur Gudmundsson wrote:
>>
>> On Jun 25, 2013, at 6:05 AM, Matthijs Mekking wrote:
>>
>>>
>>> * Nit: In section 1, it says there may be two interactions with the
>>> parent. This could also be onl
On Jun 17, 2013, at 1:32 PM, Warren Kumari wrote:
> Hi there all,
>
> We have just posted a new version of draft-kumari-ogud-dnsop-cds
>
> This incorporates comments from both the list and in person discussions.
>
> The authors believe this version is ready for WG adoption and request the
Hi Olafur,
On 06/28/2013 08:18 PM, Olafur Gudmundsson wrote:
>
> On Jun 25, 2013, at 6:05 AM, Matthijs Mekking wrote:
>
>> Hi,
>>
>> On 06/21/2013 11:58 PM, Wes Hardaker wrote:
>>> Paul Wouters writes:
>>>
I am in favour of adopting this draft as a WG item.
>>>
>>> Ditto.
>>
>> Another di
On Jun 25, 2013, at 6:05 AM, Matthijs Mekking wrote:
> Hi,
>
> On 06/21/2013 11:58 PM, Wes Hardaker wrote:
>> Paul Wouters writes:
>>
>>> I am in favour of adopting this draft as a WG item.
>>
>> Ditto.
>
> Another ditto. I am pleased to see that there is still activity on the
> topic of au
On Jun 27, 2013, at 9:02 AM, Edward Lewis wrote:
> In the land of looking for support to take this on, the WG should. Adoption
> by the WG or not, I'm taking this seriously and will help engineer this
> through to solution.
Thank you.
Now we just need the chairs to wave the terrible thurib
In the land of looking for support to take this on, the WG should. Adoption by
the WG or not, I'm taking this seriously and will help engineer this through to
solution.
On Jun 17, 2013, at 13:32, Warren Kumari wrote:
> Hi there all,
>
> We have just posted a new version of draft-kumari-ogud-d
On Jun 25, 2013, at 6:05 AM, Matthijs Mekking wrote:
> Hi,
>
> On 06/21/2013 11:58 PM, Wes Hardaker wrote:
>> Paul Wouters writes:
>>
>>> I am in favour of adopting this draft as a WG item.
>>
>> Ditto.
>
> Another ditto. I am pleased to see that there is still activity on the
> topic of au
28 matches
Mail list logo
