RE: [Speermint] Re: comments on terminology document

Hi Otmar.

Nice hearing from you.

I guess what concerns me about the definition in your draft is the word "agree". Various DA's can coexist in a federation without agreeing on anything. They merely need to support a common set of rules so that they can understand each others requirements. Agreement sound awfully close to bilateral relationships and as I stated before that is just on use case for a federation. Entities may federate and yet not agree to accept direct traffic from each other for business, security, trust, protocol, codec or just about any other reason. 

While there may definitely be more than one definition for a federation, we should strive for a more general (supporting more use cases) definition at the expense of the more restrictive one.

Cheers,

David Schwartz
________________________________

מאת: Otmar Lendl [mailto:lendl@nic.at]
נשלח: ד 15/03/2006 16:23
אל: David Schwartz
עותק לידיעה: David Meyer; Rohan Mahy; speermint@ietf.org
נושא: Re: [Speermint] Re: comments on terminology document

On 2006/03/12 11:03, David Schwartz <David.Schwartz@Kayote.com> wrote:
>
> Following up on Rohan's comment regarding carrier clubs or federations
> I think that this document should actually have a definition of these
> as well.
>
> The reason it is so important to have this definition appear in this
> document is because I have seen many definitions cropping up that IMHO
> confuse the matter and since this document is sort of a baseline it is
> probably better that it is dealt with here.

The concept of federations will be important. They are popping up
in various concepts (e.g. IM federations), and I doubt that one
definition will be suitable for all applications.

>
> Compare for example the definitions given for a federation
> in "draft-ietf-sipping-trait-authz-02" (TRAIT) and
> "draft-lendl-speermint-federations-00" (FEDS).
>
> TRAIT defines a federation as "...a set of administrative domains
> that implement common policies regarding the use and applicability of
> traits for authorization decisions".
>
> FEDS on the other hand defines this same entity as "...a group of VoIP service providers which
>       *  agree to receive calls from each other via SIP,
>       *  agree on a set of administrative rules for such calls
>          (settlement, abuse-handling, ...), and
>       *  agree on specific rules for the technical details of the
>          Interconnection".
>
> As can be seen, FEDS has a much narrower definition and since as Rohan
> has pointed out we are "not precluding" connections via some sort
> of intervening network it is possible to have federations where the
> peers do not "agree" on policy with anyone other than the intervening
> network. TRAIT is general enough to allow for this model while FEDS is
> not.

My wording in FEDS may be ambiguous, but as one example shows I tried
to include the options of having a layer 5 node in the middle in
the definition of a federation:

   o  Peering fabric based on SIP: A company sets up a SIP proxy which
      acts as a forwarding proxy between the SIP proxies of all
      participating VSPs.  The group of these VSP form a federation
      whose technical rules state that calls have to be routed via that
      central proxy.

In the context of draft-lendl-speermint-federations-00, the only important
aspect of a federation is the notion that if VSP A is a member of
the federations X and Y and VSP B is a member of Y and Z then A can use
the federation-framework of Y to complete a call to B.

At this level, the details of Y's inner working (direct SIP? proxied SIP?
Public Internet? Private L3? QoS? TLS? Codecs? srtp?) is irrelevant.

The TRAIT concept fits in nicely into draft-lendl-domain-policy-ddds-00.
I see two ways of incorporating TRAITs there:

a) if e.g. 10 universities trust each other's traits, then they can
   form a FEDS federation where the technical rules state that inter-university
   calls need to carry the trait "valid-user" (signed by one of the universities).

b) assuming traits will be standardized as RFC9999, and the appropriate
   policy-types are introduced:

   $ORIGIN example.edu.
      ;      order pref flags service regexp replacement
       IN NAPTR 10 10   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:9999!" .
       IN NAPTR 10 11   "U" "D2P+SIP:ca-list" "!^.*$!CACERT,THAWTE,XXXX!" .

> Accepting the TRAIT definition and "base-lining" it is therefore more
> in line with the current revisions to your document.

I'm not sure whether that's a good idea. TRAIT addresses a different application
than FEDS. Forcing a definition to suit both may have benefits in terminology
but will dilute the applicability of the concepts regarding the respective use-cases.

/ol
--
< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >