On Nov 6, 2013, at 10:55 AM, Tim Wicinski <tim.wicin...@teamaol.com> wrote:
> (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: > > http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-05 > http://tools.ietf.org/html/draft-hardaker-dnsop-csync-01 > > 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 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 > > > 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 >> "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, dan-i...@danyork.org >> http://danyork.me http://twitter.com/danyork >> >> >> _______________________________________________ >> DNSOP mailing list >> >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
