State changed to Approved-announcement sent from IESG Evaluation::AD Followup

2012-11-15

20

Amy Vezza

IESG has approved the document

2012-11-15

20

Amy Vezza

Closed "Approve" ballot

2012-11-15

20

Amy Vezza

Ballot approval text was generated

2012-11-15

20

Amy Vezza

Ballot writeup was changed

2012-11-07

20

Russ Housley

[Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss

2012-09-28

20

Samuel Weiler

New version available: draft-ietf-dnsext-dnssec-bis-updates-20.txt

2012-07-13

19

(System)

Sub state has been changed to AD Followup from Revised ID Needed

2012-07-13

19

Samuel Weiler

New version available: draft-ietf-dnsext-dnssec-bis-updates-19.txt

2012-06-07

18

Cindy Morgan

State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation

2012-06-07

18

Pete Resnick

[Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick

2012-06-07

18

Stewart Bryant

[Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant

2012-06-06

18

Benoit Claise

[Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise

2012-06-06

18

Ralph Droms

State changed to IESG Evaluation from Waiting for AD Go-Ahead

2012-06-06

18

Gonzalo Camarillo

[Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo

2012-06-05

18

Stephen Farrell

[Ballot comment]

During the "no answer" mega-discussion on the DANE list, [1] Iseem to recall this comment was made more than once: "you're ...

[Ballot comment]

During the "no answer" mega-discussion on the DANE list, [1] Iseem to recall this comment was made more than once: "you'reseeing all this because you're maybe the first newapplication that really needs DNSSEC," or words to thateffect. Should any of that discussion be reflected in thisdocument? (I assume its not already there for timing reasonsif nothing else.)

This MAY and the one in the following paragraph are misused: they should not be 2119 terms. Describing what a zone "may be using" is simply a descriptive phrase, not anything normative. Actually, I would say "might be using".

-- 5.2 --Isn't the point really more general: that if the validator is unable to validate the signature, *for whatever reason*, it treats the zone as unsigned? Wouldn't it be better to make that general point clear... and then give unknown or unsupported key or message digest algorithms as reasons it would be unable to validate?

========Other comments; no need to respond to these. Take them or modify themas you please:

-- 2 --There's a SSnake in the graSSS in the SSection title.

2012-06-05

18

Barry Leiba

[Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba

2012-06-04

18

Wesley Eddy

[Ballot Position Update] New position, Yes, has been recorded for Wesley Eddy

2012-06-04

18

Ron Bonica

[Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica

2012-06-04

18

Martin Stiemerling

[Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling

2012-06-01

18

Adrian Farrel

[Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel

2012-06-01

18

Russ Housley

[Ballot discuss]

The Gen-ART Review by Richard Barnes on 25-May-2012 raised two major concerns. The Gen-ART Review can be found here: ...

(1) Section 4.1: Please clarify the threat model. If the zone operator is malicious, then it can simulate the necessary zone cut and still prove the non-existence of records in the child zone.

(2) Section 5.10: Please explain why the "Accept Any Success" policy is more preferable the "Highest Signer" policy. This analysis might not appear in Section 5.10; it could appear in an appendix.

2012-06-01

18

Russ Housley

[Ballot Position Update] New position, Discuss, has been recorded for Russ Housley

2012-05-31

18

(System)

State changed to Waiting for AD Go-Ahead from In Last Call

2012-05-30

18

Brian Haberman

[Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman

2012-05-25

18

Sean Turner

[Ballot comment]These are my preliminary sets of comments:

1) Any reason you can't just refer to DNSSECbis as DNSSEC? I guess does ...

[Ballot comment]These are my preliminary sets of comments:

1) Any reason you can't just refer to DNSSECbis as DNSSEC? I guess does the outside world know DNSSECbis isn't DNSSEC?

2) General: r/RFCXXXX/[RFCXXXX] throughout except for the abstract. A couple of times I thought the RFC references needed to be included in [] so it's probably better to just do it everywhere. You also need to add [RFC2308] as a reference.

4) s1.2: To cut down on the possible "where is X defined" you could add something like: "Readers are assumed to be familiar with DNSSECbis documents as the terminology used herein comes from those documents."

5) s2, s2.1, s2.2: Could you replace the three instances of "should {also} be" with "are"? If the WG considers them part of the core, then aren't they? It also avoids the whole question about whether it ought to be SHOULD (not that I'm asking to change that).

6) s2.1: Pet peeve requirements in a paragraph that starts with Note. Couldn't you just r/Note that the/The

7) s5.5: Might be worth pointing out that this was filed as an errata.

8) s5.6, s5.7, and s5.10: I was already to give you the kudos for each section being clear about which document was being updated until I got to these sections. Please state which RFC you're updating in these sections. In s5.6 is it updating 3225?

9) s5.11: could you just strike "note that"

2012-05-25

18

Sean Turner

Ballot comment text updated for Sean Turner

2012-05-25

18

Sean Turner

[Ballot comment]These are my preliminary sets of comments:

1) Any reason you can't just refer to DNSSECbis as DNSSEC? I guess does ...

[Ballot comment]These are my preliminary sets of comments:

1) Any reason you can't just refer to DNSSECbis as DNSSEC? I guess does the outside world know DNSSECbis isn't DNSSEC?

2) General: r/RFCXXXX/[RFCXXXX] throughout except for the abstract. A couple of times I thought the RFC references needed to be included in [] so it's probably better to just do it everywhere. You also need to add [RFC2308] as a reference.

3) s1.2: To cut down on the possible "where is X defined" you could add something like: "Readers are assumed to be familiar with DNSSECbis documents as the terminology used herein comes from those documents."

3) s2, s2.1, s2.2: Could you replace the three instances of "should {also} be" with "are"? If the WG considers them part of the core, then aren't they? It also avoids the whole question about whether it ought to be SHOULD (not that I'm asking to change that).

4) s2.1: Pet peeve requirements in a paragraph that starts with Note. Couldn't you just r/Note that the/The

5) s5.5: Might be worth pointing out that this was filed as an errata.

6) s5.6, s5.7, and s5.10: I was already to give you the kudos for each section being clear about which document was being updated until I got to these sections. Please state which RFC you're updating in these sections. In s5.6 is it updating 3225?

7) s5.11: could you just strike "note that"

2012-05-25

18

Sean Turner

[Ballot Position Update] New position, No Objection, has been recorded for Sean Turner

2012-05-25

18

Ralph Droms

Ballot has been issued

2012-05-25

18

Ralph Droms

[Ballot Position Update] New position, Yes, has been recorded for Ralph Droms

2012-05-25

18

Ralph Droms

Created "Approve" ballot

2012-05-23

18

Ralph Droms

Placed on agenda for telechat - 2012-06-07

2012-05-21

18

Pearl Liang

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.

The IESG has received a request from the DNS Extensions WG (dnsext) toconsider the following document:- 'Clarifications and Implementation Notes for DNSSECbis' <draft-ietf-dnsext-dnssec-bis-updates-18.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicitsfinal comments on this action. Please send substantive comments to theietf@ietf.org mailing lists by 2012-05-31. Exceptionally, comments may besent to iesg@ietf.org instead. In either case, please retain thebeginning of the Subject line to allow automated sorting.

Abstract

This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata.

This document updates the core DNSSECbis documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification.

PROTO write up for draft-ietf-dnsext-dnssec-bis-updates-182012-05-01Template version 2012-02-24

(1) What type of RFC is being requested (BCP, Proposed Standard,Internet Standard, Informational, Experimental, or ...

PROTO write up for draft-ietf-dnsext-dnssec-bis-updates-182012-05-01Template version 2012-02-24

(1) What type of RFC is being requested (BCP, Proposed Standard,Internet Standard, Informational, Experimental, or Historic)? Whyis this the proper type of RFC? Is this type of RFC indicated in thetitle page header?

The request is for Proposed Standard. The documents it is updating are all at the Proposed Standard level, and this document reflects experience with and clarifications of those. The type is indicated in the header.

(2) The IESG approval announcement includes a Document AnnouncementWrite-Up. Please provide such a Document Announcement Write-Up. Recentexamples can be found in the "Action" announcements for approveddocuments. The approval announcement contains the following sections:

Technical Summary

DNSSECbis was published in RFC 4033, RFC 4034, and RFC 4035. Since the publication, some people filed errata against those documents, some additional developments added to DNSSECbis, and some implementation experience illustrated ambiguities or issues with the original texts. This draft collects those issues in a single place, updating the DNSSECbis specification and clarifying it where need be.

Working Group Summary

This draft is the product of the DNS Extensions Working Group. Many of the clarifications came easily. The more contentious parts of the document have been discussed at length. For the most controversial of the clarifications, extensive discussion is included in appendices so that implementers and deployers may make informed decisions.

Document Quality

Most, if not all, of the document is reflected in the bulk of DNSSECbis validators and signers deployed on the Internet. The document is the result of several years of experience and discussion, collected with an eye to improving implementations. One of the most contentious parts resulted in multiple rounds of discussion and a special design team meeting. The document as it stands has been refined over a long period of time, and is of high quality.

Personnel

Who is the Document Shepherd? Who is the Responsible Area Director?

Andrew Sullivan is the Document Shepherd, and Ralph Droms is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed bythe Document Shepherd. If this version of the document is not readyfor publication, please explain why the document is being forwarded tothe IESG.

The shepherd performed multiple complete reviews, and is satisfied the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth orbreadth of the reviews that have been performed?

No. The WG has a requirement of at least five reviews prior to publication, and this document easily met that. In addition, some of the reviews were from long-standing critics of earlier versions.

(5) Do portions of the document need review from a particular or frombroader perspective, e.g., security, operational complexity, AAA, DNS,DHCP, XML, or internationalization? If so, describe the review thattook place.

No.

(6) Describe any specific concerns or issues that the Document Shepherdhas with this document that the Responsible Area Director and/or theIESG should be aware of? For example, perhaps he or she is uncomfortablewith certain parts of the document, or has concerns whether there reallyis a need for it. In any event, if the WG has discussed those issues andhas indicated that it still wishes to advance the document, detail thoseconcerns here.

Section 5.6 represents a clear change to the protocol. This change is amply documented in practice, but it is nevertheless a change to the protocol. The Shepherd would have preferred something that did not actually change the protocol, but the document editors and a small number of reviewers said they preferred this formulation. The change happened during WGLC. Few people responded to a special request to comment on this issue, so it is not clear how strong the agreement is with this change in the protocol. It is indisputable, however, that some deployed instances work according to the new text, and interoperability is likely maximized by making the change in section 5.6.

(7) Has each author confirmed that any and all appropriate IPRdisclosures required for full conformance with the provisions of BCP 78and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?If so, summarize any WG discussion and conclusion regarding the IPRdisclosures.

No. There is an IPR filing against RFC 5155, which this draft updates, but it does not seem to impinge on this draft.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with othersbeing silent, or does the WG as a whole understand and agree with it?

The document has been through many iterations, a large amount of review, and several rounds of discussion about particular issues.

There is one section, 5.9, that continues to be a sore point with one WG participant (the participant is also a notable contributor to an important implementation). Repeated requests during WGLC for expressions of support of that participant's position yielded no results.

Section 5.9 was changed after WGLC because a participant (different than the one who objects to section 5.9 overall) said that it did not apply to stub resolvers. On further reflection, the authors reverted the change, because they thought it might be incorrect.

Section 5.9 remains the area of most controversy.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separateemail messages to the Responsible Area Director. (It should be in aseparate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in thisdocument. (See http://www.ietf.org/tools/idnits/ and the Internet-DraftsChecklist). Boilerplate checks are not enough; this check needs to bethorough.

There are none.

(12) Describe how the document meets any required formal reviewcriteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified aseither normative or informative?

Yes

(14) Are there normative references to documents that are not ready foradvancement or are otherwise in an unclear state? If such normativereferences exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?If so, list these downward references to support the Area Director in theLast Call procedure.

No.

(16) Will publication of this document change the status of anyexisting RFCs? Are those RFCs listed on the title page header, listedin the abstract, and discussed in the introduction? If the RFCs are notlisted in the Abstract and Introduction, explain why, and point to thepart of the document where the relationship of this document to theother RFCs is discussed. If this information is not in the document,explain why the WG considers it unnecessary.

It will not change the formal status of any, but it does update several. They are all listed. The way that documents are treated together (informally) as the DNSSEC core is also updated, and that is also called out in the document.

(17) Describe the Document Shepherd's review of the IANA considerationssection, especially with regard to its consistency with the body of thedocument. Confirm that all protocol extensions that the document makesare associated with the appropriate reservations in IANA registries.Confirm that any referenced IANA registries have been clearlyidentified. Confirm that newly created IANA registries include adetailed specification of the initial contents for the registry, thatallocations procedures for future registrations are defined, and areasonable name for the new registry has been suggested (see RFC 5226).

There are no actions for IANA.

(18) List any new IANA registries that require Expert Review for futureallocations. Provide any public guidance that the IESG would finduseful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the DocumentShepherd to validate sections of the document written in a formallanguage, such as XML code, BNF rules, MIB definitions, etc.: