Subject: Request to publish draft-ietf-dnsext-nsid

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 24 Jan 2006 19:05:19 +0100

Esteemed ADs,

We would like to request publication of draft-ietf-dnsext-nsid-01 on
the standards track.

Hereby the proto questionnaire.  I will be the proto contact.

Yours,

--Olaf Kolkman

Questions:

1) Have the chairs personally reviewed this version of the ID and do
     they believe this ID is sufficiently baked to forward to the IESG
     for publication?

    Yes.

2) Has the document had adequate review from both key WG members and
     key non-WG members? Do you have any concerns about the depth or
     breadth of the reviews that have been performed?

    Yes, at least 5 people in the working group state they have
    reviewed this work thoroughly. We have no concern about the depth
    of review.

3) Do you have concerns that the document needs more review from a
     particular (broader) perspective (e.g., security, operational
     complexity, someone familiar with AAA, etc.)?

    No. This is a relatively trivial protocol extension.

4) Do you have any specific concerns/issues with this document that
     you believe the ADs and/or IESG should be aware of? For example,
     perhaps you are uncomfortable with certain parts of the document,
     or whether there really is a need for it, etc., but at the same
     time these issues have been discussed in the WG and the WG has
     indicated it wishes to advance the document anyway.

   The document specifically addresses server to client
   identification. Client to server identification is out of scope. If
   such is ever needed the WG will write new specification.

5) How solid is the WG consensus behind this document?  Does it
     represent the strong concurrence of a few individuals, with others
     being silent, or does the WG as a whole understand and agree with
     it?

   Solid. Note that the need for this technique came from the DNS
   operations community. Also see draft-ietf-dnsop-serverid (The nsid
   document does not contain references to dnsop-serverid as it stands
   on itself).

6) Has anyone threatened an appeal or otherwise indicated extreme
     discontent?  If so, please summarize what are they upset about.

   No.

7) Have the chairs verified that the document adheres to _all_ of the
     ID nits?  (see http://www.ietf.org/ID-nits.html).

   Yes

8) For Standards Track and BCP documents, the IESG approval
     announcement includes a writeup section with the following
     sections.

    In order to be able to identify certain nameservers in a DNS
    anycast cloud clients querying nameservers in that cloud can add an
    EDNS OPT pseudo RR that signals the answering nameservers to
    include identifying information in an OPT RR that is attached to
    the answer.

    This technique improves the existing ad-hoc methods to identify
    nameservers.

    Working group consensus is solid. During the working group
    discussions the question came up to also allow for client to server
    identification. This was argued to be out of scope since.

    This feature will be implemented in at least two independent
    open-source products used on anycasted root-servers. And will be
    available in at least one resolver implementation and become
    available in two libraries.

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/