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

From: "Sumanth Channabasappa" <[email-masked]>
Date: Mon, 22 Jan 2007 11:52:29 -0700

Cullen,

Thanks for your comments. v10 was submitted (Fri eve), but is not yet
available on the IETF website (when I last checked). Once available, I
will send across an email listing changes at a high level (also listed
in the I-D). 

The 'Security section' (as you will see in the I-D) has not undergone
sufficient discussion and will benefit from feedback (so your email
definitely helps :) ). As indicated at the last IETF, ad-hoc calls are
being conducted and will continue to do so for this I-D. Folks
interested can send me an email directly to me or the co-chairs. 

- S

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Saturday, January 20, 2007 11:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Sipping] draft-ietf-sipping-config-framework-10

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

_______________________________________________
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