Subject: [Speermint] Re: comments on terminology document

From: David Meyer <[email-masked]>
Date: Fri, 10 Mar 2006 11:13:51 -0800

Rohan,

	Thanks for the comments. I'll work it all into the next
	rev.

	Dave

On Thu, Mar 09, 2006 at 08:50:42AM -0800, Rohan Mahy wrote:
> Hi,
> 
> I just read the -01 terminology document.  I think we are making good 
> progress here. I have 3 content comments and a bunch of NITS.
> 
> 1) I found the NAPTR discussion in Section 2 confusing.  There will 
> often be two NAPTR lookups, one for ENUM and another for selecting the 
> SIP transport.  From the diagram I can tell that the text is referring 
> to the ENUM lookup only.  I'd also refer to RFC3263 instead of 
> describing the additional SIP DNS lookup steps. Proposed rewording:
> 
> In the case shown here, an E.164 number is used as a key by ENUM to 
> retrieve a NAPTR record [RFC3404] from the DNS, which in turn resolved 
> into a SIP URI.  Call routing is based on the resulting SIP URI. The 
> call routing step does not depend on the presence of an E.164 number; 
> indeed, the resulting SIP URI may no longer even contain any numbers, 
> and the SIP URI can be advertised in various other ways, such as on a 
> web page.  Finally, note that the subsequent lookup steps described in 
> RFC 3263 [RFC3263] to find the next-hop SIP server from this URI are 
> outside the scope of SPEERMINT.
> 
> 2) In Section 3.5 (2nd paragraph), its not obvious what an "ingress 
> point" is in this context, or how this 2nd paragraph is related to the 
> first.  I'd remove it. Alternatively it could be reworded:
> 
>  Note that as soon as a domain advertises SIP-specific DNS records 
> (SIP+ or SIPS+ NAPTR records, or _sip or _sips SRV records), anyone can 
> discover SIP servers corresponding to the domain and send calls there.
> 
> 3) It seems like a lot of folks are interested in federation and 
> carrier clubs.  I think our first responsibility is direct peering, but 
> we should be flexible enough to accommodate federation without jumping 
> through a lot of hoops. I like the new wording in 5.1 for example.  I 
> still think the definition of Layer 5 could be more accommodating.  
> I've proposed some text below:
> 
> current wording in -01
> >3.6.2.  Layer 5 Peering
> >
> >   Layer 5 peering refers to interconnection of two service providers
> >   for the purposes of SIP signaling.  Note that in the layer 5 peering
> >   case, there is no intervening network.  That is, for purposes of 
> >this
> >   discussion, there is no such thing as a "Layer 5 Transit Network".
> 
> Proposed wording:
> Layer 5 peering refers to interconnection of two service providers for 
> the purposes of exchanging SIP signaling. Note that in the layer 5 
> peering case, there is no requirement for any intervening "Layer 5 
> Transit Network".  Each service provider is expected to interconnect 
> directly with other service providers, although a service provider is 
> allowed to interconnect through another domain (ex: a federation) to 
> act on its behalf. This document neither precludes nor encourages this 
> behavior.
> 
> 
> 
> NITS:
> 
> spell out and reference first uses of SIP, ENUM, and SMTP
> spell out VoIP, URI, and DNS on first use
> s/Ip /IP /g
> capitalize "MAC" in MAC address
> reference split-DNS
> 
> Section 2 s/NAPTR recored/NAPTR record/
> 
> Section 4.3
> s/VPN's/IPsec [ref] VPNs (Virtual Private Networks)/
> 
> Section 4.4  (is this what was intended?)
> s/Finally, note that ENUM is not constrained to carry only data (CDR)/
> Finally, note that ENUM is not constrained to carry only CRD data/
> 
> s/an an/an/
> 
> Section 5.1
> s/These start by a/These start as a/
> 
> Section 5.5
> s/used route the/used to route the/
> 
> thanks,
> -rohan
> 
_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 10 Mar 2006 20:24:29 +0100

First, I like the proposed text from from Rohan regarding
 
> >3.6.2.  Layer 5 Peering

second, on the discussion on NAPTRs I would like to add
that we may also have a third, etc. NAPTR lookup, 
e.g. the proposed Policy NAPTRs, so we should always
make clear what NAPTRs we are talking about

regards
Richard

________________________________

Von: David Meyer [mailto:[email-masked]]
Gesendet: Fr 10.03.2006 20:13
An: Rohan Mahy
Cc: [email-masked]
Betreff: [Speermint] Re: comments on terminology document

        Rohan,

        Dave

---

From: "David Schwartz" <[email-masked]>
Date: Sun, 12 Mar 2006 16:43:39 +0200

Hi David.

Upon further thought I believe we need to reexamine section 3.6.2. of
draft-ietf-speermint-reqs-and-terminology-01.txt. Does the scope of the
definition of Layer 5 peering presented really cover all of our use
cases?

Consider if you will the nature of social or referral networks. Assume
that B is a friend to A and C. A would like to speak to C only C does
not know or trust A is and it is only when B "introduces" A to C that A
can speak directly to C. Note that this has nothing to do with how the
signaling/media flows between A and C. In reality, peering networks have
more in common with this example than we realize. At the end of the day,
it is the business relationships comprising trust and policy that
differentiate the Layer 5 peering problems from lower layer ones.

The direct peering model and the one using an intermediary network are
both use cases that need to be unified by a common peering model. The
challenge for SPEERMINT is to define this model such that we have the
tools to express peering for all its use cases.

David Schwartz

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Mon, 13 Mar 2006 12:53:19 -0600

Yes, it will be a good idea to move draft-ietf-sipping-trait-authz-02 to
SPEERMINT.

-----Original Message-----
From: David Meyer [mailto:[email-masked]] 
Sent: Monday, March 13, 2006 12:33 PM
To: David Schwartz
Cc: Rohan Mahy; [email-masked]
Subject: Re: [Speermint] Re: comments on terminology document

On Sun, Mar 12, 2006 at 12:48:56PM +0200, David Schwartz wrote:
> Nice draft.

	Thanks. Just surfacing after a brutal travel spin-cycle.

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

	Agreed.

> 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.
> 
> Accepting the TRAIT definition and "base-lining" it is therefore more
in line with the current revisions to your document.
> 
> (In general I feel that the TRAIT document should migrate over to the 
> SPEERMINT working group)

	On first blush, seems reasonable. What does the WG think?

	Dave

---

From: "Jeremy Barkan \(DigitalShtick\)" <[email-masked]>
Date: Thu, 16 Mar 2006 17:30:06 +0200

Hi Otmar and David,
 
This discussion regarding the definition of federation is fundamental to how
we see the role of the federation, and not just terminology.

> 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.
 
The definition of a federation in the TRAITS draft is more like a framework
that would enable federations as described in FEDS [ a federation for peer
terminations ] to be a use case that would be expressible in the framework.
A key point in TRAITS is that federations are first and foremost a common
policy schema framework.

>From the TRAITS draft:
 
“Domains that federate with one another agree on the syntax and semantics of
traits - without this consensus, trait-based authorization schemes would
only be useful in an intradomain context.”
 
“A federation is defined as a set of administrative domains that implement
common policies regarding the use and applicability of traits for
authorization decisions.”
 
The use case in the TRAITS draft of “Settlement for Services” is an
interesting example. If we extend TRAITS beyond authorization, wouldn’t the
peered termination examples in FEDS be better expressed in a TRAITS-like
framework? TRAITS enables assertion of attributes and their policy
requirements [the scope of those in the draft are authorization]. FEDS, on
the other hand, is limited to DNS expression for policy requirements.
 
TRAITS also does not commit to a binding such as DNS, as in FEDS. TRAITS
provides a framework that should be implemented at several levels. In the
FEDS example of call termination, the authorization/agreement flow could
conceivably require elements at a higher protocol level than DNS. 
 
Regards,
 
Jeremy Barkan
jeremyb at digitalshtick dot com
DigitalShtick
w/h +972 2 6728069
m +972 54 6321603
Shalom Yehdua 6/2
Jerusalem 93395 Israel