Subject: [Sipping] draft-ietf-sipping-config-framework-10

From: Cullen Jennings <[email-masked]>
Date: Sat, 20 Jan 2007 10:58:10 -0800

Thanks for getting this out.

Big comments :

My one big comment is about the security stuff - I think we should  
have a phone call about the security model for this works, what we  
need to secure from, and how we are going to do it. We need to talk  
about what credential will be used at various stages and where theses  
will come from. I suspect  some changes are needed here but we need  
to get on the same page first. We also need to consider things like  
where do the credentials come from and in what order. I want to make  
sure it is possible that the device profile can have the credentials  
used for user. (I'm fine if some uses do not, I just want to make  
sure this use case is possible).

Related to the security issues, the approach in 5.6.1 significantly  
complicates things. I have yet to understand why this additional  
flexibility in the order of things was needed. I would like to  
consider if we really need it and what it will take to secure it in  
practical deployments

Small Comments:

In section 5.6.1, I think it is mandatory that if this approach is  
used, that it results in the information to form a subscriptions  
which must be formed. Without this the framework fails to meet it's  
requirements of being to get notifications about changes.

I think there are places where the From gets used in the wrong way  
and the Contact header should be used instead. Specifically I have  
problems with how the From is used in subscription for the local- 
network profile. This is the wrong semantics form From (and exactly  
the right semantics for Contact) and breaks things like Identity and  
makes the meaning of the From header in SIP even more confused than  
it is now.

Small notes - don't be surprised if the the IESG tells you the MAC:  
looks like a a URN and request you define it as a URN.

When looking a local network config, if DHCP says the domain is  
example.com, I do not think we should look at example.com, I think we  
should only look at _sipuaconfig.example.com. This stops us from  
sending random requests to things that don't support this framework  
and seem to still provide all the flexibility for people that want to  
use DHCP based discovery.

Instead of a DNS name of sipuaconfig, it should be _sipuaconfig.

Cullen <with my individual contributor hat on>

_______________________________________________
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