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

From: William Marshall <[email-masked]>
Date: Tue, 12 Feb 2002 08:37:26 -0500 (EST)

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.

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.

While registration of header names could be independent of option
tags, it is not clear that is a good idea.  The "Proxy-Require" with
an option tag corresponding to an added header is one technique
similar to those used to go from 4 9's of reliability to 5 9's.
If all is working well the option tag in the Proxy-Require is
totally redundant; however it serves as a backup check on several
other parts of the system (like message routing in particular).

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.

Where can we break this sequence before it reaches the bad conclusion?
One way is to design the extensions needed for regulatory requirements
so that they don't need new headers.  One way is to keep the IANA
registry of headers, but don't add a Proxy-Require tag.  One way is
to allow the result to be called compliant to the specification
of SIP.

It would be nice if no new information were needed to convey between
proxies.  Unfortunately there are cases (actually very common cases)
where it is essential.  This was studied in depth for PacketCable.
I'd welcome alternative designs, but am very skeptical.  This is not
a subject for the sip list, anyway.

If the additional information needed to meet regulatory requirements
were, instead, added as a body part (making a multi-part attachment),
then the problem just moves.  The "content-type" of this additional
body part would need a name, and the requirement would then be that
the receiving proxy understand this new content-type.  That seems
no different than understanding a new header.  And if routing goofs,
then this multi-part reaches the UAS.  While a UAS could easily recover
from an unknown header in the request, it is not so clear that it
could recover from an unknown multi-part body.

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.

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.

Bill Marshall
[email-masked]

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

going through this thread, logging the bugs needed to be fixed. Ran into
a question here:

William Marshall wrote:
> 2) Carriers are unfortunately obliged to meet regulatory requirements.
> At least some of these, related to Electronic Surveillance, will not
> be standardized by IETF (see RFC 2804), though publication is
> encouraged (presumably as informational RFCs).  However, they may
> require
> extensions to SIP, and definition of additional headers and option tags.
> 
> It would be unfortunate if this resulting protocol could not be called
> SIP.  This is an ugly subject, granted, and I do not want it to delay
> publication of bis as an RFC.  My proposed resolution of this is
> to have bis make reference to draft-tsvarea-sipchange-xx for the
> guidelines of extensions being standard-track RFCs, and have the
> discussion when that draft is re-issued and last-called.
> Affects lines 1094-7, 1103-4, 1306-7

I think much of this thread was not properly interpreted by the list,
because people are not aware of the specific content of these lines. And
that makes a big difference.

These lines are about the usage of option tags in Supported and Require.
The spec says that these headers can only contain references to
standards track RFCs. That does NOT mean that one can't define an
extension to sip outside of IETF and use it (that is covered by
tsvchange). This requirement does say that such an extension could not
be *required* by clients, and it cannot be indicated as being explicitly
supported (which would allow servers to require it).

These words about Require and Supported come from IESG, and they are
based on bad experiences with protocols in the past that did not have
such restrictions. Specifically, a protocol in the past allowed for
mandatory vendor specific extensions. This was abused by a large vendor,
whose servers always required support of their extensions from clients.
That vendor was able to call their product compliant to the spec. What
we are hoping to avoid is similar problems with SIP. You can't force
someone to only put standards-track tags in Require/Supported, but if
they do, you can at least publically state that it is not compliant to
the specification.

Since this issue is really independent of tsv-change, there is no need
to reference tsv-change at all, and I have no plans to do so.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Feb 2002 01:18:16 -0500

> 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.

> sufficient.  No reference to tsvarea-sipchange was needed.

Agreed.

> 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.

> are the tools to get to 5 9's.  Give up on the reliability goal?  I

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!". 

> 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.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com