Handling of Unknown DNS Resource Record (RR) Types
draft-ietf-dnsext-unknown-rrs-06
Discuss
Yes
No Objection
(Alex Zinin)
(Bill Fenner)
(Cullen Jennings)
(Dan Romascanu)
(David Kessens)
(Jon Peterson)
(Magnus Westerlund)
(Mark Townsley)
(Russ Housley)
(Sam Hartman)
No Record
Andy Newton
Deb Cooley
Erik Kline
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Ketan Talaulikar
Mahesh Jethanandani
Mike Bishop
Mohamed Boucadair
Orie Steele
Paul Wouters
Roman Danyliw
Éric Vyncke
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Andy Newton
No Record
Deb Cooley
No Record
Erik Kline
No Record
Gorry Fairhurst
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
Ketan Talaulikar
No Record
Mahesh Jethanandani
No Record
Mike Bishop
No Record
Mohamed Boucadair
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Éric Vyncke
No Record
Margaret Cullen Former IESG member
(was Yes, Discuss, Yes)
Discuss
Discuss
[Treat as non-blocking comment]
(2005-08-18)
Unknown
Need to clear up the downrefs to RFCs 2535 and 2163 before this can go to DS.
Scott Hollenbeck Former IESG member
(was No Objection, No Record, Discuss)
Discuss
Discuss
[Treat as non-blocking comment]
(2005-08-16)
Unknown
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 IESG member
Yes
Yes
(2005-08-18)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
(2005-08-18)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2005-08-15)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2005-08-16)
Unknown
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.