Re: [ietf-provreg] thursday's meeting

[janusz sienkiewicz <janusz@libertyrms.info>]

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

Janusz Sienkiewicz