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

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

At 04:26 PM 11/5/2007, Janet P Gunn wrote:

>In line
>
>Janet
>
>Dale.Worley@comcast.net wrote on 11/05/2007 05:04:11 PM:
>
> >    From: "Attila Sipos" <attila.sipos@vegastream.com>
> >
> >    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 A@a.com calls B@b.com, 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?
> >
> > 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.
>
>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.
>
> >
> > This is pretty much how *any* priority-identification system has to be
> > operated.
> >
> > Dale
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip