Subject: [Sipping] WGLC for configuration package

From: Rohan Mahy <[email-masked]>
Date: Tue, 14 Dec 2004 11:11:49 -0800

Hi,

I'd like to start a Working Group Last Call for:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-config- 
framework-05.txt

This WGLC will end on January 10, 2005.

thanks,
-rohan

_______________________________________________
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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Dec 2004 08:06:57 -0800

One of the goals of this draft is to be able to plug in a new UA and have it
work. I assume that this means we will be transferring things like the
credentials to log on a proxy or turn server over this configuration data. I
think the security aspects of enrolment are not really covered in this. We
might want to have a look at:

draft-pritikin-ttimodel-01.txt
draft-tschofenig-enroll-next-steps-00.txt

I'm particularly interested in making sure there is a way where if the UA
had a deceive specific certificate that was bound to it's instance ID, then
there was a way for the device to use that to authenticate.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Dec 2004 12:33:51 -0800

In a word, I don't think this is ready for WGLC and has several open issues.

I think all this configuration stuff should go to IESG as a bundle and it it
should be WGLC together. It's hard to say the framework is going to need to
be changed as we actually work out the details of how it works.

I send some comments about this back in November and would have hope to see
those incorporated in a revision before this was WGLC - all theses comments
still apply.

My biggest concern is this draft seems to carefully gloss the issues that
the the device/user/applications/local profiles need to all be fetched and
need to be merged. This whole issues and how it works seems like it should
be one of they key parts of the framework.

My second largest concern is that concern is that this has no hope of making
devices and servers that could actually interoperate. The server could send
some URI, perhaps, an LDAP, the client does not have to implement any
particular schemes. I can't tell how the server can discover what the client
supports. I can't see how the client can report an error to the server. I
think we should make HTTP and HTTPS MUST implement and dump the rest.

My third concern is there are way to many options and it's just not clear
they are needed.

I don't understand what application profile is or why it is needed? Why is
Network-user not defined for applications? Why is it needed for others -
Could just the From be used?

Effective-By seems underspecified - does the UA send the OK to the notify
after the UA succeeds in making it effective?

Does the server store one copy of the data for each value of the app-id

I think specify no must implement transports (FTP, HTTP, HTTPS, LDAP, XCAP)
is an absolute disaster for any hope of building equipment that actually
interoperates. 

It says
   When the Event header "profile-type" is "device" and the user agent
   has provided the user's AOR in the "network-user" parameter, the
   profile delivery server MAY set or change the default user associated
   with the device indicated in the SUBSCRIBE URI.
I don't really know what this means. but continues
   This is an
   implementation or policy decision.  The profile delivery server
   SHOULD authenticate the user for the SUBSCIRBE request before
   effecting the default user indicated in the "network-user" parameter.
How does it do this? Again what for? can From be used?
This stuff may be all exactly right, I just don't understand how it works or
what the motivation for it is.

I had some vague recollection we decided to use something like more obtuse
than sipuaconfig.

There is a way to enroll - is there a way to unenroll? How does the
authentication work for enrollment?

Interaction with XCAP paths is pretty vague.

How can the NOTIFY pass credentials to use to fetch the profiles

I think the whole system would be better if we said that the instance id
MUST be a UUID. I know some people don't agree with this and am not
concerned if we don't change this but I have so far not heard a single
argument against why it does not meet every single need we have identified
with one simple mechanism instead of having all kinds of wacky different
things. 

There are many small detail issues but I think they are secondary to points
raised here. As I said in my previous email, I think this is getting close.

Don't get the idea I don't like this - I think that is is absolutely
essential and really good work - just needs a bit more.

Cullen