[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

To: Rick Wesson <wessorh@ar.com>
cc: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, "Hollenbeck, Scott" <shollenbeck@verisign.com>, "'Edward Lewis'" <edlewis@arin.net>, ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Mon, 17 Mar 2003 13:22:40 -0500
In-Reply-To: Your message of "Mon, 17 Mar 2003 09:21:56 PST." <Pine.LNX.4.33.0303170919590.811-100000@flash.ar.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] thursday's meeting

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

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.


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.

Home | Date list | Subject list