Subject: [DNSOP] Moving parent-child-update documents forward

From: Dan York <[email-masked]>
Date: Wed, 6 Nov 2013 05:49:54 -0800

Peter & Tim,

Unfortunately we ran out of time in the DNSOP session yesterday and I don't
feel we left with a plan to move forward on the various
"parent-child-update" documents and scenarios.  However I think it is
*critical* that we DO move forward with these documents as this issue is
one of the big barriers for smoother operation of DNSSEC.

I think there was a strong sense in the room that we definitely need to
work on this overall issue and I think at the end we were getting hung up
on some process points (and I admit that *I* was contributing to that
confusion)... and then we simply ran out of time.

What do you see as a path forward here?  How can we progress these
documents?

The point I was trying to make in the final minutes was that we need
something *more* than just these documents to help get these solutions
actually out there and deployed.  I think we need to provide operational
guidance to registrars and registries on the different mechanisms for
updating these type of DNS records and explain the options that we have
available.  We need to make it easy for them to understand how the
mechanisms fit together and can be used in different situations.

But I think that kind of document can be written separately from moving the
other documents forward (and yes, I'm willing to help with text and not
just say that "someone" should write a doc).

I don't see why we can't adopt the CDS/CDNSKEY and CSYNC drafts as working
group documents and continue to move them along - we've had significant
discussion on these over the past several meetings and also on the lists:

http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-05
http://tools.ietf.org/html/draft-hardaker-dnsop-csync-01

Similarly, I think Mark's draft could be another one to consider adopting
for situations where people want to operate the push-style model:

http://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-00

I think we need some more discussion on that document before we adopt it (I
haven't seen any on the list, or did I miss it?) but I don't see any issue
with ALSO having a document like it as a working group document.  There
will be multiple models for different situations.

Additionally, I think Paul's document on use cases is one that we should be
bringing back into circulation (thanks, Matthijs, for the pointer after
Paul mentioned it yesterday):

http://tools.ietf.org/html/draft-wouters-dnsop-secure-update-use-cases-00

Anyway - I think we do need to move this whole area of work forward as
rapidly as we can.

My 2 cents,
Dan

--
Dan York, [email-masked]
http://danyork.me   http://twitter.com/danyork

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Nov 2013 11:09:19 -0500

Dear colleagues,

> discussion on these over the past several meetings and also on the lists:

There is, of course, no reason why people can't just work on these
documents without any magic bits about WG adoption.  Indeed, if recent
history is any guide, it might be that getting adopted by DNSOP is a
good way to ensure a document never actually emerges from being a
draft.

It seems to me that this list is reasonably chartered to address this
issue.  If the chairs disagree, there is another list still around
that can also be used.  In any case, what's more important is that the
work gets done, and not that we manipulate all the process levers in
the IETF machinery.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 6 Nov 2013 10:55:29 -0800

(I will speak only as myself for the moment )

I am in solid agreement that we need to move these documents forward. In 
Berlin, we sent back Wes, Warren and Olafur to resolve their 
differences, merge them (if possible) and present the various options. 
I've think they've done that and don't it admirably.  I believe that we 
should call for adoption on these two documents:

As it was said, "Adoption does not mean it will get published." All the 
authors agree with this.  I also feel that their is enough consensus to 
move on these.

With Mark Andrew's document:
     draft-andrews-dnsop-update-parent-zones-00

I agree with Dan here that we need some more time to see how this will 
work.  A functional example perhaps or some more time and more eyeballs 
on it.  I can see where both this and Wes's documents can work for 
different organizations.  I don't think we're far enough along to pick A 
vs B but we are far enough along to adopt and move forward.

Personally, I've been following dnsop and dnsext for many years. One 
thing I've felt is the turgid pace of document flow. I feel that we need 
to move things forward or decide why not and send them back.  One of the 
things I want to do as co-chair is "step up the pace."  From talking 
with folks on the committee, I have gotten the feedback this is needed. 
(If you think otherwise, please reach out to me directly).

I serve at the whim of the AD, and to serve the community, and until my 
body is found in a dumpster, I'm working in a more forward direction.

tim

On 11/6/13 5:49 AM, Dan York wrote:
> Peter & Tim,
>
> Unfortunately we ran out of time in the DNSOP session yesterday and I 
> don't feel we left with a plan to move forward on the various 
> *critical* that we DO move forward with these documents as this issue 
> is one of the big barriers for smoother operation of DNSSEC.
>
> I think there was a strong sense in the room that we definitely need 
> to work on this overall issue and I think at the end we were getting 
> hung up on some process points (and I admit that *I* was contributing 
> to that confusion)... and then we simply ran out of time.
>
> actually out there and deployed.  I think we need to provide 
> operational guidance to registrars and registries on the different 
> mechanisms for updating these type of DNS records and explain the 
> options that we have available.  We need to make it easy for them to 
> understand how the mechanisms fit together and can be used in 
> different situations.
>
> But I think that kind of document can be written separately from 
> moving the other documents forward (and yes, I'm willing to help with 
> text and not just say that "someone" should write a doc).
>
> I don't see why we can't adopt the CDS/CDNSKEY and CSYNC drafts as 
> working group documents and continue to move them along - we've had 
> significant discussion on these over the past several meetings and 
> also on the lists:
>
> Similarly, I think Mark's draft could be another one to consider 
> adopting for situations where people want to operate the push-style model:
>
> I think we need some more discussion on that document before we adopt 
> it (I haven't seen any on the list, or did I miss it?) but I don't see 
> any issue with ALSO having a document like it as a working group 
> document.  There will be multiple models for different situations.
>
> Additionally, I think Paul's document on use cases is one that we 
> should be bringing back into circulation (thanks, Matthijs, for the 
> pointer after Paul mentioned it yesterday):
>
> Dan York, [email-masked] <mailto:[email-masked]>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: joel jaeggli <[email-masked]>
Date: Wed, 6 Nov 2013 13:15:36 -0800

On Nov 6, 2013, at 10:55 AM, Tim Wicinski <[email-masked]> wrote:

> I am in solid agreement that we need to move these documents forward. In Berlin, we sent back Wes, Warren and Olafur to resolve their differences, merge them (if possible) and present the various options. I've think they've done that and don't it admirably.  I believe that we should call for adoption on these two documents:
> 
> As it was said, "Adoption does not mean it will get published."   All the authors agree with this.  I also feel that their is enough consensus to move on these. 
> 

So a question I have here with respect to conversations between authors that I’ve heard…

is the model more appropiate if the zone and corresponding number of updates is very large?

> I agree with Dan here that we need some more time to see how this will work.  A functional example perhaps or some more time and more eyeballs on it.  I can see where both this and Wes's documents can work for different organizations.  I don't think we're far enough along to pick A vs B but we are far enough along to adopt and move forward. 
> 
> Personally, I've been following dnsop and dnsext for many years. One thing I've felt is the turgid pace of document flow. I feel that we need to move things forward or decide why not and send them back.  One of the things I want to do as co-chair is "step up the pace."  From talking with folks on the committee, I have gotten the feedback this is needed. (If you think otherwise, please reach out to me directly).   
> 
> I serve at the whim of the AD, and to serve the community, and until my body is found in a dumpster, I'm working in a more forward direction. 
> 
> tim
> 
> 
>> Unfortunately we ran out of time in the DNSOP session yesterday and I don't feel we left with a plan to move forward on the various "parent-child-update" documents and scenarios.  However I think it is *critical* that we DO move forward with these documents as this issue is one of the big barriers for smoother operation of DNSSEC.
>> 
>> I think there was a strong sense in the room that we definitely need to work on this overall issue and I think at the end we were getting hung up on some process points (and I admit that *I* was contributing to that confusion)... and then we simply ran out of time.
>> 
>> What do you see as a path forward here?  How can we progress these documents?
>> 
>> The point I was trying to make in the final minutes was that we need something *more* than just these documents to help get these solutions actually out there and deployed.  I think we need to provide operational guidance to registrars and registries on the different mechanisms for updating these type of DNS records and explain the options that we have available.  We need to make it easy for them to understand how the mechanisms fit together and can be used in different situations.
>> 
>> But I think that kind of document can be written separately from moving the other documents forward (and yes, I'm willing to help with text and not just say that "someone" should write a doc).
>> 
>> I don't see why we can't adopt the CDS/CDNSKEY and CSYNC drafts as working group documents and continue to move them along - we've had significant discussion on these over the past several meetings and also on the lists:
>> 
>> Similarly, I think Mark's draft could be another one to consider adopting for situations where people want to operate the push-style model:
>> 
>> I think we need some more discussion on that document before we adopt it (I haven't seen any on the list, or did I miss it?) but I don't see any issue with ALSO having a document like it as a working group document.  There will be multiple models for different situations.
>> 
>> Additionally, I think Paul's document on use cases is one that we should be bringing back into circulation (thanks, Matthijs, for the pointer after Paul mentioned it yesterday):
>> 
>> Anyway - I think we do need to move this whole area of work forward as rapidly as we can.  
>> 
>> My 2 cents,
>> Dan
>> 
>> --