Skip to main content

Handling of Unknown DNS Resource Record (RR) Types
RFC 3597

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

Alvaro Retana
Andrew Alston
Erik Kline
Francesca Palombini
John Scudder
Lars Eggert
Martin Duke
Murray Kucherawy
Paul Wouters
Robert Wilton
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

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

Discuss [Treat as non-blocking comment] (2005-08-18)
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

Discuss [Treat as non-blocking comment] (2005-08-16)
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

Yes (2005-08-18)
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

No Objection ()

                            

(Bert Wijnen; former steering group member) No Objection

No Objection (2005-08-18)
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

No Objection ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2005-08-15)
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

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection (2005-08-16)
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.