Subject: Re: nsid last call

From: Olaf M.Kolkman <[email-masked]>
Date: Tue, 13 Jun 2006 15:18:10 +0200

Colleagues,

This is to close the remaining issues.

On the second issue we did not see consensus to change the text and  
it will remain as is

> In section 2.3:
>
> OLD:
> The OPTION-DATA for the NSID option is an opaque byte string the  
> semantics of which are deliberately left outside the protocol.

As for the discussion of the first issue. The group consents with the  
general idea that the NSID option remains "unique" but also asked for  
a definition of unique. I think Dean Anderson's proposed text is  
catching the spirit of the discussion. And if there are is no push- 
back before the end of the week I would like to ask the editors to  
update 3.1 with the following.

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.

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

---

From: Peter Koch <[email-masked]>
Date: Tue, 13 Jun 2006 16:20:34 +0200

>      over a series of queries. The NSID can be opaque and encoded  

sorry to disagree, but in the Paris meeting and subsequently in
<http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01347.html>
I explicitly asked to have this as dynamic as possible and neither were
there any objections nor can I see much discussion, lest support for this
180 degree change. Please remove "as long as the content ... over a series
of queries".

>      This section describe some of the kinds of data that server  

[...]

The rest of the more verbose explanation is fine, though.

-Peter

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 14 Jun 2006 14:37:14 +0200

> 180 degree change. Please remove "as long as the content ... over a  

Fair point Peter, I'm always happy to see you disagree and in this  
case you made me painfully and rightfully aware that this issue was  
in fact already explicitly brought up before last call and I had just  
forgot about it.

Anyway, this causes a bit of dilemma since during this post last-call  
debate Dean made an argument in favor of being able to identify the  
any cast nodes as a client while you made the argument to hide  
instances behind an anycast based load sharing system.  These are  
clearly conflicting.

Now for a fair way to get closure on this issue;

I think that a one person call in favor for identifying the any cast  
instances over a series of queries is not sufficient to overhaul an  
issue that was brought up pre-last call. On the other hand I'd like  
to give others the possibility support one of the two views. So, I  
will not close the issue yet. We leave it open for another few days  
and unless there is no clear consensus building for _not_ removing  
"as long as the content ... over a series of queries" I propose to  
converge to:

3.1.  The NSID Payload

      content. The NSID can be opaque and encoded such that it

(Silence or increased entropy do not constitute "clear consensus  
building for _not_ ... &c &c".)

phewww,

--Olaf

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Jun 2006 10:16:51 -0400

>Now for a fair way to get closure on this issue;

Can you provide a link to the document?  (The thread began as an 
"Re:" as far as I can tell.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 14 Jun 2006 17:59:50 +0200

> "Re:" as far as I can tell.)

Apologies,

I messed up the subject header.

The first mail in this thread (http://ops.ietf.org/lists/namedroppers/ 
namedroppers.2006/msg00735.html) should have been a continuation of  
the thread starting at:
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00684.html

Hope this clarifies.

--Olaf

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Jun 2006 12:23:09 -0400

At 17:59 +0200 6/14/06, Olaf M. Kolkman wrote:

>http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00684.html

I don't see the purpose of this change:

# In section 2.3:
#
# OLD:
# The OPTION-DATA for the NSID option is an opaque byte string the semantics of
# which are deliberately left outside the protocol.
# NEW:
# The OPTION-DATA for the NSID option is an opaque byte string the semantics of
# which are deliberately left outside the protocol. Implementations MUST
# implement manual configuration of the NSID string.

(Altering NSDID to NSID in the last line.)

This does not impact interoperability (it's not in the protocol).

Not all server implementations will need to do this, e.g., turnkey 
DNS code paths, code that is not distributed, etc.  It some 
situations, hardcoding one value for this field may work quite well.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

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

> 180 degree change. Please remove "as long as the content ... over a series

This change is what has been discussed recently. I don't see that as a very
great change, even though it may not be exactly what you wanted in Paris. I 
wasn't at Paris, so I don't know what was agreed there, but presumably review by 
a wider audience has its benefits....

Can you explain why this should be allowed to be changed on a per-packet basis?

It is actaully very dynamic as I worded it.

I can't see any good reason for there to be a secret as to how many anycast
instances there are, nor can I see any good reason that remote users shouldn't
be able to match the NSID to the server instance over a series of queries.

I think I would object to the 'each query unique secret' version, with some good
reasons for that.

		--Dean

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

---

From: Matt Larson <[email-masked]>
Date: Fri, 16 Jun 2006 17:12:38 -0400

> building for _not_ ... &c &c".)

I can live with this text, although I prefer the original text.

This whole thread is getting a bit silly, since the contents of the
NSID payload is unenforceable, anyway.

How about directing all this energy to reading the various trust
anchor management proposals?

Matt

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 19 Jun 2006 11:55:36 +0200

On Jun 14, 2006, at 2:37 PM, Olaf M. Kolkman wrote:
>
> I think that a one person call in favor for identifying the any  
> cast instances over a series of queries is not sufficient to  
> overhaul an issue that was brought up pre-last call. On the other  
> hand I'd like to give others the possibility support one of the two  
> views. So, I will not close the issue yet. We leave it open for  
> another few days and unless there is no clear consensus building  
> for _not_ removing "as long as the content ... over a series of  
> queries" I propose to converge to:
>
>
>
> 3.1.  The NSID Payload
>

Kind Colleagues,

I have seen the discussion develop over the last couple of days and I  
think it has converged to a point where arguments are being  
reiterated. I have not seen a clear consensus building for '_not_  
removing "as long as the content ... over a series of queries"'.  
Hence I would like to request the editors to include the above  
version of 3.1 in the draft (modulo the possible "Strunk and White"  
and "Merriam-Webster" kind of corrections that are needed to turn the  
text into plain english).

--Olaf