(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
The RFC is being requested as an Internet Standard. The
Internet-Draft is a bis document to RFC2845 and updates RFC4635, both
Proposed Standard RFCs.
Since the publication of RFC2845 and RFC4635, many DNS name servers
have implemented the RFCs. Given the maturity of the protocols and
this rfc2845bis draft, Internet Standards seem to be appropriate. It
also meets the maturity level specified in RFC6410, section 2.2.
(2) The IESG approval announcement includes a Document Announcement
Write-Up.
Technical Summary:
This document describes a protocol for DNS for transaction level
authentication using shared secrets and one way hashing. It can be
used to authenticate dynamic DNS updates as coming from an approved
client, or to authenticate responses as coming from an approved DNS
name server.
No recommendation is made here for distributing the shared secrets: it
is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism.
The draft obsoletes RFC2845 and RFC4635.
Working Group Summary:
The draft updates RFC2845, because due to some ambiguity in the
wording of the document, different implementations made decisions that
caused operational problems, see also Section 1.3. The draft was
swiftly adopted to become a DNSOP WG document. After WG adoption, the
authors of the original RFC2845 have also been added to the author
list. The WG stated that the document was not just an errata, but a
bis, so the document could improve the readability and wording of the
protocol specification.
Document Quality:
A recent implementation of RFC2845 used the rfc2845bis draft to
implement TSIG. The new draft document is much clearer and offers
better implementation guidance than the original. RFC2845 is
implemented by all known open source DNS name servers and, as far as
the shepherd knows, all commercial DNS name servers (not knowing for
proprietary name servers).
The implementer (Martin Hoffmann, NLnet Labs) has provided good
feedback to improve the text of the rfc2845bis draft and to reorganize
some sections. Other feedback from the working group has also been
processed.
Personnel:
Document Shepherd: Benno Overeinder
Responsible Area Director: Warren Kumari
(3) The shepherd followed the mailing list discussion closely and
encouraged implementor Martin Hoffmann to send his feedback on the
document to the mailing list (and authors). The shepherd also
reviewed the document himself and during the WGLC encouraged the
working group participants to send feedback or simply say yes/no.
We feel the document is ready for publication.
(4) The Document Shepherd has no concerns on the depth or breadth of
the reviews.
(5) There is no need for broader review.
(6) There are no concerns from the document shepherd.
(7) No IPR disclosures.
(8) There is no IPR.
(9) WG consensus is clear. There were no conflicting insights or
opinions.
(10) There has been no appeals.
(11) One of the idnits is "The document seems to contain a disclaimer
for pre-RFC5378 work, but was first submitted on or after 10 November
2008." The draft contains material from RFC2845 that was published
before November 10, 2008.
(12) No formal reviews needed.
(13) All references have been identified as either normative or
informative.
(14) There are no normative references waiting to advance.
(15) According to idnits there is a possible downward normative
reference:
-- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4'
The possible downrefs is an external standard.
(16) This document obsoletes RFC2845 and RFC4635, as mentioned in the
title page header and in the abstract of the document.
(17) The Document Shepherd has reviewed the IANA considerations
section of the document. This a bis document and no new IANA registry
reservations has been made. All referenced IANA registries have been
clearly identified.
(18) There are no new IANA registries.
(19) There are no sections written in a formal language, such as XML
code, BNF rules, MIB definitions, YANG modules, etc.
(20) The document does not contain a YANG module.