Subject: RE: [ietf-provreg] thursday's meeting

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 17 Mar 2003 08:39:46 -0500

> As one might imagine, the agenda is going to be a bit flexible.
> 
> Besides the published agenda, I'd like folks to be prepared to also 
> discuss these items:
> 
>     Our response to the IESG.  The IESG wants "a standard (as 
> in the base,
>     core spec) means for a registrar to tell a registry what 
> can be disclosed
>     at fine granularity."
> 
>     A means to avoid host objects.

We have really got to get a grip on the first item.  I thought we were past
this as of last week, and here we are again.  There's clearly a
communications issue somewhere...

I would hope that whomever wishes to bring up the "avoid host objects" topic
plans to introduce information that hasn't already been talked to death on
the mailing list at multiple times in the past.

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 17 Mar 2003 11:16:31 -0500

> communications issue somewhere...

I agree.

Either a
	session-scope mechanism, which incidently is independent of 
	syntax and schema (it could be morphed into EBNF if RRP has
	not yet reached its sell-by date),
or a
	base schema mechanism, dependent upon syntax and schema, and
	independent of "session" (aka, "privacy" is a property of
	syntax representations, and transport independent, even if it
	is not transported),
or a
	mechanism which subsets the base schema, and constructs some
	syntax and semantics from some subset, and is also independent
	of "session" (see above, and add complexity for subseting in
	general).

That should read as a switch statement, with no fall-through.

Pointing out a specific defect in the <dcp> element's sub-schema would be
really useful.

Eric

---

From: Rick Wesson <[email-masked]>
Date: Mon, 17 Mar 2003 08:23:22 -0800 (PST)

> > >     core spec) means for a registrar to tell a registry what
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >     at fine granularity."

[snip]

> Pointing out a specific defect in the <dcp> element's sub-schema would be

The DCP proposal didn't address how a registrar can tell the registry
what can be disclosed. I believe it was the <dnd> proposal that did
allow this fine granularity of disclosure.

-rick

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 17 Mar 2003 11:34:20 -0500

> allow this fine granularity of disclosure.

We don't have a negociation mechanism, for anything.

I don't mind adding one.

Why is the scope of negociation limited to this however?

Eric

---

From: Rick Wesson <[email-masked]>
Date: Mon, 17 Mar 2003 09:21:56 -0800 (PST)

> Why is the scope of negociation limited to this however?

I suspect because the granularity requetsted is for the registrant not the
session, where by one session could do many registrations for many more
contacts/registrants.

-rick

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 17 Mar 2003 13:22:40 -0500

> session, where by one session could do many registrations for many more

So, in this model, there is p1, p2, p3; three distinct mumbles that have a
to be defined, but not session-scoped, definition.

A session between e1 and e2, two EPP endpoints, which transports d1, d2, d3,
three distinct EPP datums, is:

	e1: session-open; send d1:p1; send d2:p2; send d3:p3; session-close
	e2: ack, ack, ack, ack (sort of like the Martians in "Mars Attacks")

If so, then while data exhibits a property close to global uniqness within
each glob of data, the value for the set {p1, p2, p3, ...} may have a much
smaller cardinality. Somewhere less than 42 seems likely.

If so, then connections should resemble something like this:

	send d1:p1, send d2:p1, send d3:p1 .... send dN:p1 \
	send dN+1:p2 send dN+2:p1, send dN+3:p1 .... send dN+M:p1  

for non-trivial sequences of sequentially identical values of p.

Rewritten, to show policy-scoped sequences of data:

	p1{d1, d2, ... dN}, p2{dN+1}, p1{dN+2, dN+3, ... dN+M}

And that looks reasonably amenable to this

	s1{p1{d1, d2, ... dN}}, s2{p2{dN+1}}, s3{p1{dN+2, dN+3, ... dN+M}}

or three sessions, each with an associated single policy on all data.

Operationally, we haven't precluded server operators from assigning well
known values of p to ports, so that in practice, the above would be three
distinct connections.

We also haven't precluded server operators from cycling through a set of
well known values of p whenever the server observes a session-end sent
by a client, followed by a session-begin.

We could of course add some mechanism for client and server to "dual" with
<dcp> values, until "trained", but until someone starts putting values for
p down, we don't actually know if the size of the p value-space is as big
as 42, or as small as two, or three, or four meaningfully distinct values.

Eric

P.S. I'm having way too much fun with the symbolic general nonsense. The
proponant(s) of mumble need to attempt to be concret, soon.

---

From: janusz sienkiewicz <[email-masked]>
Date: Mon, 17 Mar 2003 14:07:41 -0500

>         send dN+1:p2 send dN+2:p1, send dN+3:p1 .... send dN+M:p1

Shouldn't  "send dN+2:p1, send dN+3:p1 .... send dN+M:p1" have p3 instead of
p1?

> proponant(s) of mumble need to attempt to be concret, soon.

Janusz Sienkiewicz

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 17 Mar 2003 14:16:13 -0500

> Shouldn't  "send dN+2:p1, send dN+3:p1 .... send dN+M:p1" have p3 instead of

I should have been explicit.

I'm drawing on some non-provreg data -- real life with cookies.

Few distinct "privacy" "policies" or "preferences" exist.

The distribution of policied cookies and browser values that result in
these three general categories:
	accept-unconditionally
	warn-accept-or-reject-conditionally
	reject-unconditionally
is small, and the modality is less than the total range of values.

The most likely transition will be from one domainant mode to another.

So, p1 to p2 and back to p1, generally, and p1 to p3 and back to p1.
Less frequently will be pN to pM, where N and M are not in the very
small set of dominant modalities of meaningfully distinct policies.

I wasn't trying to show p1, then p2, then p3 usage, but
	
 ...p1p1p1p1p1<break>p2p2<break>p1p1p1p1p1p1pp1<break>p3<break>p1p1...

Where there really is random variation from one data glob to the next, and
the variations are meaningfully distinct (a kettle of fish that is not yet
opened), then clearly the "statefull encoding" of policied sequences of
data globs is not going to work as well as some "statefull encoding" of
policied, and uncorrolated data globs. 

In a sense, we're just revisiting statefull vs stateless encoding design
issues. How much character-set variation do you think there is in some
character stream? Design accordingly. If few transitions relative to the
byte count, go for what amounts to state shifts (and variable byte counts
per character). If many relative to the byte count, consider using fixed
rather than variable byte counts, and accept the "padding" overhead.

How many interesting ways are there to write: don't publish some or all of
my mumble?

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 17 Mar 2003 14:19:41 -0500

> policied, and uncorrolated data globs. 

Oops. That should read

> data globs is not going to work as well as some "stateless encoding" of
                                                        ^^^^
Eric