Subject: [Sipping] The config framework nightmare

From: Cullen Jennings <[email-masked]>
Date: Mon, 07 Nov 2005 15:52:41 -0800

I am pleased to say I really like the new config-framework document.

I don't like the merge stuff in the generic datasets document. It is way to
complicated and there is no need for this level of complication. It results
in definition of merger rules in the datasets that just don't work. I will
provide examples of this later in this email.

Consider the three use cases given: outbound proxy, codec's, and transport.
Lets look at what we really need in all practical use case people have
provided. For outbound, well we need to concatenate some proxies together in
a well defined way that gets wired into the code. I think Jonathans draft is
a good start for this. On codecs, the device supports what the device
supports and everything else is a restriction off of this. Clearly we need a
max_bandwidth that many people can set and is merged in the obvious way. We
also need a "disallowed_codec" list that merged with concatenation.  We
don't need containers of sets of allow/disallow etc. There has yet to be a
use case for anyone other than one party to set the order of the codecs -
I'm very dubious on this one. On the trasnports use case, the device
supports what it supports and we clearly need and "disallow_transport" list
off of that. Or perhaps all we need is a disallow non TLS transports. SRV of
the first proxy sets the preferences. Again all easy to see how to merge.

Now lets look at the path we are on and why this extensive complexity is a
very bad thing. 

The current core dataset document requires the transport to have a port in
it. So if the local network want to say UDP is OK but only on port 5080 it
would put allow,udp,5080 in the XML. Now the home network also allows UDP
and does not care about the port but is required to put one so it puts the
default with allow,udp,5060. This results in a merge conflict and UDP is not
allowed to be used. This is all insane - hopefully I significantly misread
the drafts and this is not the case. Either it too complicated for me to
understand, or it is too complicated for the author to make trivial examples
that work. Either way, it's too complicated and my main point is there is no
need for this level of complexity.

Let me move on to a second example, where once again, hopefully I am totally
confused but I suspect the most basic examples don't work. This is the idea
off merging the outbound proxy set using q values. Take the example the home
network has two proxy A and B set to .3 and .7. so you go through A first.
Now the local network provides a proxy L with the q set to .5. It choose .5
because what better value might it choose? So now the merger path is A,N,B
but this won't work - the path needed to be N,A,B.

The approach is too complicated and does not work. So what's my suggestion.
It pretty simple to fix all this and ship these documents really soon.

Put the profile-datasets document on the back burner until it is clear how
it works or if it is needed.  Take the actual documents defining the data
set (such as the core one) and dropt the "policy" tags out of the elements.
Define how each element is merged. For elements of name foo where we
actually need a disallow type policy, make a new element called
foo-disallowed-list. Later if we got the policy stuff worked out, we could
add policy tags back in and still do this whole scheme yet still be
backwards compatible with what I am suggesting here.

The basic design flaw of this dataset work is the assumption that the device
doing the merging needs to be able to merge abstract data that it does not
understand. This is bogus, the UA only needs to merge data that it knows how
to use - other data can be ignored. Once you make this simplification the
whole things is significantly easier.

We could be finished with this absolutely critical work before the next
IETF.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP