[DNSOP] Andrew Alston's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Andrew Alston has entered the following ballot position for draft-ietf-dnsop-nsec3-guidance-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ -- COMMENT: -- Thanks for the work put into this document. Having read through the document, I would also like to support Paul's discuss since the document does seem to update RFC5155. I also would like to second what Murray said about it seeming a little strange to see a BCP document updating a standards track document. Finally - I was a little surprised to see IANA actions in a document entitled "guidance for" - not sure if anyone else agrees with me, but it seems strange to see a BCP document requesting IANA actions ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Andrew Alston's Discuss on draft-ietf-dnsop-nsec3-guidance-08: (with DISCUSS and COMMENT)
Andrew Alston has entered the following ballot position for draft-ietf-dnsop-nsec3-guidance-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ -- DISCUSS: -- I've been sitting trying to work out in my mind if a BCP document should be requesting code points - and if I should change the position from a no objection to a discuss - and the more I think about this - I feel that a discuss here is probably the right option. I'd like to discuss if both the sections of the document that utilize normative language and require additional code points aren't better suited to a standards track document. -- COMMENT: -- Thanks for the work put into this document. Having read through the document, I would also like to support Paul's discuss since the document does seem to update RFC5155. I also would like to second what Murray said about it seeming a little strange to see a BCP document updating a standards track document. Finally - I was a little surprised to see IANA actions in a document entitled "guidance for" - not sure if anyone else agrees with me, but it seems strange to see a BCP document requesting IANA actions ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
John Scudder via Datatracker writes: > John Scudder has entered the following ballot position for > draft-ietf-dnsop-nsec3-guidance-08: No Objection Thanks John; I've made all of these changes: > -- > COMMENT: > -- > > Thanks for this document, I found it easy to read and useful. I have only a > few > nits: > > 1. In the Introduction: “This sacrifices the tamper-resistance proof of non- >existence offered by NSEC3” > > That doesn’t parse. Probably what you mean is “This sacrifices the > tamper-resistance of the proof of non-existence offered by NSEC3” (added “of > the”)? Or "... the tamper-resistant proof" would also work. > > 2. In Sections 2.4 and 3.1, I suggest “re-signing” (signing again) instead of > “resigning” (quitting). > > 3. Appendix B has “The table (Appendix C) >below” > > The “(Appendix C)” part appears to be a mistake? The table is uncaptioned, I > guess you either should caption it and xref that caption, or just remove the > xref? > > > -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Éric Vyncke via Datatracker writes: Thanks for the comments Éric, I've made the following changes: > ## Section 2 > > Suggest to change the title s/considerations/discussions/ as this section > explains the recommendations of section 3. > > ## Section 3.2 > > S/near the time of publication/near the time of publication of this document/ > ? > > ## Section 7.1 > > RFC 8174 should be normative > > # NITS > WRT to this: > ## Section 1 > Should "zone apex" be explained ? Probably not as its a term of art in DNS and hard to explain in a sentence. Anyone that follows the normative refs should understand it. > ## Appendix C > > I am not sure whether Peter Špaček appreciates his last name writing in the > I-D > ;-) (my first name, Éric, suffers from the same issue ;-) ) Yeah, I8N is a pain. I haven't figured out the right way to fix that in markdown source yet, but by the time its all published we'll get it fixed. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Lars Eggert via Datatracker writes:
> DNS Error (EDE) {RFC8914} EDNS0 option of value (RFC EDITOR: TBD).
> {RFC8914} looks like a Markdown citation bug.
Yep. Fixed.
> ### Stray characters
>
> The text version of this document contains these HTML entities, which might
> indicate issues with its XML source: `č`, `Š`, and `Č`
Actually it's the markdown source -- I'll get the names fixed though.
> ### Grammar/style
>
> "Table of Contents", paragraph 1
> ```
> . . . . . . . . . . 10 Appendix D. Github Version of This Document . . . . .
>^^
> ```
> The official name of this software platform is spelled with a capital
> "H".
Good point. Better yet though, I've added a note that the rfc editor
should remove that section anyway.
These are done (but more following):
> Section 1.1, paragraph 1
> ```
> lag [RFC5155], which specifies whether or not that NSEC3 record provides pro
>^^
> ```
> Consider shortening this phrase to just "whether". It is correct though if you
> mean "regardless of whether".
>
> Section 2.3, paragraph 1
> ```
> w, ftp, mail, imap, login, database, etc) can be used to quickly reveal a lar
> ^^^
> ```
> A period is needed after the abbreviation "etc.".
>
> Section 5, paragraph 1
> ```
> y Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/R
>^^^
> ```
> Do not mix variants of the same word ("on-line" and "online") within a single
> text.
I'm very confused now. That section looks nothing like you above text,
nor is that text anywhere. And ditto with this one:
> Section 7.1, paragraph 2
> ```
> NSSEC zone enumeration algorithm", n.d.. Appendix A. Deployment measurements
> ^^
> ```
> Two consecutive dots.
Were you perhaps reading a different reference or something?
> "Appendix A.", paragraph 2
> ```
> Vixie * Tim Wicinski Appendix D. Github Version of This Document While this
> ^^
> ```
> The official name of this software platform is spelled with a capital
> "H".
I've marked that section to be deleted by the RFC Editor, but fixed that anyway.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Zaheduzzaman Sarker's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Zaheduzzaman Sarker via Datatracker writes: > - the updating RFC 5155 issue like others have, so, lets support Paul's > discuss. I've added a reference. > - RFC 8174 should be in the normative reference. Also done. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Wes Hardaker writes:
> > Section 5, paragraph 1
> > ```
> > y Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI
> > 10.17487/R
> >^^^
> > ```
> > Do not mix variants of the same word ("on-line" and "online") within a
> > single
> > text.
>
>
> I'm very confused now. That section looks nothing like you above text,
> nor is that text anywhere. And ditto with this one:
Arg, *I* was reading the wrong version.
Anyway, you're quoting how the tools produced the reference results with
their titles. I can't fix RFC4470.
> > Section 7.1, paragraph 2
> > ```
> > NSSEC zone enumeration algorithm", n.d.. Appendix A. Deployment measurements
> > ^^
> > ```
> > Two consecutive dots.
Ditto.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Zaheduzzaman Sarker's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Thanks, Wes! //Zahed From: iesg on behalf of Wes Hardaker Sent: Thursday, May 12, 2022 7:05:54 PM To: Zaheduzzaman Sarker via Datatracker Cc: The IESG ; Zaheduzzaman Sarker ; draft-ietf-dnsop-nsec3-guida...@ietf.org ; dnsop-cha...@ietf.org ; dnsop@ietf.org ; tjw.i...@gmail.com Subject: Re: Zaheduzzaman Sarker's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT) Zaheduzzaman Sarker via Datatracker writes: > - the updating RFC 5155 issue like others have, so, lets support Paul's > discuss. I've added a reference. > - RFC 8174 should be in the normative reference. Also done. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Hi, On 2022-5-12, at 20:11, Wes Hardaker wrote: > Anyway, you're quoting how the tools produced the reference results with > their titles. I can't fix RFC4470. understood - that's why I have the blurb about false positives in there. Thanks, Lars signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
