Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

On 23 September 2015 at 21:40, Dave Lawrence wrote: > Ted Lemon writes: >> It would be helpful if the authors could explain why the REFUSED >> response is being used here. > > Not to be glib, but because that's what Wilmer originally specified. > That's thus what got implemented by the existing im

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

On Wed, Sep 16, 2015 at 12:05:58PM -0400, Suzanne Woolf wrote: > The current version is at: > http://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/ > I have some concerns, which I describe below. I've attempte

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

On Sep 24, 2015, at 8:52 AM, John Dickinson wrote: > I agree, when I last read this I had the IESG Note in my head (and I already > knew that this was just documenting existing deployments). Looking again, I > suggest that the IESG Note be moved to the main text and not be removed prior > to pu

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

John Dickinson writes: > I suggest that the IESG Note be moved to the main text and not be > removed prior to publication. I agree, and am making some edits today for review by the co-authors. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/m

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

On 24 Sep 2015, at 13:42, Ted Lemon wrote: > On Sep 23, 2015, at 4:40 PM, Dave Lawrence wrote: >> Ted Lemon writes: >>> It would be helpful if the authors could explain why the REFUSED >>> response is being used here. >> >> Not to be glib, but because that's what Wilmer originally specified. >> T

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

On Sep 23, 2015, at 4:40 PM, Dave Lawrence wrote: > Ted Lemon writes: >> It would be helpful if the authors could explain why the REFUSED >> response is being used here. > > Not to be glib, but because that's what Wilmer originally specified. > That's thus what got implemented by the existing imp

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

Ted Lemon writes: > It would be helpful if the authors could explain why the REFUSED > response is being used here. Not to be glib, but because that's what Wilmer originally specified. That's thus what got implemented by the existing implementations (and there are more than you'd likely imagine, t

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

Greetings. I have reviewed the latest version of this document and think that it ready for publication as an Informational RFC. It covers more of the relevant related topics than the draft that the WG adopted, and is clearer in many places. I'm not an implementer so I can't say whether or not i

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

It would be helpful if the authors could explain why the REFUSED response is being used here. Realizing that the current version of the document is intended to document existing practice, nevertheless, strongly recommending the use of REFUSED here is a bad idea, as can be seen from the advice

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

I have read the draft. I am collecting information carried in EDNS0 client_subnet and have been running modified authoritative state server-side in order to tickle it out, and I am happy with what I see. It ain't perfect but its pretty good. I like that the draft is reasonably clear about the know

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-cookies

On Thu, Jul 2, 2015 at 4:20 AM, Tim Wicinski wrote: > > All > > Donald and Mark have worked out the issues on the DNS Cookies draft, > mostly around the issue of returning an error code (no), and getting an > official Option-Code (10). > > This starts a Working Group Last Call for draft-ietf-dnso

[DNSOP] Working Group Last Call for draft-ietf-dnsop-cookies

All Donald and Mark have worked out the issues on the DNS Cookies draft, mostly around the issue of returning an error code (no), and getting an official Option-Code (10). This starts a Working Group Last Call for draft-ietf-dnsop-cookies Current versions of the draft is available here: ht

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-qname-minimisation

On Thu, Jun 25, 2015 at 01:42:17PM -0400, Tim Wicinski wrote a message of 31 lines which said: > (the last comments from Mr. Harold are not in this draft but are > being addressed) You can see it in the Github repository

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-qname-minimisation

On Jun 25, 2015, at 10:42 AM, Tim Wicinski wrote: > All > > Stephane has taken in all the comments on the qname-minimisation draft, and > has addressed everything (the last comments from Mr. Harold are not in this > draft but are being addressed). This starts a Working Group Last Call for

[DNSOP] Working Group Last Call for draft-ietf-dnsop-qname-minimisation

All Stephane has taken in all the comments on the qname-minimisation draft, and has addressed everything (the last comments from Mr. Harold are not in this draft but are being addressed). This starts a Working Group Last Call for draft-ietf-dnsop-qname-minimisation Current versions of th

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-root-loopback

On Jun 8, 2015, at 10:27 PM, fujiw...@jprs.co.jp wrote: > draft-fujiwara-dnsop-nsec-aggressiveuse My apologies for forgetting about your draft. We will mention it as an alternative approach in the introduction to draft-ietf-dnsop-root-loopback and include an informational reference to it. --Pau

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-root-loopback

> From: Paul Hoffman >> If resolvers are encouraged to use NSEC records to synthesize NXDOMAIN >> responses, would there still be any point to this draft? > > Yes. No one has written up a document on using NSEC records to synthesize > NXDOMAIN for the root, and if they do, there will certainly b

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-root-loopback

> On Jun 4, 2015, at 7:48 PM, Paul Hoffman wrote: > > On Jun 4, 2015, at 4:05 PM, Tony Finch wrote: >> Are there any implementations of this draft? > > Assuming you mean "is anyone deploying the ideas in this draft, particularly > those in Appendix B", that would be good information for the a

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-root-loopback

On Jun 4, 2015, at 4:05 PM, Tony Finch wrote: > Are there any implementations of this draft? Assuming you mean "is anyone deploying the ideas in this draft, particularly those in Appendix B", that would be good information for the authors to have. > If resolvers are encouraged to use NSEC recor

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-root-loopback

Are there any implementations of this draft? If resolvers are encouraged to use NSEC records to synthesize NXDOMAIN responses, would there still be any point to this draft? Tony. -- f.anthony.n.finchhttp://dotat.at/ Rockall: Southeasterly 5 to 7, becoming cyclonic 7 to severe gale 9, occasio

[DNSOP] Working Group Last Call for draft-ietf-dnsop-root-loopback

This starts a Working Group Last Call for draft-ietf-dnsop-root-loopback Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/ https://tools.ietf.org/html/draft-ietf-dnsop-root-loopback-01 Please review the draft and offer relevant com

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

A few minor notes on draft-ietf-dnsop-edns-chain-query-02 My apologies for not seeing these earlier. Or perhaps I am not understanding this correctly. pg 6 sec 5.2 "Depending on the size of the labels of the last known entry point value, a DNS Query packet could be arbitrarily large. If using

[DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

The chairs feel that the Author has addressed all the comments that have been brought up on the mailing list and updated this draft to reflect this. We are ready to move forward with a Working Group Last Call. At this time, this starts a Working Group Last Call for draft-ietf-dnsop-edn

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

At Tue, 12 May 2015 11:44:28 +0200, Warren Kumari wrote: > > In BIND, NTA's are set by an rndc command, but in other implementations > > they might be set up in a config file. If you have both a TA and an NTA > > for the same node in the same configuration, that would be sensible to > > warn abou

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Tue, May 12, 2015 at 5:00 PM, Evan Hunt wrote: > On Tue, May 12, 2015 at 11:44:28AM +0200, Warren Kumari wrote: >> "An NTA placed at a node where there is a configured positive trust >> anchor MUST take precendence over that trust anchor, effectively >> disabling it. Implementations SHOULD issu

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Tue, May 12, 2015 at 11:44:28AM +0200, Warren Kumari wrote: > "An NTA placed at a node where there is a configured positive trust > anchor MUST take precendence over that trust anchor, effectively > disabling it. Implementations SHOULD issue a warning or informational > message when this occurs,

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

Moin! On 11 May 2015, at 19:20, Evan Hunt wrote: >> Does this mean: >> >> A: All implementations that conform to this document should prefer the >> NTA over the positive anchor in such a case, or >> B: This is implementation-dependent, but if an implementation allows >> the coexistence of posit

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Mon, May 11, 2015 at 7:26 PM, Evan Hunt wrote: > On Mon, May 11, 2015 at 12:19:19PM -0400, Bob Harold wrote: >> I am not even sure there is a good reason for a warning. > > In BIND, NTA's are set by an rndc command, but in other implementations > they might be set up in a config file. If you ha

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Mon, May 11, 2015 at 12:19:19PM -0400, Bob Harold wrote: > I am not even sure there is a good reason for a warning. In BIND, NTA's are set by an rndc command, but in other implementations they might be set up in a config file. If you have both a TA and an NTA for the same node in the same confi

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

> Does this mean: > > A: All implementations that conform to this document should prefer the >NTA over the positive anchor in such a case, or > B: This is implementation-dependent, but if an implementation allows >the coexistence of positive and negative anchors, it should prefer >the

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Mon, May 11, 2015 at 12:10 PM, 神明達哉 wrote: > At Sat, 9 May 2015 18:50:28 +, > Evan Hunt wrote: > > > Actually, weirdly enough, after I implemented NTA's in BIND, one of the > > very first applications somebody came up with for them was to temporarily > > disable DNSSEC validation by setti

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

At Sat, 9 May 2015 18:50:28 +, Evan Hunt wrote: > Actually, weirdly enough, after I implemented NTA's in BIND, one of the > very first applications somebody came up with for them was to temporarily > disable DNSSEC validation by setting an NTA for ".". This was seen as > better than "rndc va

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

At Sat, 9 May 2015 15:08:11 +0200, Warren Kumari wrote: > > 1. In my very original comment on this matter: > >www.ietf.org/mail-archive/web/dnsop/current/msg12614.html > >I noted one other corner case, which we might also want to clarify: > > On a related note, there are some corner

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Sat, May 9, 2015 at 8:50 PM, Evan Hunt wrote: > On Sat, May 09, 2015 at 03:08:11PM +0200, Warren Kumari wrote: >> "It is RECOMMENDED that implementations warn operators (or treat as an >> error) if they attempt to add an NTA for a domain that has a >> configured positive trust anchor." > > You

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Sat, May 9, 2015 at 4:33 PM, Paul Hoffman wrote: > On May 9, 2015, at 6:07 AM, Warren Kumari wrote: >>> In Section 2, there should be a new paragraph after the first paragraph >>> that describes why the "reasonable attempt" in the first paragraph is >>> needed to determine whether the attack

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Sat, May 09, 2015 at 03:08:11PM +0200, Warren Kumari wrote: > "It is RECOMMENDED that implementations warn operators (or treat as an > error) if they attempt to add an NTA for a domain that has a > configured positive trust anchor." You still need to say what happens if the implementation decid

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On May 9, 2015, at 6:08 AM, Warren Kumari wrote: >> Two more related points: >> >> 1. In my very original comment on this matter: >> www.ietf.org/mail-archive/web/dnsop/current/msg12614.html >> I noted one other corner case, which we might also want to clarify: >> On a related note, there

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On May 9, 2015, at 6:07 AM, Warren Kumari wrote: >> In Section 2, there should be a new paragraph after the first paragraph that >> describes why the "reasonable attempt" in the first paragraph is needed to >> determine whether the attacker has partial control of the zone, or is just >> mountin

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Wed, May 6, 2015 at 6:51 PM, 神明達哉 wrote: > At Tue, 5 May 2015 17:06:04 -0400, > Warren Kumari wrote: > >> ... and now I'm replying to the rest of the comments. > > Thanks, I've confirmed that my major and minor points are addressed in > the 05 version. So I'm now basically fine with shipping

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Wed, May 6, 2015 at 5:08 PM, Dan York wrote: > Warren and Tim, > > I support the publishing of this document subject to incorporating the > various comments I’ve seen here on that list. I had a couple of specific > points but they seem to have been covered by others, so… > > On May 6, 2015, at

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Wed, May 6, 2015 at 3:33 PM, Rose, Scott W. wrote: > I think the draft is just about ready for publication as well. > > On May 5, 2015, at 5:53 PM, Paul Hoffman wrote: > >> This document has progressed very well and is nearly ready for publication. >> >> Related to an earlier thread about inte

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

[ Top post ] Integrating these -- 'parently I'm processing emails out of order... Thank you for your comments, I've integrated them and will post a new version soon (planning on incorporating some of Jinmei's comments before posting). On Tue, May 5, 2015 at 5:53 PM, Paul Hoffman wrote: > This d

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

At Tue, 5 May 2015 17:06:04 -0400, Warren Kumari wrote: > ... and now I'm replying to the rest of the comments. Thanks, I've confirmed that my major and minor points are addressed in the 05 version. So I'm now basically fine with shipping it. Some non-blocking comments follow... > I've integr

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

Warren and Tim, I support the publishing of this document subject to incorporating the various comments I’ve seen here on that list. I had a couple of specific points but they seem to have been covered by others, so… On May 6, 2015, at 9:46 AM, Warren Kumari mailto:war...@kumari.net>> wrote:

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

[meta comment] I will be traveling for DNS-OARC, RIPE and another meeting starting this afternoon. I wanted to mention this so that y'all don't think I'm ignoring your comments - I really appreciate all feedback, and will integrate comments in the next couple of days (I like to rev the doc even du

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

I think the draft is just about ready for publication as well. On May 5, 2015, at 5:53 PM, Paul Hoffman wrote: > This document has progressed very well and is nearly ready for publication. > > Related to an earlier thread about intended status: "Informational" is most > appropriate here becaus

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

This document has progressed very well and is nearly ready for publication. Related to an earlier thread about intended status: "Informational" is most appropriate here because the document is all about proposed operations but no "best current practice". There is no problem with WGs producing In

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

... and now I'm replying to the rest of the comments. I've integrated them and posted a new version with the clarifications on a *positive* **trust anchor** under an NTA. I'm not very happy with the text I added, if others have better text happy to consider it... Huge thanks to Jinmei for the car

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

On Tue, May 05, 2015 at 12:24:13PM -0400, Warren Kumari wrote: > The way that our resolver works is that the closest TA would win, and > so a positive TA under a negative trust anchor *would* be used. To me > this seems to be the obviously right thing to do, and so, unless > anyone objects, I'll ad

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

[ Top post] Only replying to the biggest issue here, will reply to the rest later today. On Mon, May 4, 2015 at 2:25 PM, 神明達哉 wrote: > At Mon, 27 Apr 2015 18:58:10 -0400, > Tim Wicinski wrote: > >> This starts a Working Group Last Call for Adoption for >> draft-ietf-dnsop-negative-trust-anchors

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

At Mon, 27 Apr 2015 18:58:10 -0400, Tim Wicinski wrote: > This starts a Working Group Last Call for Adoption for > draft-ietf-dnsop-negative-trust-anchors (I guess this is "for Publication", not "for Adoption"). Also, have we decided to publish it as an Informational document? I'm not opposed

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

Hi I have reviewed this document, and support its publication as is. Olafur On Mon, Apr 27, 2015 at 11:58 PM, Tim Wicinski wrote: > Greetings, > > This starts a Working Group Last Call for Adoption for > draft-ietf-dnsop-negative-trust-anchors > > Current versions of the draft is available he

[DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

Greetings, This starts a Working Group Last Call for Adoption for draft-ietf-dnsop-negative-trust-anchors Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/ https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anc

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-key-timing

On Sat, Jul 26, 2014 at 11:29:24PM -0400, Tim Wicinski wrote a message of 49 lines which said: > So I'm going to do something different: I will submit this document "this" being, I assume, the version on Github? It is modified non-trivially since the last formally published version (-04) so

[DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-key-timing

Thank to John, Andrew, Paul, and Scott for your comments. I was originally going to start a very formal WGLC for this once I returned from Toronto, but two things stand out: 1) a WGLC last call was done, and totally passed 2 years ago 2) the changes are specific to address the

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

Edward Lewis writes: > But I am dubious on the flag for “immediate.” In my experience, I’ve > never seen queue-jumping to every pay off unless the underlying system > is over subscribed as it is. If this system is oversubscribed, there > are bigger problems. Normally I’d let this lie, but it r

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

Edward Lewis writes: > My concern with the glue records is more substantial. There are two > use cases to consider. > > One case is where the addresses of the NS names are owned in a > different (perhaps sub) zone. The other case is where the addresses > are in zone that is “above” the child bu

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

Paul Hoffman writes: >> The document does do a good job of handling as many as it can, but >> there’s still the underlying limitations of one-way-only message >> passing. The only way this will work (in the sense of scale and >> stability over time) is if the parental agent gets notified reliabl

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc6304bis and draft-ietf-dnsop-as112-dname

Hi Stephane, On 5 May 2014, at 16:13, Stephane Bortzmeyer wrote: > On Sun, May 04, 2014 at 01:42:51PM -0400, > Tim Wicinski wrote > a message of 33 lines which said: > >> Since this has been discussed several times and voted on during the >> meetings, please *only* state if you think these ar

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc6304bis and draft-ietf-dnsop-as112-dname

On Sun, May 04, 2014 at 01:42:51PM -0400, Tim Wicinski wrote a message of 33 lines which said: > Since this has been discussed several times and voted on during the > meetings, please *only* state if you think these are *not* ready for > publication, and your reasons. OK, then, I'll say nothi

[DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc6304bis and draft-ietf-dnsop-as112-dname

All These two documents have been ready for WGLC since before London (and probably farther back than that). Since the revised version of 6304 referenced the new as112-dname document, the decision was made to submit them both at once, and pass them along as a pair. Reminder, in London, we

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

On 2.5.2014 01:26, Wes Hardaker wrote: >- I'm bit nervous about "should be processed" in section: >2.2.2. CSYNC Record Types > >This document defines how the following record types may be processed >if the CSYNC Type Bit Map field indicates they should be processed. > >Did you mean SHOULD

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

Petr Spacek writes: > I support this proposal. Thanks Petr! > Couple nits I have noticed: > > - Term "DNS Publisher" is not used in the whole text except it's > definition and section 5. Acknowledgments :-) Excellent point, removed! > - I'm bit nervous about "should be processed" in section:

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

Olafur Please add this. I'll get caught back up on the rest of this by the time warren returns from his walkabout. Sent from my Hi-Tech Gadget. > On Apr 25, 2014, at 6:48, Olafur Gudmundsson wrote: > > >> On Apr 25, 2014, at 2:28 AM, Matthijs Mekking wrote: >> >> Hi, >> >>> On 04/24/201

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Apr 25, 2014, at 2:28 AM, Matthijs Mekking wrote: > Hi, > > On 04/24/2014 05:41 PM, 神明達哉 wrote: >> At Thu, 24 Apr 2014 07:55:52 +0200, >> Matthijs Mekking wrote: >> >>> The child can also signal its desire to remove DS records by removing >>> the corresponding records from the CDS/CDNSKEY

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

Hi, On 04/24/2014 05:41 PM, 神明達哉 wrote: > At Thu, 24 Apr 2014 07:55:52 +0200, > Matthijs Mekking wrote: > >> The child can also signal its desire to remove DS records by removing >> the corresponding records from the CDS/CDNSKEY RRset again. > > ...unless that would make the resulting CDS/CDNSK

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

At Thu, 24 Apr 2014 07:55:52 +0200, Matthijs Mekking wrote: > The child can also signal its desire to remove DS records by removing > the corresponding records from the CDS/CDNSKEY RRset again. ...unless that would make the resulting CDS/CDNSKEY RRset empty. Otherwise it can contradict this one:

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

is no action to perform for the parent. Hence, this document does not support removing all DS records from the parent. Best regards, Matthijs > > Jack > >> -Original Message- From: DNSOP >> [mailto:dnsop-boun...@ietf.org] On Behalf Of Joe Abley Sent: >>

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

quot; parameter to the proposed CDS and CDNSKEY resource records to instruct the parental agent on the type of operation to perform? Jack > -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Joe Abley > Sent: April-21-14 9:34 AM > To: Warren Kumari

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

Matthijs Mekking writes: > 1. Introduction, last paragraph. > To me, the mentioning of not addressing DNSSEC bootstrapping comes out > the blue. One sentence later it mentions it is not intended for DNSSEC > synchronization at all. I'd prefer a rewrite of this last paragraph: > > "This specif

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

Masataka Ohta writes: Sorry for the delay in getting to this discussion, it's been a busy few weeks and I'm just catching up. > The following paragraph: > >Some resource records (RRs) in a parent zone are typically expected >to be in-sync with the source data in the child's zone. The mo

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

On 15.4.2014 10:46, Matthijs Mekking wrote: 2.1.1.1. The SOA Serial Field First, this document talks about serial being greater than... It might be good to reference RFC 1982 serial number arithmetic that defines serial comparison. Second, I don't like having a special value of 0 to indicate som

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On 16 Apr 2014, at 8:02, Warren Kumari wrote: > I think I made it even clearer: > The first time a DNS operator signs a zone, they need to communicate > the keying material to their parent through some out-of-band method to > complete the chain of trust. Depending on the desires of the parent, >

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Thu, Apr 17, 2014 at 4:46 AM, Matthijs Mekking wrote: > On 04/16/2014 06:40 PM, Warren Kumari wrote: >> On Wed, Apr 16, 2014 at 9:19 AM, Dan York wrote: >>> >>> On Apr 16, 2014, at 8:02 AM, Warren Kumari >>> wrote: >>> >>> I think I made it even clearer: >>> The first time a DNS operator sig

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On 04/16/2014 06:40 PM, Warren Kumari wrote: > On Wed, Apr 16, 2014 at 9:19 AM, Dan York wrote: >> >> On Apr 16, 2014, at 8:02 AM, Warren Kumari >> wrote: >> >> I think I made it even clearer: >> The first time a DNS operator signs a zone, they need to communicate >> the keying material to their

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Wed, Apr 16, 2014 at 9:19 AM, Dan York wrote: > > On Apr 16, 2014, at 8:02 AM, Warren Kumari > wrote: > > I think I made it even clearer: > The first time a DNS operator signs a zone, they need to communicate > the keying material to their parent through some out-of-band method to > complete

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Apr 16, 2014, at 8:02 AM, Warren Kumari mailto:war...@kumari.net>> wrote: I think I made it even clearer: The first time a DNS operator signs a zone, they need to communicate the keying material to their parent through some out-of-band method to complete the chain of trust. Depending on the

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Wed, Apr 16, 2014 at 3:34 AM, Jaap Akkerhuis wrote: > > > When a DNS operator first signs their zone, they need to communicate > their > > keying material to their parent through some out-of-band method to > complete > > > > And changing opening sentence to: > > The first time

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

> When a DNS operator first signs their zone, they need to communicate their > keying material to their parent through some out-of-band method to complete And changing opening sentence to: The first time a DNS operator signs the zone, they need to communicate the keyin

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Tuesday, April 15, 2014, Paul Hoffman wrote: > This looks greatly improved from the -03 that started the WG Last Call. It > clears almost all of my concerns, particularly about the overly-loose > language. > > There is still one assumption being made of the reader that I think can > cleanly be

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Apr 15, 2014, at 8:06 PM, Paul Hoffman wrote: > This looks greatly improved from the -03 that started the WG Last Call. It > clears almost all of my concerns, particularly about the overly-loose > language. > > There is still one assumption being made of the reader that I think can > clea

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

This looks greatly improved from the -03 that started the WG Last Call. It clears almost all of my concerns, particularly about the overly-loose language. There is still one assumption being made of the reader that I think can cleanly be cleared up. The first paragraph of the introduction says:

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Tue, Apr 15, 2014 at 4:23 AM, Antoin Verschuren wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > op 14-04-14 21:18, Warren Kumari schreef: > >>> Just checking -- do you want any action *on this doc*? I *think* >>> that we are generic/non-prescriptive enough that you can >>> implemen

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

Hi, Some feedback: 1. Introduction, last paragraph. To me, the mentioning of not addressing DNSSEC bootstrapping comes out the blue. One sentence later it mentions it is not intended for DNSSEC synchronization at all. I'd prefer a rewrite of this last paragraph: "This specification was not d

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 op 14-04-14 21:18, Warren Kumari schreef: >> Just checking -- do you want any action *on this doc*? I *think* >> that we are generic/non-prescriptive enough that you can >> implement whatever policy you want... Yes, like I said, I would like to have

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Mon, Apr 14, 2014 at 7:09 AM, Antoin Verschuren wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > op 10-04-14 21:54, Patrik Fältström schreef: > >> We already have too many parents that have I do not know how many >> stupid rules for what various values must be in the child hosting >

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 op 10-04-14 21:54, Patrik Fältström schreef: > We already have too many parents that have I do not know how many > stupid rules for what various values must be in the child hosting > situation, and in many cases that make it plain impossible to do > w

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 op 12-04-14 00:06, Warren Kumari schreef: > The parent should use whichever one they choose, but MUST NOT query > for both and perform consistency checks between the CDS and CDNSKEY > records." > > "A parent MUST NOT perform a consistency check betwee

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On 11 apr 2014, at 23:48, Warren Kumari wrote: >> This is not YOUR fault, and you can not fix this problem in THIS draft. I >> just find it being...not fun. > > Yup, me too. > If they made me President of the Universe: > 1: SPAM would be a capitol offense. > 2: All movies **MUST** (RFC2119-styl

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Fri, Apr 11, 2014 at 7:10 AM, Patrik Fältström wrote: > > On 11 apr 2014, at 12:03, Antoin Verschuren wrote: > >> I think since this is a protocol definition, CDS and CDNSKEY MUST >> match. What a parent should do when the protocol is violated is I >> guess an implementation issue, BCP, or per

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Fri, Apr 11, 2014 at 5:36 AM, Matthijs Mekking wrote: > Hi, > > > On 04/10/2014 09:54 PM, Patrik Fältström wrote: > 2.2.1. Solution Space : : > Some parents want the child to express their DNSKEYS in the > form of DS records, while others want to receive the DNSKEY > recor

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Thu, Apr 10, 2014 at 3:54 PM, Patrik Fältström wrote: > On 10 apr 2014, at 18:34, Warren Kumari wrote: > >>> Because of this, I do not mind having some extra words here, like: >>> >>> "This proposal do not include all operations needed for maintenance of >>> DNSSEC key material, specifically

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On 11 apr 2014, at 12:03, Antoin Verschuren wrote: > I think since this is a protocol definition, CDS and CDNSKEY MUST > match. What a parent should do when the protocol is violated is I > guess an implementation issue, BCP, or perhaps even local policy. A > parent may only look at CDNSKEY or CD

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

Hi, I support publication of this document, but I agree that some things should be improved before its ready to do so. Mainly the RFC2119 language (raised by Patrik), the rule of removing the CDS/CDNSKEY RRset at the child and missing/no clear guidelines to prevent "DS flapping". Besides some nit

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 op 10-04-14 21:54, Patrik Fältström schreef: > On 10 apr 2014, at 18:34, Warren Kumari wrote: >> If we were to *require* that they match, what happens in the >> case where they *don't*? Do we fail the keyroll? That seems >> suboptimal. Do we throw a

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On 11 apr 2014, at 11:36, Matthijs Mekking wrote: >> I want to know what happens both from the child and parent >> perspective IF the CDS and CDNSKEY differs. >> >> Just say what the result should be. >> >> Parent pick one at random? > > At random? Then you still don't really know that the re

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

Hi, On 04/10/2014 09:54 PM, Patrik Fältström wrote: 2.2.1. Solution Space >>> : : Some parents want the child to express their DNSKEYS in the form of DS records, while others want to receive the DNSKEY records and calculate the DS records themselves. There is no consens

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On 10 apr 2014, at 18:34, Warren Kumari wrote: >> Because of this, I do not mind having some extra words here, like: >> >> "This proposal do not include all operations needed for maintenance of >> DNSSEC key material, specifically introduction and complete removal of all >> keys. Because of th

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[ Top post ] We have received a number of comments, and are integrating them. So far we have mostly just covered Patrik's - I'm posting a newer version with some of these integrated, so it's easier for folk to see what the doc looks like with the changes. We plan to post a more updated version with

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Thu, Apr 3, 2014 at 3:07 AM, Tim Wicinski wrote: > Greetings, > > This is the starting of the WGLC on Automating DNSSEC delegation trust > maintenance. This was briefly covered in London and these are ready for > WGLC. The current versions of this documents can be found here: > > > https://d

<    2   3   4   5   6   7   8   >