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

Mpierce1@aol.com Sun, 07 November 2004 15:56 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28889 for <sip-web-archive@ietf.org>; Sun, 7 Nov 2004 10:56:48 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpPl-0005jy-N4 for sip-web-archive@ietf.org; Sun, 07 Nov 2004 10:57:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpI4-0007OL-KR; Sun, 07 Nov 2004 10:49:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpG3-0006sw-I4 for sip@megatron.ietf.org; Sun, 07 Nov 2004 10:47:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28189 for <sip@ietf.org>; Sun, 7 Nov 2004 10:47:09 -0500 (EST)
From: Mpierce1@aol.com
Received: from imo-d06.mx.aol.com ([205.188.157.38]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpGM-0005VJ-S8 for sip@ietf.org; Sun, 07 Nov 2004 10:47:34 -0500
Received: from Mpierce1@aol.com by imo-d06.mx.aol.com (mail_out_v37_r3.8.) id l.1d8.2fad9d47 (4340); Sun, 7 Nov 2004 10:46:32 -0500 (EST)
Message-ID: <1d8.2fad9d47.2ebf9d57@aol.com>
Date: Sun, 07 Nov 2004 10:46:31 -0500
Subject: Re: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets ...
To: sip@ietf.org
MIME-Version: 1.0
X-Mailer: 6.0 for Windows XP sub 10500
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Cc: jmpolk@cisco.com, jgunn6@csc.com, carlberg@g11.org.uk, dean.willis@softarmor.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0696415664=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba

In a message dated 11/6/2004 7:21:20 PM Eastern Standard Time, 
dean.willis@softarmor.com 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, 
carlberg@g11.org.uk 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


_______________________________________________
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