Skip to main content

A Root Key Trust Anchor Sentinel for DNSSEC
draft-ietf-dnsop-kskroll-sentinel-17

Revision differences

Document history

Date Rev. By Action
2019-08-19
17 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2019-08-19
17 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Tina Tsou was marked no-response
2018-12-18
17 (System)
Received changes through RFC Editor sync (created alias RFC 8509, changed abstract to 'The DNS Security Extensions (DNSSEC) were developed to provide origin authentication …
Received changes through RFC Editor sync (created alias RFC 8509, changed abstract to 'The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS.  This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries.  Note that this method is only applicable for determining which keys are in the trust store for the root key.', changed pages to 19, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-12-18, changed IESG state to RFC Published)
2018-12-18
17 (System) RFC published
2018-12-17
17 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8509">AUTH48-DONE</a> from AUTH48
2018-12-13
17 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8509">AUTH48</a> from RFC-EDITOR
2018-11-20
17 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-11-09
17 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2018-11-05
17 (System) RFC Editor state changed to EDIT
2018-11-05
17 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-11-05
17 (System) Announcement was received by RFC Editor
2018-11-05
17 (System) IANA Action state changed to No IANA Actions
2018-11-04
17 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2018-11-04
17 Cindy Morgan IESG has approved the document
2018-11-04
17 Cindy Morgan Closed "Approve" ballot
2018-11-04
17 Cindy Morgan Ballot approval text was generated
2018-10-21
17 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-17.txt
2018-10-21
17 (System) New version approved
2018-10-21
17 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-10-21
17 Warren Kumari Uploaded new revision
2018-10-21
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-10-21
16 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-10-21
16 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-16.txt
2018-10-21
16 (System) New version approved
2018-10-21
16 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-10-21
16 Warren Kumari Uploaded new revision
2018-10-18
15 Benjamin Kaduk
[Ballot comment]
Thanks for addressing my Discuss points -- the text in the github version of
this document helps a lot, and I'm happy with …
[Ballot comment]
Thanks for addressing my Discuss points -- the text in the github version of
this document helps a lot, and I'm happy with the direction we're going in
for the more general case.

[original ballot comments preserved below]

Other than my Discuss points, I just have a number of essentially editorial
nits.

Abstract

                                This document specifies a mechanism that
  will allow an end user and third parties to determine the trusted key
  state for the root key of the resolvers that handle that user's DNS
  queries.  [...]

This wording feels confusing to me; I think what it's trying to say is "the
root key(s) that are in use by the resolver" but am having a hard time
grouping these words to achieve that meaning.  (Is "trust" really necessary
to mention, here?)

Section 1

              RRSIG RRs contain a Key Tag field whose value is equal to
  the Key Tag of the DNSKEY RR that was used to generate the
  corresponding signature.

nit: Is the RR used to generate the signature, or just the key?

  o  Users may wish to ascertain whether their DNS resolution
      environment resolvers is ready for an upcoming root KSK rollover.

nit: I think there's a singular/plural mismatch or similar here, maybe
"environment's resolver"?

  o  Researchers want to perform Internet-wide studies about the
      proportion of users who will be negatively impacted an upcoming
      root KSK rollover.

nit: "by an upcoming"

  If a browser or operating system is configured with multiple
  resolvers, and those resolvers have different properties (for
  example, one performs DNSSEC validation and one does not), the
  sentinel test described in this document can still be used, but it

nit: this usage of "but" feels a bit misplaced to me, as the thing being
warned about is more that the test may produce indeterminate or
inconsistent results.  Or perhaps that the assumptions it makes may not
necessarily hold in the specific environments being described (i.e., "these
environments").

  makes a number of assumptions about DNS resolution behaviour that may
  not necessarily hold in all environments.  If these assumptions do
  not hold (such as, for example, requiring the stub resolver to query
  the next recursive resolver in the locally configured set upon
  receipt of a SERVFAIL response code) then this test may produce
  indeterminate or inconsistent results.  In some cases where these
  assumptions do not hold, repeating the same test query set may
  generate different results.

Section 1.1

Please use the RFC 8174 boilerplate.

Section 3

I'll note without further comment that we had a long thread on ietf@
relevant to the term "slave resolver".

Section 3.1

  If the resolver is non-validating, and it has a single forwarder,
  then the resolver will presumably mirror the capabilities of the
  forwarder target resolver.

Perhaps this is just me misreading the previous paragraph's introduction to
what is clearly a more widely known term of art, but in "has a single
forwarder" is the thing of which there is only one the "one or more other
resolvers" that the "forwarder" is relaying queries to?  It's just weird
for the word "forwarder" mean a different protocol participant when used as
a noun vs. adjective.  Or perhaps this is meant to be possessive; the
"forwarder's target resolver"?

As noted in the directorate review, "use the CD bit" needs disambiguation.

Section 4

nit: missing trailing 'r' in the section title

Section 4.3

Maybe call out that these are the same general categories of query as in
Section 3 but the key tag used is different for some queries?

It's also a bit weird to use new notation for this section as opposed to
consistent notation between the different types of test.
2018-10-18
15 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2018-09-27
15 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-09-27
15 Alexey Melnikov
[Ballot comment]
Benjamin asked:

  The first one may just be something that I missed, but does this document
  actually say anywhere that there …
[Ballot comment]
Benjamin asked:

  The first one may just be something that I missed, but does this document
  actually say anywhere that there needs to be a real zone with real
  configured A and/or AAAA records for the query names used for these tests?
  The Appendix sort-of-mentions it, but I feel like there needs to be a
  mention in the main body text.

The same question bothered me a lot and made understanding purpose of the document hard. Please clarify this early on in the document.
2018-09-27
15 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-09-27
15 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-09-26
15 Adam Roach
[Ballot comment]
I am balloting "no objection," although I share Benjamin's concerns about the
claiming of leaf nodes in the DNS system. However, I think …
[Ballot comment]
I am balloting "no objection," although I share Benjamin's concerns about the
claiming of leaf nodes in the DNS system. However, I think that issue is larger
than just this document, and that we are unlikely to come to an agreement within
the DNS community about how to handle it in a reasonable amount of time.

I have some additional comments, below.

---------------------------------------------------------------------------

§4:

> 4.  Sentinel Tests from Hosts with More than One Configured Resolve

Nit: "...Resolvers"

---------------------------------------------------------------------------

§4.2:

One of the implicit assumptions of this section appears to be that the client
performing this test will necessarily be using gethostbyname() (or something
similar), and at the mercy of the underlying library with regard to the test
assumptions. On systems where the list of configured resolvers can be retrieved
programmatically (e.g., 'scutil --dns' under OS X, or the contents of /etc/hosts
on most other Unices), I would guess that more reliable results could be
achieved by treating the three bullets in section 4.2 as requirements on the
testing client rather than assumptions that may make the results invalid if they
don't hold.

Concretely: I believe it would be useful to add text to this section suggesting
that clients can achieve more reliable results by bypassing the local stub
resolver and implementing queries themselves (in a fashion similar to the
popular "dig" utility), which allows them to ensure that these assumptions are
true.

---------------------------------------------------------------------------

Appendix A:

This walkthrough uses the name "bogus.example.com" for the bogus record used in
the testing. I've gone looking through the document and cannot determine whether
this is canonical or just the name this example uses. I presume it's the latter.
It's probably worth adding text to this example which explains that the choice
of "bogus" by Geoff is a site-local decision. What I'd like to avoid is having
situations where people hardcode "bogus" into some tooling suite, and then cause
sites like "github.io" grief in the case that the (already-registered) user with
a username of "bogus" attempts to set up a page at "https://bogus.github.io/").
2018-09-26
15 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-09-26
15 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-09-26
15 Ben Campbell
[Ballot comment]
Just a couple of nits:

§1, the two bullet points:

"... DNS resolution environment resolvers is ready...": Plural mismatch, although I wonder if …
[Ballot comment]
Just a couple of nits:

§1, the two bullet points:

"... DNS resolution environment resolvers is ready...": Plural mismatch, although I wonder if both "environment" and "resolvers" were intended to be there.

"... negatively impacted an upcoming root KSK rollover.": Missing word after "impacted"?
2018-09-26
15 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-09-26
15 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-09-26
15 Benjamin Kaduk
[Ballot discuss]
Thanks for preparing this document and mechanism; it is good to have more
data about the expected impact of the root KSK roll.  …
[Ballot discuss]
Thanks for preparing this document and mechanism; it is good to have more
data about the expected impact of the root KSK roll.  That said, I have two
Discuss-worthy points, albeit both fairly minor.

The first one may just be something that I missed, but does this document
actually say anywhere that there needs to be a real zone with real
configured A and/or AAAA records for the query names used for these tests?
The Appendix sort-of-mentions it, but I feel like there needs to be a
mention in the main body text.

The other point basically is a procedural one, in that we are in effect
claiming a couple of leaf name prefixes in all domains to exhibit "weird
and surprising behavior" (that is, for parties unaware of this
specification).  We generally try to avoid this sort of namespace
squatting, preferring (e.g.) /.well-known for HTTP requests, various
underscore-prefixed tricks for the DNS, etc.  I see in the changelog that
initial attempts did use an underscore prefix but ran into implementation
difficulty, and acknowledge that using a "magic" name is much easier to get
deployed than (e.g.) a new RR type.  But I do not want the IESG to
implicitly approve a namespace claim like this; it's better to be explicit
about it if this is the best way to go.
2018-09-26
15 Benjamin Kaduk
[Ballot comment]
Other than my Discuss points, I just have a number of essentially editorial
nits.

Abstract

                …
[Ballot comment]
Other than my Discuss points, I just have a number of essentially editorial
nits.

Abstract

                                This document specifies a mechanism that
  will allow an end user and third parties to determine the trusted key
  state for the root key of the resolvers that handle that user's DNS
  queries.  [...]

This wording feels confusing to me; I think what it's trying to say is "the
root key(s) that are in use by the resolver" but am having a hard time
grouping these words to achieve that meaning.  (Is "trust" really necessary
to mention, here?)

Section 1

              RRSIG RRs contain a Key Tag field whose value is equal to
  the Key Tag of the DNSKEY RR that was used to generate the
  corresponding signature.

nit: Is the RR used to generate the signature, or just the key?

  o  Users may wish to ascertain whether their DNS resolution
      environment resolvers is ready for an upcoming root KSK rollover.

nit: I think there's a singular/plural mismatch or similar here, maybe
"environment's resolver"?

  o  Researchers want to perform Internet-wide studies about the
      proportion of users who will be negatively impacted an upcoming
      root KSK rollover.

nit: "by an upcoming"

  If a browser or operating system is configured with multiple
  resolvers, and those resolvers have different properties (for
  example, one performs DNSSEC validation and one does not), the
  sentinel test described in this document can still be used, but it

nit: this usage of "but" feels a bit misplaced to me, as the thing being
warned about is more that the test may produce indeterminate or
inconsistent results.  Or perhaps that the assumptions it makes may not
necessarily hold in the specific environments being described (i.e., "these
environments").

  makes a number of assumptions about DNS resolution behaviour that may
  not necessarily hold in all environments.  If these assumptions do
  not hold (such as, for example, requiring the stub resolver to query
  the next recursive resolver in the locally configured set upon
  receipt of a SERVFAIL response code) then this test may produce
  indeterminate or inconsistent results.  In some cases where these
  assumptions do not hold, repeating the same test query set may
  generate different results.

Section 1.1

Please use the RFC 8174 boilerplate.

Section 3

I'll note without further comment that we had a long thread on ietf@
relevant to the term "slave resolver".

Section 3.1

  If the resolver is non-validating, and it has a single forwarder,
  then the resolver will presumably mirror the capabilities of the
  forwarder target resolver.

Perhaps this is just me misreading the previous paragraph's introduction to
what is clearly a more widely known term of art, but in "has a single
forwarder" is the thing of which there is only one the "one or more other
resolvers" that the "forwarder" is relaying queries to?  It's just weird
for the word "forwarder" mean a different protocol participant when used as
a noun vs. adjective.  Or perhaps this is meant to be possessive; the
"forwarder's target resolver"?

As noted in the directorate review, "use the CD bit" needs disambiguation.

Section 4

nit: missing trailing 'r' in the section title

Section 4.3

Maybe call out that these are the same general categories of query as in
Section 3 but the key tag used is different for some queries?

It's also a bit weird to use new notation for this section as opposed to
consistent notation between the different types of test.
2018-09-26
15 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2018-09-25
15 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-09-24
15 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-09-20
15 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-09-13
15 Terry Manderson IESG state changed to IESG Evaluation from Waiting for Writeup
2018-09-10
15 Warren Kumari [Ballot comment]
Recusing because author.

ADs, avoid balloting with this weird trick..... :-P
2018-09-10
15 Warren Kumari [Ballot Position Update] New position, Recuse, has been recorded for Warren Kumari
2018-09-10
15 Amy Vezza Placed on agenda for telechat - 2018-09-27
2018-09-09
15 Terry Manderson Ballot has been issued
2018-09-09
15 Terry Manderson [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson
2018-09-09
15 Terry Manderson Created "Approve" ballot
2018-09-09
15 Terry Manderson Ballot writeup was changed
2018-09-06
15 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-08-30
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2018-08-30
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2018-08-29
15 Jari Arkko Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Jari Arkko. Sent review to list.
2018-08-28
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tina Tsou
2018-08-28
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tina Tsou
2018-08-27
15 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-08-27
15 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-kskroll-sentinel-15, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-kskroll-sentinel-15, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-08-23
15 Jean Mahoney Request for Last Call review by GENART is assigned to Jari Arkko
2018-08-23
15 Jean Mahoney Request for Last Call review by GENART is assigned to Jari Arkko
2018-08-23
15 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-08-23
15 Amy Vezza
The following Last Call announcement was sent out (ends 2018-09-06):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2018-09-06):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, Benno Overeinder <benno@NLnetLabs.nl>, dnsop@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, terry.manderson@icann.org, draft-ietf-dnsop-kskroll-sentinel@ietf.org
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-dnsop-kskroll-sentinel-15.txt> (A Root Key Trust Anchor Sentinel for DNSSEC) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'A Root Key Trust Anchor
Sentinel for DNSSEC'
  <draft-ietf-dnsop-kskroll-sentinel-15.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-09-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The DNS Security Extensions (DNSSEC) were developed to provide origin
  authentication and integrity protection for DNS data by using digital
  signatures.  These digital signatures can be verified by building a
  chain of trust starting from a trust anchor and proceeding down to a
  particular node in the DNS.  This document specifies a mechanism that
  will allow an end user and third parties to determine the trusted key
  state for the root key of the resolvers that handle that user's DNS
  queries.  Note that this method is only applicable for determining
  which keys are in the trust store for the root key.

  [ This document is being collaborated on in Github at:
  https://github.com/APNIC-Labs/draft-kskroll-sentinel.  The most
  recent version of the document, open issues, etc should all be
  available here.  The authors (gratefully) accept pull requests.  RFC
  Editor, please remove text in square brackets before publication. ]




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-08-23
15 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-08-23
15 Terry Manderson Last call was requested
2018-08-23
15 Terry Manderson Ballot approval text was generated
2018-08-23
15 Terry Manderson Ballot writeup was generated
2018-08-23
15 Terry Manderson IESG state changed to Last Call Requested from AD Evaluation
2018-08-23
15 Terry Manderson Last call announcement was generated
2018-07-31
15 Terry Manderson IESG state changed to AD Evaluation from Publication Requested
2018-07-20
15 Tim Wicinski
(1) What type of RFC is being requested

  Standards Track


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a …
(1) What type of RFC is being requested

  Standards Track


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

Technical Summary:

  The DNS Security Extensions (DNSSEC) were developed to provide origin
  authentication and integrity protection for DNS data by using digital
  signatures.  These digital signatures can be verified by building a
  chain of trust starting from a trust anchor and proceeding down to a
  particular node in the DNS.  This document specifies a mechanism that
  will allow an end user and third parties to determine the trusted key
  state for the root key of the resolvers that handle that user's DNS
  queries.  Note that this method is only applicable for determining
  which keys are in the trust store for the root key.


Working Group Summary:

  This document has had a short history, and came about while working with ICANN on
  the KSK rollover process, as a way to assist tracking the addition and removal of DNSSEC
  keys.


Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  WG criticism of the design approach produced at least two implementations of the design.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors
indicated their plan to implement the specification?

  There are two different implementations of the design.

Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  No.


Personnel:

Document Shepherd: Tim Wicinski

Responsible Area Director: In this case since the DNSOP AD is a co-author (Warren Kumari),
  we have Terry Manderson to step in his place.  They chairs thank Mr. Manderson for
  his assistance in this.

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

  The shepherd has been involved during the working group process reviewing versions,
  looking for editorial issues,

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

  No.


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

  No other reviews are needed.


(6) Describe any specific concerns or issues that the Document Shepherd has with this
document that the Responsible Area Director and/or the IESG should be aware of?

None.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for
full conformance with the provisions of BCP 78 and 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 IPR disclosures.

  No.

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

  Solid.


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

  No.


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

  No nits.


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

  None needed. 

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

  Yes.


(14) Are there normative references to documents that are not ready for advancement or
are otherwise in an unclear state? If such normative references 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 the Last Call procedure.



(16) Will publication of this document change the status of any existing RFCs? 
Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.

  N/A


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

  None.


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

  The documents were produced with an XML editor and were processed
through the IETF's ID Nits engine, and txt files were produced from the
XML by the IETF's Internet Drafts submission process.
2018-07-20
15 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-07-20
15 Tim Wicinski IESG state changed to Publication Requested
2018-07-20
15 Tim Wicinski IESG process started in state Publication Requested
2018-07-20
15 Tim Wicinski Changed document writeup
2018-07-20
15 Tim Wicinski Notification list changed to Benno Overeinder <benno@NLnetLabs.nl>, Tim Wicinski <tjw.ietf@gmail.com> from Benno Overeinder <benno@NLnetLabs.nl>
2018-07-20
15 Tim Wicinski Document shepherd changed to Tim Wicinski
2018-07-04
15 Benno Overeinder IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-07-02
15 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-15.txt
2018-07-02
15 (System) New version approved
2018-07-02
15 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-07-02
15 Warren Kumari Uploaded new revision
2018-06-22
14 Tim Wicinski Notification list changed to Benno Overeinder <benno@NLnetLabs.nl>
2018-06-22
14 Tim Wicinski Document shepherd changed to Benno Overeinder
2018-06-11
14 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-14.txt
2018-06-11
14 (System) New version approved
2018-06-11
14 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-06-11
14 Warren Kumari Uploaded new revision
2018-06-11
14 Warren Kumari Uploaded new revision
2018-06-05
13 Geoff Huston New version available: draft-ietf-dnsop-kskroll-sentinel-13.txt
2018-06-05
13 (System) New version approved
2018-06-05
13 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-06-05
13 Geoff Huston Uploaded new revision
2018-05-03
12 Geoff Huston New version available: draft-ietf-dnsop-kskroll-sentinel-12.txt
2018-05-03
12 (System) New version approved
2018-05-03
12 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-05-03
12 Geoff Huston Uploaded new revision
2018-04-10
11 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2018-04-09
11 Warren Kumari Shepherding AD changed to Terry Manderson
2018-04-04
11 Geoff Huston New version available: draft-ietf-dnsop-kskroll-sentinel-11.txt
2018-04-04
11 (System) New version approved
2018-04-04
11 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-04-04
11 Geoff Huston Uploaded new revision
2018-04-02
10 Geoff Huston New version available: draft-ietf-dnsop-kskroll-sentinel-10.txt
2018-04-02
10 (System) New version approved
2018-04-02
10 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-04-02
10 Geoff Huston Uploaded new revision
2018-03-26
09 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-09.txt
2018-03-26
09 (System) New version approved
2018-03-26
09 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-03-26
09 Warren Kumari Uploaded new revision
2018-03-24
08 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-08.txt
2018-03-24
08 (System) New version approved
2018-03-24
08 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-03-24
08 Warren Kumari Uploaded new revision
2018-03-20
07 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-07.txt
2018-03-20
07 (System) New version approved
2018-03-20
07 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-03-20
07 Warren Kumari Uploaded new revision
2018-03-05
06 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-06.txt
2018-03-05
06 (System) New version approved
2018-03-05
06 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-03-05
06 Warren Kumari Uploaded new revision
2018-03-05
05 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-05.txt
2018-03-05
05 (System) New version approved
2018-03-05
05 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-03-05
05 Warren Kumari Uploaded new revision
2018-02-28
04 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-04.txt
2018-02-28
04 (System) New version approved
2018-02-28
04 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-02-28
04 Warren Kumari Uploaded new revision
2018-02-28
03 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-03.txt
2018-02-28
03 (System) New version approved
2018-02-28
03 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-02-28
03 Warren Kumari Uploaded new revision
2018-02-21
02 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-02.txt
2018-02-21
02 (System) New version approved
2018-02-21
02 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-02-21
02 Warren Kumari Uploaded new revision
2018-02-12
01 Warren Kumari New version available: draft-ietf-dnsop-kskroll-sentinel-01.txt
2018-02-12
01 (System) New version approved
2018-02-12
01 (System) Request for posting confirmation emailed to previous authors: Joao Damas <joao@apnic.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>
2018-02-12
01 Warren Kumari Uploaded new revision
2017-12-10
00 Tim Wicinski Changed consensus to Yes from Unknown
2017-12-10
00 Tim Wicinski Intended Status changed to Proposed Standard from None
2017-12-10
00 Tim Wicinski This document now replaces draft-huston-kskroll-sentinel instead of None
2017-12-10
00 Geoff Huston New version available: draft-ietf-dnsop-kskroll-sentinel-00.txt
2017-12-10
00 (System) WG -00 approved
2017-12-10
00 Geoff Huston Set submitter to "Geoff Huston <gih@apnic.net>", replaces to (none) and sent approval email to group chairs: dnsop-chairs@ietf.org
2017-12-10
00 Geoff Huston Uploaded new revision