Subject: RE: [Sip] namespaces in RFC 4411, 4412 and draft-ietf-sip-rph-new-namespaces-00

From: "Attila Sipos" <[email-masked]>
Date: Mon, 5 Nov 2007 15:13:44 -0000

Hi,

I have tried asking these questions on SIP-implementors
but not getting any responses.  Are these silly questions...?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Attila Sipos
Sent: 01 November 2007 08:52
To: [email-masked]
Subject: [Sip-implementors] namespaces in RFC 4411,4412 and
draft-ietf-sip-rph-new-namespaces-00

Are namespaces just a way to group together different users across
different DNS domains?

What if a.com is using namespaces "dsn-000000" to "dsn-000009"
and b.com is using the same namespaces?
Then if [email-masked] calls [email-masked], wouldn't the namespaces interfere?

What looks after or checks the namespaces?
Is it that a proxy knows what everyone's namespace should be?
So if someone wants to do "UA Preemption" and tries to use a resource
priority level higher than they should have, then will the domain's
proxy downgrade it back to the correct permitted level?

Regards,

Attila

_______________________________________________
Sip-implementors mailing list
[email-masked]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
[email-masked]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 5 Nov 2007 16:24:39 +0100

Theoreticallly, there is no relationship between namespaces and domains. 

However, it is possible that different domains use different namespaces. When a SIP message travels along different providers then one would have to map the different priorities someone ....

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: ext Attila Sipos [mailto:[email-masked]] 
> Gesendet: Montag, 5. November 2007 16:14
> An: [email-masked]
> Betreff: RE: [Sip] namespaces in RFC 4411,4412 and

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 5 Nov 2007 17:36:00 +0100

I don't think it is explicitly covered in the RFC 4412, but there are
clear pointers to what needs to be done.

There needs to be agreement between the administrative domains as to
what is passed across the boundaries between the adminstrative domains.
This could take a number of forms:

-	the header is not passed at all because there is no agreement
between the administrations. Any priority handling only exists in the
source domain.
-	the header is passed and the two administrations agree to use
the same namespace in a compatible fashion.
-	by agreement, different namespaces are conveyed by the two
adminstrations, and two Resource-Priority headers are included that are
each used by the owning administration. 

Regards

Keith

> From: Attila Sipos [mailto:[email-masked]] 
> Sent: Monday, November 05, 2007 3:14 PM
> To: [email-masked]
> Subject: RE: [Sip] namespaces in RFC 4411,4412 and 
> I have tried asking these questions on SIP-implementors but 
> not getting any responses.  Are these silly questions...?
> 
> 
> 
> 
> [mailto:[email-masked]] On 
> Behalf Of Attila Sipos
> Are namespaces just a way to group together different users 
> across different DNS domains?
> 
> So if someone wants to do "UA Preemption" and tries to use a 
> resource priority level higher than they should have, then 
> will the domain's proxy downgrade it back to the correct 
> permitted level?
> 
> 
> Regards,
> 
> Attila
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: [email-masked]
Date: Mon, 5 Nov 2007 17:04:11 -0500

From: "Attila Sipos" <[email-masked]>

The primary thing is that resource-priority namespaces are registered
with IANA (RFC 4412, section 3.1).

Within any administrative domain, if it processes resource-priorities
at all, it will generally sanitize any incoming SIP messages to match
the policy of the domain.  As a default, this means that it is going
to strip any resource-priority identification.  Above that, it may
respect resource-priority identification if the domain has a suitable
working relationsip with the terminal or domain from which the message
is entering -- but that relationship will explicitly or implicitly
define how the resource-priority identifications will be preserved or
transformed at the boundary.

This is pretty much how *any* priority-identification system has to be
operated.

Dale

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 5 Nov 2007 17:26:58 -0500

In line

Janet

> transformed at the boundary.

I am not so sure about that ( the stripping as a default). 

I would think that (consistent with RFC 4412 
and RFC 3261)the default (when the edge device at a new domain receives an 

RPH with an unrecognized namespace) would be to pass and ignore the 
unrecognized name space. 

This is described in section 4.6.2 of RFC 4412:
"4.6.2.  No Known Namespace or Priority Value

   If an RP actor does not understand any of the resource values in the
   request, the treatment depends on the presence of the 'Require'
   'resource-priority' option tag:

   1.  Without the option tag, the RP actor treats the request as if it
       contained no 'Resource-Priority' header field and processes it
       with default priority.  Resource values that are not understood
       MUST NOT be modified or deleted.

   2.  With the option tag, it MUST reject the request with a 417
       (Unknown Resource-Priority) response code.

   Making case (1) the default is necessary since otherwise there would
   be no way to successfully complete any calls in the case where a
   proxy on the way to the UAS shares no common namespaces with the UAC,
   but the UAC and UAS do have such a namespace in common.

   In general, as noted, a SIP request can contain more than one
   'Resource-Priority' header field.  This is necessary if a request
   needs to traverse different administrative domains, each with its own
   set of valid resource values.  For example, the ETS namespace might
   be enabled for United States government networks that also support
   the DSN and/or DRSN namespaces for most individuals in those domains."

Your suggested behavior would seem to violate this.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 05 Nov 2007 17:09:49 -0600

Janet

I think Dale is pointing out a common practice wrt cross-boundary 
priority indications.  What you want, and why this is in RFC 4412, is 
a special case - one in which adjacent SPs (or domains) agree the 
same marking means the same across these boundaries, and that 
existing indications, regardless of whether they are acted upon, 
remain in the message at these boundary crossing points.

I don't believe where each of you are coming from are inconsistent to 
the other.

Time will tell how well this mechanism works where more than one 
domain is involved.

James

---

From: [email-masked]
Date: Tue, 6 Nov 2007 17:20:38 -0500

From: Janet P Gunn <[email-masked]>

That's true.  But I think the RFC-compliant behavior doesn't take into
account how the incoming request validates that it is authorized to
use the priority it has claimed.  The practical result is that
whenever a request crosses a trust boundary, the network operator of
the network being entered is going to remove any priority request.

I expect that the rules of the RFC will be followed by any elements
inside a *network*.  But I expect network ingress/egress elements to
violate it by default.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Nov 2007 17:34:30 -0500

> inside a *network*.  But I expect network ingress/egress elements to

If the header is truly only a *request*, with no implication of asserted 
authorization, then there is no reason to remove it.

BUT, unless you can authenticate the sender of the request and authorize 
them to receive the priority they have requested, then there is little 
likelihood that it will be granted.

So the key issue is how authorization is determined. If this is a closed 
military network then I imagine they will have some kind of transitive 
trust that will support this.

But if the goal here is for emergency service workers to obtain priority 
over all sorts of networks, then I can't imagine how it can work.

	Paul