Subject: [DNSOP] Working Group Last Call draft-ietf-dnsop-edns-key-tag

From: Tim Wicinski <[email-masked]>
Date: Thu, 6 Oct 2016 03:00:36 -0400

The authors for this document have addressed some lingering  outstanding 
issues, and it appears ready for Working Group Last Call.

This starts a Working Group Last Call for:
    draft-ietf-dnsop-edns-key-tag

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

This starts a two week Working Group Last Call process, and ends on 20 
October 2016

thanks
tim

---

From: 神明達哉 <[email-masked]>
Date: Fri, 7 Oct 2016 11:53:40 -0700

At Thu, 6 Oct 2016 03:00:36 -0400,

> feels the document is *not* ready for publication, please speak out with

I've read the 03 version of the draft.  I think it's basically ready
for publication.  However, I have two new points to discuss, which may
result in some non-trivial updates (although they may not be
substantial to warrant another WGLC).

1. regarding recursive resolvers (4.2.2.1), I wonder whether we
   want to explicitly note that the recursive servers MUST NOT (I
   think) forward a DNSKEY query with an EDNS key tag option when it
   already has it in the cache simply because the set of key tags in
   the originally query is different from its own set of key tags.

2. regarding the following note in Section 5.3:

   [ Note RFC1035 says NULL
   RRs are not allowed in master files, but I believe that to be
   incorrect ]

  perhaps we should officially update RFC1035 and clarify that NULL is
  now allowed in master files?  Even if the usage in the authoritative
  side (such as the example shown in Section 5.3.1) is not a normative
  part of this draft, the use of NULL RR is, and so it would be better
  to assure such configuration won't be considered a non-compliant
  setting.

--
JINMEI, Tatuya

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 7 Oct 2016 17:19:54 -0400

>   to assure such configuration won't be considered a non-compliant

§5.3.1 uses the RFC 3597 generic text representation, and 3597 says "An
implementation MAY also choose to represent some RRs of known type using
the above generic representations for the type". So maybe all that is
needed is a reference to 3597.

(Are there any other reasons for 1035 to not allow NULL RRs in zone
files besides the lack of a defined presentation format?)

-- 
Robert Edmonds