Subject: Re: [Asrg] 4d. Consent Framework - Protocols and Formats

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 20 Aug 2003 00:45:38 -0400

At 10:18 AM 8/15/2003, Andrew Akehurst wrote:
>..........
> > The question is whether SCOPE and SCOPE RULES are independent, or are
> > they just specific examples of CONSENT RULES and POLICIES.
>
>It's tempting to think that "scope" is merely an attribute of a rule,
>rather than an entity in its own right.
>
>If scope were a simple value then I don't see what attributes
>it could have, other than being "local", "shareable" or whatever
>value the scope has. (I invented these labels at random, I'm not
>claiming they're good suggestions, just examples that came to mind
>at the time)
>
>It's a common design principle that anything which has only one
>attribute (i.e. its value) is not considered to be a separate entity
>but is instead a flat "primitive" attribute of something else.
>I'd suggest that (for the sake of simplicity) unless anyone can
>demonstrate that a scope has additional attributes of its own, then
>why not make scope part of a rule or policy definition?
>
>A nice example of this use of scope was Jon Kyme's example of a
>consent schema:
>
> 
>https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01022.html
>
>His suggestion was for scope to be "local", "organisational" or
>"global", with regards to how widely it is shared. Is this a
>reasonable starting point?

I think we need to work this out better - this is something that needs to 
be cleared up in the consent framework. Scope may have much more 
complicated rules than simply "local" or "global" like suggested by John - 
for example a user might share his policy with his ISP but share only part 
of it with a spammer (the C/R part). Thus, scope rules would also apply to 
specific parts of a policy which is where a mechanism like XLinks would 
come into play which allows a standard mechanism to refer to a part of the 
policy.

>The discussion that followed with Keith Moore was interesting and
>dealt with some of the issues to do with how to establish that a
>policy is genuine and with priority conflicts between multiple rules.
>It's worth a second look.

Definitely.  

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 20 Aug 2003 14:24:42 +0100

> of it with a spammer (the C/R part). Thus, scope rules would also apply

I'm not sure that scopes more "complicated" / fine-grained than
 local | organisational | global
would in fact be useful, but whether scope might be better represented as
an attribute of a "rule" or of the "policy" - this is a good question. I'd
go for per-rule, as I guess that it would make the policy more compact
(given that these scopes "nest" nicely) as you'd avoid duplicating rules
differing only in scope in the differently scoped policies.

--

---

From: "Pete (Madscientist)" <[email-masked]>
Date: Thu, 21 Aug 2003 13:11:42 -0400

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Jon Kyme
<snip>
|I'm not sure that scopes more "complicated" / fine-grained 
|than  local | organisational | global would in fact be useful, 
|but whether scope might be better represented as an attribute 
|of a "rule" or of the "policy" - this is a good question. I'd 
|go for per-rule, as I guess that it would make the policy more 
|compact (given that these scopes "nest" nicely) as you'd avoid 
|duplicating rules differing only in scope in the differently 
|scoped policies.

Currently the way the XML-CPDL example works is to define scope in terms
of a SYSTEM. A SYSTEM might be a user, organization, etc... defined by
the implementor by subscription. For example, a small ISP might have a
SYSTEM that corresponds with their global policy and is implemented at
their gateway MTAs; they might then have another SYSTEM implemented for
each of their store & forward customers running on the server(s) that
make that transfer; they might have another SYSTEM defined and running
for each of their hosted domains that subscribe to a custom-domain
policy service; and below those they might have a SYSTEM defined for
each user within one of these domains.

In this example we would presume that user level SYSTEMs would be
aggregated by domain level SYSTEMSs, that domain level SYSTEMS and S&F
SYSTEMS would be agregated into the global policy SYSTEM. The
relationships between these SYSTEMS (scope definitions) would be defined
by the IMPORT and EXPORT rules defined in each SYSTEM.

This structure allows the implementor to determin the granularity of
scope to fit their needs.

I will endeavor to create a document that clarifies this... in the
interim, does this description make sense?

_M