Subject: [Sipping] comments on config-framework-07

From: Goix Walter <[email-masked]>
Date: Wed, 17 Aug 2005 01:42:46 +0200

All,
I've run through the draft and it's just becoming a great work to finally have
such an easy mean to manage UAs. However, I still have some comments/doubts on
some specific sections, some of them also related to the new version.
 
- section 7.2, p13: the vendor, model and version parameters are defined to be
the ones of the SIP user agent. What is then the difference with the content of
the User-Agent header? Is that simply a matter of mandating this data? It could
be useful to get a better understanding of the relationship between both.
 
- section 7.2, p13: The need for an extra parameter here is not clear to me as
well: what is the rationale not to put it into the From: header? In most
networks and implementations, authentication is done based on that header, which
is useful because common to all SIP methods and event frameworks, without the
need to check for a specific event package to know what to authenticate
against. besides, it is still not clear when a user agent on the device decides
to put this parameter or not. It should be clear to implementors when to put it,
whether this is a local configuration param, if we don't want to get half of the
implementations inserting it, half not. Finally, the parameter accepts a name-addr
right now, i.e allows for display names: isn't this a bit complex for a
parameter since it may include quotes, spaces, etc? Isn't the addr-spec enough,
moreover if this field is only to be interpreted by a server?
 
- section 7.2, p15: AUID seems to be now only used with XCAP. Why this change?
There are way of reasons to keep some kind of application id to identify profile
data which is not XML-based and has no reason to be wrapped as CDATA in XML. The
current version of the draft actually would not prevent some implementer to use
the auid without XCAP (except the wording there is no technical limitation), and
i personally do not see the reason for limiting this usage. Rather, i would see
a clear distinction between the usage of this event package with XCAP and use it
without XCAP (for example for content which is not XML based). It may be worth
to consider some parameters only for XCAP (pretty much as it is now) while
having others more generic: would that be reasonable to specify a document
parameter with "<auid>/global", or even "<auid>/global/*" to simulate the auid
parameter (which if i understood means all docs for this specific application
usage), and in this case have the auid value set to "xcap" (or "org.ietf.xcap")
when XCAP is to be used. For auids different than XCAP, the document parameter
would not have any meaning and be ignored. This specific solution may not work
with usage of XCAP with other profile types than application, but still other
types of profile content should be supported (not only XML).
Still in this paragraph it is currently said that setting both aiud and document
parameters is an error, but there is no behavior suggested. How shoud the server
behave, reject the request with a "bad request" error, of only consider one of
the params and ignore the other (which one?)
 
- section 7.6, p18: In the first paragraph the draft is giving strong
requirements about how the server should authenticate the device, and the type
of connection to use. However, some networks may rely on other types of
connectivity and security models (IPSec tunnel, Digest-AKA auth, etc), and still
should be able to implement this framework without the need to setup additional
TLS or digest mechanisms on top. I agree that there are huge security issues,
and that any implementation should always work within a secure environment, and
the one provided here is a good example but only an example. I would assume
lighter requirements, based on the type of underlying network, which does not
prevent other networks to implement this framework simply because of these
mechanisms.
Regarding the requirements on HTTP and HTTPS, it may be clearer to separate the
statements on HTTP (MUST) and HTTPS (MAY).
In the clarification provided, it could be useful to separate logically the
concepts of the "profile notification server" (the one which sends the NOTIFY)
from the actual "profile delivery server" (the one with the HTTP or LDAP
interface that really delivers the content), also because nothing prevents these
two entities to be running on different processes.
 
- section 7.13.1, p23, 1st paragraph: is 'recommended' intended as 'RECOMMENDED'?
Regarding the recommendation about caps, should the server be ready to receive a
lower-case version of the MAC address, or should it reject such a request?
 
- section 8.1, p25: is 'must' intended as 'MUST'?
 
- section 8.1.1, p25: idem 'SHOULD not' -> 'SHOULD NOT'? and 'should' -> 'SHOULD'?
Again, how does the UA know whether to include the 'network-user' param?
 
- section 8.1.2, p26: SIP DHCP option references only the v4 version, what about also
referencing v6 (rfc3319)?
 
- section 8.1.2, p27, bullet #3: it maybe only cosmetic, but isn't the name

'sipuaconfig' a bit far from 'ua-profile'? What about 'sipuaprofile' or 'uaprofile'?
- section 8.1.2, p27: a whole section is dedicated to the retrieving through HTTP/S
in the middle of the discovery section of the device URI, while there is very
little relationship. Maybe this could move to a standalone subsection about
retrieval. Then in the discovery section could state that "as alternative', the
device URI may be retrieved as in section ... 
 
- section 8.1.2, p28: in the clarification, i would clarify that "The profile delivery
server OF THE VISITED NETWORK never provides"...
 
- section 8.3, p29: about the diferential changes and xcap-diff, i would clarify that
this applies only for XCAP application usage (for all profile types).
 
- section 8.6, p30, 3rd paragraph: it is not claer what 'all documents' means?
Is that for all 'global' documents, or all docs under the 'users/<userAOE>' tree?
At the bottom is stated that the auid param should not be present if the document
is also present. What is the expected behavior if both are present anyway?
 
- section 8.6, p31, bullet #1: it may be clearer to say that the 'user' is
actually intended in a loose way (i.e. may represent a device)
 
- section 8.6, p31, bullet #3 and 4: These bullets should appear first, since the
auid is set before the 'global' or 'users' segment in the URI
 
- section 8.6, p31, SUBSCRIBE example: "vendor" has DNS name missing.
 
- section 8.6, p32, XCAP URI examples: auid should appear prior to 'users'
(3 times)
 
- section 8.6, p32, above last example: the example actually refers to the 'auid'
with no document parameter. Hence, it should be introduced as 'a specific AUID'
(or as 'all documents of a specific AUID'), instead of 'as a specific document'.
Maybe it would be better to consider revising the example itself to include a
document parameter.
In the last paragraph, it may be useful to illustrate the sentence with another
example.
 
- section 10, p34, 1st paragraph: i would again clarify the statements about the
requirements on the device : HTTP MUST and HTTPS MAY
 
- section 10.1, p34: again, the statement about Digest authentication is a bit
strong.
 
- section 10.3, p36, 2nd paragraph: "the following NOTIFY request" is missing...

Some editorial changes
- p8, line 8: /s/profie/profile
- p8, line 12: /s/use/is used
- p12, last paragraph: /s/rational/rationale
- p15, SUBSCRIBE example: /s/vendor="premier"/vendor="premier.com" (DNS)
- p16, both tables: /s/manditory/mandatory
- p18, line 2: /s/conections/connections
- p20, section 7.12: /s/request/requests
- p21, SUBSCRIBE example: /s/10.1.1.41/10.1.1.44 (not a big deal, but nicer ;-)
- p23, 7.13.1 last paragraph: "to need to use" (consider revision). /s/uuid/UUID.
/s/unique id/same UUID
- p24, 7.13.2, last sentence: "these are only examples AND not ..."
- p25, line 10: /s/provide/provided
- p25, 8.1.1: /s/to another other/to another one
- p28, line 7: /s/persistantly/persistently
- p28, 3 lines from the bottom: idem
- p31, line 2: /s/constucted/constructed
- p31, line 7: /s/"user"/"users" (idem line 9)
- p31, line 10: duplicated 'the'
- p34, 10.1, last sentence: /s/provide/provided
- p35, 10.2, 2nd paragraph: /s/retierve/retrieve. /s/retreival/retrieval
- p35, 10.2, 3rd paragraph: /s/authenication/authentication
 
Walter

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

_______________________________________________
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