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

To: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
CC: Rick Wesson <wessorh@ar.com>, "Hollenbeck, Scott" <shollenbeck@verisign.com>, "'Edward Lewis'" <edlewis@arin.net>, ietf-provreg@cafax.se, jaap@sidn.nl
From: janusz sienkiewicz <janusz@libertyrms.info>
Date: Mon, 17 Mar 2003 14:07:41 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] thursday's meeting

Eric Brunner-Williams in Portland Maine wrote:

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

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

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

Janusz Sienkiewicz

Home | Date list | Subject list