Subject: [drinks] Policy vs. Protocol

From: Dean Willis <[email-masked]>
Date: Thu, 25 Aug 2011 13:44:33 -0500

One of the things we've done so far in DRINKS is leave a lot of 
implementation decisions to "local policy", in the hopes that it would 
reduce the detail of the specifications we're writing, while preserving 
the flexibility of the resulting implementation to do needful things 
that we haven't thought about.

I think this is a misunderstanding of "local policy". Local policy is 
not "the part of the specification we didn't write". Rather, it is the 
"locally-determined settings for configurable elements of the protocol." 
In other words, it's how the operator tweaks the knobs of the system.

The knobs, however, still have to be defined. We need to know what they 
are, how they work, and what they can be made to do. Then local policy 
can decide how they're going to be adjusted, thereby driving the 
behavior of the system.

If we don't know what the configurable aspects of a protocol are, we 
can't fully implement that protocol. At best, we can implement the 
specified subset of the protocol, and leave it to implementations to 
guess at the rest. This is not, in my opinion, a recipe for a protocol 
in which we can expect two different teams working from the same 
specification to produce implementations that will correctly work with 
each other.

Let's take an example of authentication within IMAP, the Internet Mail 
Access protocol. IMAP's specs do not say how an IMAP server is 
configured to add authorized user accounts. However, it does say where 
the username will be carried in a request and how authentication 
alternatives are negotiated and selected. And it gives us a baseline set 
of options that all implementations are expected to support. Whether the 
operator turns on those options is "local policy", but the options 
themselves, incorporated in the base protocol spec or an extension 
thereto, are "protocol".

---

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 25 Aug 2011 15:28:54 -0400

Hi Dean,

Sorry, this statement is just too vague.  Can you help me understand what you mean by "a lot"?  Even your example is not an SPP example, but rather an IMAP analogy.  And that analogy is not accurate with respect to SPPP, if I understand what you mean by "how authentication alternatives are negotiated and selected". SPPP does specify how to do authentication (Digest Authentication) and SSL certs.  Now if you do not agree with the use of the Digest Authentication then that is another matter.

If my memory serves me, the SPPP document lists the following as matters of policy:

1) Route Group Priority for Resolution:  How/if the resolution serves will use the "priority" value on the Route Group object when answering resolution queries.
2) Data Authorization Rules:  What data objects will be "gettable" and "modifiable" by a given registrar/registrant.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Thursday, August 25, 2011 2:45 PM
To: [email-masked]
Subject: [drinks] Policy vs. Protocol

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Aug 2011 14:44:37 -0500

On 8/25/11 2:28 PM, Cartwright, Ken wrote:
> Hi Dean,
>
> Sorry, this statement is just too vague.  Can you help me understand
> what you mean by "a lot"?  Even your example is not an SPP example,
> but rather an IMAP analogy.  And that analogy is not accurate with
> respect to SPPP, if I understand what you mean by "how
> authentication alternatives are negotiated and selected". SPPP does
> specify how to do authentication (Digest Authentication) and SSL
> certs.  Now if you do not agree with the use of the Digest
> Authentication then that is another matter.

Ok, you've done authentication in SPPP. What did you get out of it? How
do you use that information? based on this information, how do you
decide which records are visible?

In IMAP, the authentication produces an authenticated username, which
can be string-compared to the names of individual IMAP accounts. If the 
authenticated user name == an account user name, the access is 
authorized (possibly subject to other restraints in shared folders and 
where quotes are in use, but those are different error codes).

> If my memory serves me, the SPPP document lists the following as

...

> 2) Data Authorization Rules:  What data objects will be "gettable"
> and "modifiable" by a given registrar/registrant.

How does the user name returned by the digest authentication relate to 
the registrar or registrant name as specified in the schema especially 
given that the current schema says nothing about registrar names?

That's not a policy question. It's a protocol binding.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 25 Aug 2011 17:17:33 -0400

Answers in-line (KJC).

Ken
-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, August 25, 2011 3:45 PM
To: Cartwright, Ken
Cc: [email-masked]
Subject: Re: [drinks] Policy vs. Protocol

KJC:  It's not clear to me but you seem to be asking how to use Digest Authentication to implement authentication.  I do not think that something we should be putting in the spec.

...

KJC:  There is no such "binding" that exists because the registrant does not authenticate itself in SPPP.  There is no construct in the protocol to do such a thing because there has not been a requirement for it.  It is the registrar/SPPPClient that authenticates itself using Digest Authentication.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Aug 2011 23:38:51 -0500

On 8/25/11 4:17 PM, Cartwright, Ken wrote:

> How does the user name returned by the digest authentication relate
> to the registrar or registrant name as specified in the schema
> especially given that the current schema says nothing about registrar
> names?
>
> KJC:  There is no such "binding" that exists because the registrant
> does not authenticate itself in SPPP.  There is no construct in the
> protocol to do such a thing because there has not been a requirement
> for it.  It is the registrar/SPPPClient that authenticates itself
> using Digest Authentication.

Okay, let's rephrase the question:

How does the user name returned by the digest authentication relate to 
the registrar name as specified in the XSD schema? Is it a one-to-one 
mapping? Is it a direct mapping?Do we assume that they are textually the 
same? If so, what rules for string-comparison are used to match one 
against the other?

I know this sounds like nit-picky crap. But it's the kind of stuff that 
IETF protocols often leave out (the first time) and that developers then 
get wrong, meaning "client A will not work with server B which will not 
work with provisioning system C" because A, B, and C filled in the 
ambiguous guesswork differently. The goal in spec-writing is to 
eliminate ambiguity, otherwise we're describing an architecture, not 
defining a protocol. There's nothing wrong with describing an 
architecture, of course. But we can't say to engineer A "Build me a plug 
with three wires for 220VAC" and to engineer B "Build me a socket with 
three wires for 220VAC" and hope to get a plug and a socket that work 
together.

The history of the world's first known published engineering standard is 
worth reading:

http://en.wikipedia.org/wiki/British_Standard_Whitworth

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 26 Aug 2011 09:31:19 -0400

Dean, there is no "registrar name" defined in the XSD schema.  What are you talking about?

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, August 26, 2011 12:39 AM
To: Cartwright, Ken
Cc: [email-masked]
Subject: Re: [drinks] Policy vs. Protocol

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Aug 2011 14:30:47 -0500

> Dean, there is no "registrar name" defined in the XSD schema.  What are you talking about?

My bad. Maybe I should just say "rar" and "rant" instear of "registar" 
and "registrant". Let's try again:

How does the user name returned by the digest authentication relate to
the registrant name as specified in the XSD schema? Is it a one-to-one
mapping? Is it a direct mapping? Do we assume that they are textually the
same? If so, what rules for string-comparison are used to match one
against the other?

--
dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 26 Aug 2011 16:01:25 -0400

Given that there is also no "registrant name" in the XSD schema, I assume you mean the registrant ID, the rantID data element.  So I guess your question is, "How does a registrars' authentication credentials (part of which would be what you call a 'user name') relate to the identifier of the registrants whose data it can manage?"  The spec clearly makes no limitation that there be a one-to-one correlation between the two (the spec would be in violation of one of the use cases if it went out of its way to impose such a limitation), nor does it impose a limitation that some part of the registrar authentication credentials somehow be the same as a rantID (which would not even make sense).

As we've already discussed a couple times on the phone, the administrative steps involved in setting up registrars' authentication credentials, and the list of registrants whose data that registrar is authorized to manage is an out-of-band activity.  This activity would then, in part, result in some portion of a data store getting populated that contains that registrar's authentication credentials and the list of registrants whose data that registrar is authorized to manage.

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, August 26, 2011 3:31 PM
To: Cartwright, Ken
Cc: [email-masked]
Subject: Re: [drinks] Policy vs. Protocol

--
dean