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

[William Marshall <[e-mail]>]

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
[e-mail]

-----original message-----
Date: Mon, 11 Feb 2002 16:33:20 -0500
From: Jonathan Rosenberg <[e-mail]>
To: William Marshall <[e-mail]>
Cc: [e-mail]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip