Subject: Re: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets ...

From: [email-masked]
Date: Sat, 6 Nov 2004 14:27:52 EST

In a message dated 11/6/2004 12:38:18 AM Eastern Standard Time, 
[email-masked] writes:

> Of the namespaces described in the document, dsn, drsn and q735 (all
> variants of "MLPP") are defined as "strict".  ets and wps are defined as
> "semi-strict".  None are defined as loose.
> 
> Unfortunately, this  (semi-strict) is NOT the behavior desired for the ets
> and wps namespaces.
> 
> 

Likewise, "strict" is not the behavior desired for dsn, drsn, or q735. 
"Strict" says that it requires the RP header in a bunch of messages. Since these 
three namespaces are based on Q.735 (MLPP), it is expected that the procedures 
should be based on that standard. Therefore, the RP header only goes in the 
INVITE. The procedures do not require it in any other messages.

Further, DSN may choose to allow the absence of any RP header to mean to use 
the lowest (Routine), thus the purpose for specifying a "default level to be 
assumed in the absence of the priority value" as version -01 of this draft 
stated. I don't remember any discussion/agreement to remove this statement about 
"default", but maybe there was. The description of "Loose" mode in 4.3.5 still 
seems to require that there be a known default.

This draft is going way beyond what is required to define a simple header to 
carry a simple piece of information.

Where was the discussion on the list or elsewhere about adding the third 
mode? In the previous draft, as agreed in previous discussions, "strict" vs. 
"loose" modes only pertained to specifying "handling requests with unknown 
namespaces or priority values". This latest version greatly expands the meaning and 
use of this "mode" to specify other aspects of operation, such as relating 
"strict" mode with the use of preemption (section 4.5.1). The previous drafts 
stayed away from specifying the operation for specific cases, since this should be 
the subject of other documents.

In 4.3.4 for Semi-Strict Mode, whether or not the messages "must" contain an 
authorization header or [something unknown from the Trait-based Authorization 
effort] depends on the security architecture of the network in which this is 
being used. There may be networks that use a different approach. It is 
inappropriate for this RP draft to require specific authorization methods. In any 
case, this reference to "trait-based authorization" is normative, not informative.

The basic definitions of "strict" and "loose" modes in version -04 should be 
retained, not all this new material in -05. In fact, all of -04 should be 
accepted as the basis for further discussions, not -05.

Mike Pierce

_______________________________________________
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: [email-masked]
Date: Sun, 7 Nov 2004 10:46:31 EST

In a message dated 11/6/2004 7:21:20 PM Eastern Standard Time, 
[email-masked] writes:

> Would it be better to have each namespace definition fully define the 
> behavior of that namesapce, rather than trying to have some "templates" 
> that could be re-used by multiple namespaces?
> 
Absolutely, and as described in earlier versions of this draft, that 
documentation does not have to be in an RFC. That is also why I object to this new 
version -05. It requires an RFC for every new namespace. Future uses can not, nor 
should they have to, go through this excruciating process of producing an RFC 
just to register a new namespace.

------------------------------------------------------------------------------
---------------------
In a message dated 11/7/2004 9:24:23 AM Eastern Standard Time, 
[email-masked] writes:

> Also, when you say the NCS "owns" GETS and WPS, are you refering to the 
> systems
> or the namespace?  If its both, then I have my doubts about the latter.  I 
> see
> no association of the NCS with WPS or GETS in the draft and it would seem 
> that
> initial "ownership" of those namespaces, as well as the others like ETS, lies
> with the authors of the draft.  (I'll be happy to be corrected on that
> assumption).
> 
In the case of the DSN namespace, the previous version of this draft had the 
following for the definition of this namespace:

9.5.2  Namespace dsn

   Namespace: dsn
   Description: United States Defense Switched Network.  The values are
      adopted from RFC 791 [RFC0791], omitting the levels "critic-ecp",
      "network control" and "internetwork control", as these are
      inappropriate here.
   Documentation: ANSI T1.619, Section B1
   Organization: United States Department of Defense, Defense
      Information Systems Agency (DISA).

So, in a way, DISA does "own" this namespace. At least, DISA is responsible 
for defining its operation within its own network.
This material was removed from the latest version, which also is why I object 
to accepting version -05.

And, no, the "ownership" of these namespaces does not lie with the "authors" 
at this point. It is a Working Group draft, meaning that the "ownership" 
currently lies with the WG as a whole, and changes to this draft should not be made 
unless agreed to by the WG. There was never any discussion about many of 
these changes in -05.

Mike Pierce