Handling of Unknown DNS Resource Record (RR) Types
RFC 3597
Discuss
Yes
No Objection
No Record
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Alvaro Retana No Record
Andrew Alston No Record
Erik Kline No Record
Francesca Palombini No Record
John Scudder No Record
Lars Eggert No Record
Martin Duke No Record
Murray Kucherawy No Record
Paul Wouters No Record
Robert Wilton No Record
Roman Danyliw No Record
Warren Kumari No Record
Zaheduzzaman Sarker No Record
Éric Vyncke No Record
(Margaret Cullen; former steering group member) (was Yes, Discuss, Yes) Discuss
Need to clear up the downrefs to RFCs 2535 and 2163 before this can go to DS.
(Scott Hollenbeck; former steering group member) (was No Objection, No Record, Discuss) Discuss
Can this document go to draft if one of the normative references has been obsoleted (2535) and another (2163) is still a proposed standard? I imagine that the reference to 2535 can be updated with a note to the RFC Editor, but what about 2163?
(Allison Mankin; former steering group member) Yes
I suggest that RFCs 2535 and 2163 be Last Called for Historic, and in those LCs undergo the RFC 3969 downref procedure for this DS.
(Alex Zinin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
Nits: The example in section 5 does not adhere to the use of IP(v4) addresses in an example as per RFC3330. Probably not worth spinning another RFC. But maybe list it as erratum, so that it does get picked up if there is ever going to be a new rev?
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
After some thought I decided to ballot no-objection on this, but I do agree with the attached gen-art comment from Scott Brim. The reason I decided to let the document move forward is that I think we haven't published clear guidance on what should be in an implementation report, so it would be unreasonable to penalize this one. ---- Scott Brim said: Summary: RFC 3597 is obviously a good thing and is ready to go, but the interoperability report @ http://www.ietf.org/internet-drafts/draft-ietf-dnsext-interop3597-02.txt still has the problems that Thomas Narten pointed out last Fall. Last September Thomas Narten said https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=25265 -- an interoperability report should be specific about which capabilities were tested (by RFC section number), which implementation was tested for each capability, etc. The report sets up the test scenarios but that's it. The difference between -01 and -02 consists of a single paragraph, which just mentions all of the sections tested together. It doesn't map tests to sections, or which implementations were tested for what. Ordinarily I wouldn't mind because I know it works and it's a simple standard -- rigor in interoperability tests is much more critical for complex state machines -- but because it's simple it should be easy to fill out a report, and being casual about the procedures even for simple standards feels like a slippery slope.
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
Just as a follow-up to Scott's comment; the document says: The specifications of a few existing RR types have explicitly allowed compression contrary to this specification: [RFC2163] specified that compression applies to the PX RR, and [RFC2535] allowed compression in SIG RRs and NXT RRs records. Since this specification disallows compression in these cases, it is an update to [RFC2163] (section 4) and [RFC2535] (sections 4.1.7 and 5.2). I think 2163 is in the normative section because this document updates it. I think it would be logical to consider it "informative except for the update pointer" and to treat that as advanced with this document. It's a bit of corkscrew logic, but I think it works.