Subject: Re: nsid last call

From: <[email-masked]>
Date: Mon, 19 Jun 2006 07:39:47 +0100

Dean Anderson <[email-masked]> wrote on 2006-06-19 04:25:38:

> On Fri, 16 Jun 2006, Matt Larson wrote:
> 
> > This whole thread is getting a bit silly, since the contents of the
> > NSID payload is unenforceable, anyway.
> 
> Well, of course that's true most of the time. But its not always 
> true, e.g. root
> server operators who have legal agreements that compel them to comply 
with the
> standards.  That's why I think this sort of business should be left out 
of the
> standard.  Those people who want to do things with spoofing and hiding,
> obviously still can. 
>
> But I don't want to see the root operators doing this sort thing.

That may be, but that's an issue which is completely outside
the scope of the protocol.  Specifying this in (or omitting it
from) the protocol will not govern or control how it is used in
the wild, by the root server operators or anyone else.

> > I agree. Does it need to be prohibited in the standard though?
> 
> As opposed to just omitted?  Hmm. I think that it should at least be 
omitted,
> and strictly standard behavior should be that anycast instances are 
identified
> universally.  But I could be happy with merely omitting it.  However, in 
that
> case, we also need to remove the following text in 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.

I think it's preferable to keep this in as an illustration of the
degree to which the protocol is agnostic to payload content.

[Nit: this should be "dynamically", not "dynamicly".]

Geoff

--
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: Alex Bligh <[email-masked]>
Date: Mon, 19 Jun 2006 10:17:34 +0100

--On 18 June 2006 23:25 -0400 Dean Anderson <[email-masked]> wrote:

> omitted, and strictly standard behavior should be that anycast instances
> are identified universally.  But I could be happy with merely omitting
> it.  However, in that case, we also need to remove the following text in
> section 3.1:
>

The disadvantage of it being omitted completely is there is nothing to warn
the potential NSID client user that they might be dynamically generated.
This might confuse people - the latter is really just an illustration of
what might happen in a payload reply such as "none of your business". I
could also live with it being omitted though I would prefer some
caveat for the receiver of packets. I agree we should not be seeking to
imply that there is some sort of endorsement or recommendation for
opaque NSID in the absence of current operational REQUIREMENT to
mandate it.

Alex