Subject: Re: nsid last call (fwd)

From: Dean Anderson <[email-masked]>
Date: Wed, 28 Jun 2006 17:54:26 -0400 (EDT)

Can we have a post WGLC draft with the following changes:

Use this wording:

 3.1.  The NSID Payload

     The syntax and semantics of the content of the NSID option is
     deliberately left outside the scope of this specification. It is
     the prerogative of the server administrator to choose the NSID
     content as long as the content is unique to each anycast instance
     so that a remote user is able to match the NSID to the server 
     instance over a series of queries. The NSID can be opaque and
     encoded such that it can be decoded by the server adminstrator to
     provide more information. This section describe some of the kinds
     of data that server administrators might choose to provide as the
     content of the NSID option, and explains the reasoning behind
     choosing a simple opaque byte string.

Delete this from Section 3.1:

   o  It could be some sort of dynamicly generated identifier so that
      only the name server operator could tell whether or not any two
      queries had been answered by the same server.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

---------- Forwarded message ----------
Date: Wed, 28 Jun 2006 14:38:50 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: nsid last call

On Tue, Jun 27, 2006 at 06:50:49PM -0400, Dean Anderson wrote:
> Strongly for spoofing:
[. . .]
> Andrew Sullivan

To be clear, I am not "for spoofing".  I think I've said enough on
the topic, however, so I won't re-hash my arguments here.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Jun 2006 23:11:37 -0400

>      choosing a simple opaque byte string.

1) How does a requirement for uniqueness improve interoperability?

2) How do you enforce this, i.e., how can you detect the difference 
between one instance relying with 2 different strings and two 
instances replying with one string each?

The requirement for uniqueness is not related to interoperability and 
is not testable.  For those reasons, I think it would be dropped.

>       queries had been answered by the same server.

IMHO, I don't care about dropping this because I don't think the 
draft really ought to even bother suggesting particular semantics of 
the opaque string.  I say that from seeing past RFCs that got in hot 
water for being "too helpful."

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

That tournament in Germany.  What's all the fuss?  (Get it? "fuss?")

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 29 Jun 2006 09:49:02 +0200

> Can we have a post WGLC draft with the following changes:

Hello Dean,

I'm sorry to say, we can not have a post WGLC.

Since I determined consensus the work has moved out of the working  
group and is now in the hands of the IESG. I consider this issue closed.

Kind regards,

--Olaf

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

---

From: Mark Townsley <[email-masked]>
Date: Thu, 29 Jun 2006 13:18:08 -0400

> group and is now in the hands of the IESG. I consider this issue closed.
Amy has already initiated the IETF LC at our request. Dean, can your 
comments be addressed as IETF LC comments?

Thanks,

- Mark

---

From: Dean Anderson <[email-masked]>
Date: Thu, 29 Jun 2006 14:10:42 -0400 (EDT)

> 1) How does a requirement for uniqueness improve interoperability?

Interoperability doesn't seem relevant, unless clients cannot
interoperate with servers, which isn't the issue here. NSID is for
debugging, primarily human use.

> instances replying with one string each?

You often can't enforce anything. But you can say what should and
shouldn't be done by inclusion in the standard.  In the cases of Roots
and others, they are compelled to comply with the standards, and when
non-compliance is discovered there is a basis for a complaint. The
difficulty in detection of violation does mean that the issue should be
ignored. We may still figure it out (eg we detected 30,000 anycast
instances of F root by NSID logging), or someone who knows, blabs.  Or a
direct question is asked of the operator and an honest answer
(indicating non-compliance) is returned.

Those who want to spoof, will do so anyway.  Just like TCP signature
spoofer's.  There is no need to include this in the standard.

> is not testable.  For those reasons, I think it would be dropped.

Many things are not testable. If we dropped all of them, there would be 
little left of the ~4K published RFC's.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 29 Jun 2006 14:15:39 -0400 (EDT)

Then I strongly object to his document, as it is now.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 29 Jun 2006 14:59:22 -0400 (EDT)

> comments be addressed as IETF LC comments?

Maybe, if the text can be altered. If the text cannot be altered
directly, I think I'd want the IESG to send it back for another
revision.  I'd object to publishing it as is.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 29 Jun 2006 15:31:02 -0400 (EDT)

Err, speaking of typos:

> difficulty in detection of violation does mean that the issue should be

That should read:

 difficulty in detection of violation does _not_ mean that the issue
should be

---

From: Mark Townsley <[email-masked]>
Date: Fri, 30 Jun 2006 10:05:59 -0400

> revision.  I'd object to publishing it as is.
There will, of course, need to be consensus to change the text. Can you 
briefly summarize the issue in your IETF LC comment? The email I saw 
cc'd to the IESG simply stated a general objection against publishing.

Thanks,

- Mark