Subject: [Speermint] Revising draft-lendl-sip-peering-policy-00

From: Otmar Lendl <[email-masked]>
Date: Wed, 11 Jan 2006 17:40:32 +0100

Based on the feedback I've received from the IETF lists (Thanks!)
and local discussions, I plan restructure the SIP policy draft
quite substantially.

Before I really flesh things out I'd like to get some more feedback on
whether I'm on the right path. 

This is the plan:

* Split up the draft along similar lines as the ENUM RFC. 

  A separate document containing the problem statement and
  defining the terminology would be really helpful to offload
  a lot of content. Who is be willing to co-author this one?

* The first I-D will describe the general framework and the
  resolution algorithm. (This is the one similar to RFC 3761)

  I'm not quite sure yet whether to formulate it as a DDDS
  application or not.

  This I-D will define an algorithm on how to map an FQDN
  to a list of URI-sets and how to interpret those.

  The algorithm is close to the one described in
  draft-lendl-sip-peering-policy-00.txt:

  For the application protocol "SIP", do:

  1) Get all NAPTR records residing in the input domain
     whose service field matches "D2P+SIP(:.*)?" and where
     the flag is either empty or "u".
  
  2) If there is a record with an empty flag (""), then
     use the replacement field as the new input and
     recurse.

  3) If no matching NAPTRs were found, revert to old rules.

  4) Group (and sort) all NAPTRs found by "order".

  5) Loop over these sets of NAPTR records (lowest order first):

  	5a) Evaluate the regex to get an URI for each NAPTR.
	5b) Interpret each URI as a requirement according to
	    the subsequent I-D which define sub-types for the
	    service-field. Unknown sub-types are considered
	    to be unfulfilled.
	5c) If all requirements as defined by the NAPTRs of one
	    set can be fulfilled then the algorithm terminates
	    with a positive result.

  6) If the algorithm arrives here then no connection is possible.

  NAPTRs according to this I-D must have either flag empty ""
  and contain a valid FQDN in the replacement field or flag "u" 
  in which case the regexp must be of the form "!.*!<uri>!",
  i.e. always unconditionally map the input to an URI.

  This I-D must also (again similar to RFC3761) define how 
  subsequent RFCs can specify the interpretation rules for
  new sup-types.

* A second I-D describes NAPTRs defining federation memberships
  for this framework.

  It uses sub-type "federation", thus in the context of SIP
  peering we get "D2P+SIP:federation" as service field.

  As a change to the current draft, federations names are
  no longer FQDNs, but URIs. Thus we need a convention for
  those. (maybe urn:ietf:speermint:feds:XXXXX)

  Such a rule is fulfilled if the originating network
  is a member in the indicated federation.

  This I-D must also define the URI for the "Open Internet"-
  federation. (The set of RFC 3263 - compliant SIP-servers)

* A third I-D defining technical restrictions.

  Sub-type is "tech", thus e.g. "D2P+SIP:tech".

  The URIs identify standards, e.g.

	RFCs: urn:ietf:rfc:<number>    (or whatever the official urn is)
	W3C:  http://www.w3.org/2000/09/xmldsig#enveloped-signature
	I-Ds: http://www.ietf.org/internet-drafts/draft-ietf-XXXX.txt
	Any XML namespace registered by IANA
	[...]

  Such a policy rule is fulfilled if the sending network supports the
  referenced standard.

* Fancy XML policy languages fit also nicely into this system, the
  SAML/XACML crowd could also define their subtype, e.g. "XACML".

  Thus a service field "D2P+SIP:XACML" would lead to a 
  http: URL linking to the actual XACML rules document.

  Such an I-D needs to be clear how to construct the "Request" and
  "Context" objects to which these Rules are then applied.

Comments?

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

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

---

From: Richard Shockey <[email-masked]>
Date: Wed, 11 Jan 2006 12:46:43 -0500

>   a lot of content. Who is be willing to co-author this one?

I think the problem statement and current termonology draft could be merged.

>   I'm not quite sure yet whether to formulate it as a DDDS

I think you should.

>      the flag is either empty or "u".

If you want define a new Enumservice field based on D2P vs E2U you will 
have to define this as a new DDDS.

>      use the replacement field as the new input and

Correct.

>   peering we get "D2P+SIP:federation" as service field.

just use D2P+sip:fed:(uritype) NAPTR records are getting large as it is. 
   IN theory you can string out the enumservice field out as long as you 
need

>   Sub-type is "tech", thus e.g. "D2P+SIP:tech".

tech:(URI) there may be more that one way to retrieve the same policy 
set as in ftp vs http etc.

>   SAML/XACML crowd could also define their subtype, e.g. "XACML".

http:xacml IMHO

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: David Meyer <[email-masked]>
Date: Wed, 11 Jan 2006 11:55:22 -0800

> I think the problem statement and current termonology draft could be 

	Actually, that's not a bad idea. Omar? I can take a whack
	at that and post a revision of draft-...terminology if
	we find consensus to merge the problem statement with the
	terminology draft.

> >  I'm not quite sure yet whether to formulate it as a DDDS

	Again, not a bad idea.

	Dave

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 11 Jan 2006 21:43:06 +0100

> >  I'm not quite sure yet whether to formulate it as a DDDS

The algorithm is close enough, but I'm not sure whether my
idea of combining several rules (the ones with the same order field)
into one boolean expression fits into the DDDS algorithm.

> have to define this as a new DDDS.

This is completely independent of ENUM. It's a sister protocol and
as such it will borrow only some ideas from RFC 3271.

This will either be a new DDDS application or just some algorithm
which makes use of NAPTR records and some ideas from DDDS.
(As I read it, RFC 3263 isn't a full featured DDDS either.)

> >	    set can be fulfilled then the algorithm terminates

---------------^^^^^^^^
This is the part where I'm not sure whether that's compatible with 
the generic DDDS algorithm. 

>   IN theory you can string out the enumservice field out as long as you 

"fed" or "federation" doesn't matter. 

The service field ("enumservice" is a mis-nomer here, we're in 3402
language, not 3671) is used to select the NAPTRs used for this DDDS
application from the ones used for others.

My thinking here was:

"D2P"		We're a "Domain to Policy" application

"SIP"		We're trying to find policy as applies to SIP
		(in contrast to e.g. "SMTP" which could be used to
		publish email acceptance policy.)

"fed"		This is a federation membership rule as defined by
		RFC xxxx. As the right hand side URI acts as a
		ID and not as URL, I don't see the necessity to include
		the uri-type in the service field.

> set as in ftp vs http etc.

I don't see the need to actually retrieve the standards here.
The URIs only act as the unique identifier of a standard and
no application will every try to retrieve the standardisation
document.

Consider them like XML namespace-URIs. They are just IDs.

> >  http: URL linking to the actual XACML rules document.

As we're dealing with real URLs here it makes sense to include 
the protocol used to retrieve the document. I'd go for xacml:http,
though.

/ol