IETF conflict review for draft-jabley-dnssec-trust-anchor
conflict-review-jabley-dnssec-trust-anchor-01

The following approval message was sent
From: The IESG
To: draft-jabley-dnssec-trust-anchor@ietf.org,
    "Nevil Brownlee" ,
    rfc-ise@rfc-editor.org
Cc: "The IESG" ,
    iana@iana.org,
    "IETF-Announce"
Subject: Results of IETF-conflict review for draft-jabley-dnssec-trust-anchor-15

The IESG has completed a review of draft-jabley-dnssec-trust-anchor-15
consistent with RFC5742.


The IESG has no problem with the publication of 'DNSSEC Trust Anchor
Publication for the Root Zone'
as an Informational RFC.


The IESG has concluded that this work is related to IETF work done in the
concluded dnssec, dnsext and active dnsop Working Groups, but this
relationship does not prevent publishing.



The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine
whether or not they merit incorporation into the document. Comments may
exist in both the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-jabley-dnssec-trust-anchor/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-jabley-dnssec-trust-anchor/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]

Terry's discuss sounds right to me.

And while I've no other issue with the content of the document I do
wonder why it'd not be better to process this as an IETF stream
document, just in case.

[Ballot discuss]
I have a concern with the text in the IANA considerations section of this document which I *think* conflicts with IETF process.

I'm not concerned with the assignment of the value in the SMI Security for PKIX Module Identifier registry. That is fine given the construct of that registry.

It is with:

"Key Signing Key (KSK) management for the root zone is an IANA
  function.  This document describes an initial set of publication
  mechanisms for trust anchors related to that management.  In the
  future, additional publication schemes may also be made available, in
  which case they will be described in a new document that updates this
  one."

I don't think this is appropriate for an informational ISE document. It feels like it's trying to add subtle 'IANA can do what it likes' text. I've reached out to Joe and Paul and suggested text as follows given the vast descriptive text in this document about what IANA/etc does.

=-=-=-==-
This document defines id-mod-dns-resource-record, value 70 (see section
2.2), in the SMI Security for PKIX Module Identifier registry.

Beyond the registry assignment above, this document makes no other
requests and places no further restrictions on IANA.
=-=-=-=-=-

[Ballot discuss]
I have a concern with the text in the IANA considerations section of this document which I *think* conflicts with IETF process.

I'm not concerned with the assignment of the value in the SMI Security for PKIX Module Identifier registry. That is fine given the construct of that registry.

It is with:

"Key Signing Key (KSK) management for the root zone is an IANA
  function.  This document describes an initial set of publication
  mechanisms for trust anchors related to that management.  In the
  future, additional publication schemes may also be made available, in
  which case they will be described in a new document that updates this
  one."

I don't think this is appropriate for an informational ISE document. It feels like it's trying to add subtle 'IANA can do what it likes' text. I've reached out to Joe and Paul and suggested text as follows given the vast descriptive text about what IANA/etc does.

=-=-=-==-
This document defines id-mod-dns-resource-record, value 70 (see section
2.2), in the SMI Security for PKIX Module Identifier registry.

Beyond the registry assignment above, this document makes no other
requests and places no further restrictions on IANA.
=-=-=-=-=-