Subject: draft-ietf-dnsext-nsid issues to be reviewed

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 23 May 2006 10:50:48 +0200

Dear colleagues,

Two issues are identified during review by the AD, Mark. I would like  
to address them here and see if there is consensus.

These are the issues:

> 1. The document is not clear in who is supposed to be decoding the  
> nsid. While it is clear that it may be populated in a number of  
> ways, it needs to be more clear that only the one populating the  
> nsid field will be the one ultimately decoding what was placed in it.

The proposal is to add text.

My (in the role of document shepherd) straw-man proposal is to add  
something along the lines of the following.

OLD:
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.  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.
NEW:

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 and the server  
administrator
    is able to match the NSID to server instances. 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.

> 2. There are a lot of methods listed for populating the nsid. I  
> [OK: this is Mark speaking] would like to at a minimum see manual  
> configuration listed as a "MUST-Implement," I would also like to  
> ask the working group if it can choose one automatic method as a  
> "MUST-Implement" so as to obtain some degree of commonality when  
> not programming these by hand. I think it is a good idea, but given  
> that this value is never to be decoded between implementation  
> beyond handling as opaque data, I will not press the issue.

Is there consensus to add such a "MUST implement a specific automated  
method"?

Silence will be interpreted as that there is such consensus and that  
the following text modifications will be made (enforcing manual  
configuration but not choosing an automated method). Silence is not a  
good way to convince the IESG though.

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 NSDID string.

Obviously alternative text is welcomed but please submit in "Old",  
"New" format.

I would like to close this issue in 2 weeks from now.

--Olaf

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 23 May 2006 07:04:36 -0400

On Tue, May 23, 2006 at 10:50:48AM +0200, Olaf M. Kolkman wrote:
> NEW

Does the requirement for uniqueness introduce new problems?  Would it
be enough to say, "as long as the content is distinctive enough that
the server administrator is able to match. . ."?

(I'm not opposed to the proposed text, but "unique" is a strong
word.)

> Is there consensus to add such a "MUST implement a specific automated  

What about SHOULD?  I'm leery of MUST, especially in conjunction with
the uniqueness constraint above.

> Implementations MUST implement manual configuration of the NSDID string.

I support this text, at least.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +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/>

---

From: Peter Koch <[email-masked]>
Date: Tue, 23 May 2006 13:26:18 +0200

>     It is
>     content as long as the content is unique and the server administrator
>     is able to match the NSID to server instances.

OK with me (although I must agree with Andrew, seeing his message coming in).
If the server administrator is able to do the match, "uniqueness" is probably
too strong.

> Is there consensus to add such a "MUST implement a specific automated  

I am not convinced that that would serve a useful purpose. The data is
entered by the server administrator, published and then transferred back
to the very server administrator. So this is interoperability with thyself?
Name server configuration is very heterogeneous anyway, so unification
for this single issue doesn't seem to lead very far.
On the other hand, explicitly favoring one nsid generation method might
discourage implementation of more sophisticated ones.
Also, the configuration issue is not touched in <draft-ietf-dnsop-serverid>.

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 May 2006 13:28:57 -0400

At 10:50 +0200 5/23/06, Olaf M. Kolkman wrote:

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

Unique with respect to what?

"This section describe" -> "This section describes"

"NSID option/content" -> "NSID Payload" in multiple places (??)

>In section 2.3:
>
>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 NSDID string.

Once again, I'm at a loss to understand "MUST implement" when there 
is no enforcement of IETF decrees.  So I can't come up with a comment.

"NSDID" -> "NSID"
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

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