Subject: Re: [Sip] tsvchange and Supported/Require, was: [Sip] Last Call comments on 2543bis-07

From: William Marshall <[email-masked]>
Date: Wed, 13 Feb 2002 16:43:46 -0500 (EST)

Jonathan wrote, in part:
> It remains totally unclear to me that any extensions are needed to
> support [legal intercept] functions. People are already using b2bua and
> media intermediaries for this as you well know. 

If you are interested in understanding electronic surveillance 
requirements, I can send megabytes of documents.  If not, then continue 
to make statements about a b2bua w/media doing the job.  Either way,
per raven, the discussion does not belong on an ietf list.  And that
is somewhat difficult as it requires extensions.

> Are you honestly trying to tell me, that using an extension without a
> Require/Supported tag, won't allow us to get to 5 nines of reliability?
> On what concrete technical grounds could you conceivably make such a
> claim? I anxiously wait the numerical analysis. Sounds like more FUD to
> me - "uh oh, SIP can't do five nines!". 

It is up to you as a vendor to show how you meet a reliability
goal.  My claim is that one of the commonly-used tools to achieve
this in the past is duplication and double-checking within the
messages themselves.  If you can achieve the reliability without it,
fine.  I would think that other vendors might be more interested
in keeping the tools available.

Bill Marshall
[email-masked]

-----original message-----
Date: Wed, 13 Feb 2002 01:18:16 -0500
From: Jonathan Rosenberg <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sip] tsvchange and Supported/Require, was: [Sip] Last Call comments on 2543bis-07

William Marshall wrote:
> 
> The text that I am objecting to here first appeared in the bis rewrite
> (bis-05).  If it was preceeded by any list discussion leading to a
> consensus that it should be included, then I missed it.  I've been
> objecting regularly ever since the text in bis-05 appeared.

As I have said, this text was the result of discussions with IESG, who
requested its inclusion in the specification. The words you are reading
were carefully reviewed and scrutinized. It is frequent for changes in
documents to be based on IESG feedback.

> 
> The discussion last week concluded, I believe, that IANA registration
> of header names and option tags, combined with text regarding formats
> and discussion to appear in the extension guidelines draft, was
> sufficient.  No reference to tsvarea-sipchange was needed.

Agreed.

> There are a number of "facts" that I don't think need any discussion.
> Some of these are 1) Carriers will be obliged to meet regulatory
> requirements, and 2) Some regulatory requirements will not be
> standardized by IETF.  As I stated before, it is an ugly subject.
> 
> So assume there is an implementation of a protocol that starts with
> SIP and adds extensions necessary to meet the regulatory requirements
> on carriers.  IETF then publically states that it is not compliant
> to SIP.  Then the decision comes down from high that SIP can't meet
> the service requirements, so pick a standard protocol that can.
> And then the whole network architecture is changed.

Bill, these are FUD arguments, very similar to ones I have heard in the
past
to push other drafts that I shall not name. I am honestly quite tired at
this point of these kinds of "do as I say or we will use something else"
arguments, as they are
nothing more than veiled threats. Please keep them to yourself.

First off, no one ever said that IETF can't or won't work on extensions
for meeting regulatory requirements. Things like 911 are of much
interest to people here, and are being worked on. Perhaps you refer to
raven, where the decision was that IETF won't work on legal intercept.
It remains totally unclear to me that any extensions are needed to
support these kinds of functions. People are already using b2bua and
media intermediaries for this as you well know. While I may dislike such
things, they are within the realm of the specifications to build them. 

So, what exactly ARE you talking about? 

Let us, for the moment, entertain the notion that there is some
extension which cannot be done at IETF, and which is useful for some
kind of service mandated by regulatory requirements. Fine. A SIP
implementation that uses them is still SIP compliant. The problem only
arises if the client INSISTS that the network or endpoints provide this
service, or vice-a-versa. It is not clear to me at all that any such
extension would be built such that a client or server HAD to implement
it in order to provide service to another sip element.

> If the additional headers were added based on IANA registration,
> but an option tag were not, then the problem becomes one of system
> reliability.  As I stated above, double-checks like the header-optiontag
> are the tools to get to 5 9's.  Give up on the reliability goal?  I
> doubt it.

Are you honestly trying to tell me, that using an extension without a
Require/Supported tag, won't allow us to get to 5 nines of reliability?
On what concrete technical grounds could you conceivably make such a
claim? I anxiously wait the numerical analysis. Sounds like more FUD to
me - "uh oh, SIP can't do five nines!". 

> 
> While I agree there is a problem that allows abuse by the unnamed
> large vendor, the solution proposed in bis-05 has other unintended
> side-effects.  The only solution I can see is to allow these
> non-standards-track extensions, and try again at the general problem.

I am in favor of keeping the text as it stands. To further the point, it
is my understanding that IESG still feels that the words that are there
are needed, even in the presence of some IANA registration mechanism for
headers.

-Jonathan R.

_______________________________________________
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