Subject: [Sipping] Comments to draft-ietf-sipping-aaa-reqs-02 WGLC

From: [email-masked]
Date: Thu, 27 Mar 2003 14:32:35 +0200

Hi,

Here are a few comments/suggestions:

- Ch 1.1 on Terminology
	* Accounting has a very nice definition in RFC 2975, suggestion is
	  to use that, or the one from Diameter base protocol.
	* Home AAA server definition is confusing.
	* Online/offline accounting definitions might also benefit from RFC 2975
	  definition on real time accounting.
	* The last four definitions could also be copied from RFC 3261

- Ch 2, first paragraph; the motivational text doesn't seem really assuring and
	begs the question "If a requirement isn't intended to be supported, why
	list it?" Perhaps just say that different deployment scenarios may have
	a different set of requirements, e.g., a subset of the requirements listed
	in the chapter.

- Ch 2.1.5., I think I understand what is meant here, but the sentence could
	be clearer about what it means for a SIP entity to "have" a user. Does it imply
	an administration type relationship, like say a registrar or a presence agent?

- Ch 2.2.2, This should probably be split into two separate requirements. I think
	the first sentence is about authentication between the SIP server and 
	AAA server, whereas the latter talks about authentication schemes
	supported by the SIP-AAA interface. I.e., authentication between the UA and
	the SIP server.

- Ch 2.3.1, The note about CANCEL below the requirment may well be true, but the 
	last sentence contradicts with requirement 2.2.1. After all, if the CANCEL 
	can't be authenticated, there's no way to determine that the sender is the
	one who originally generated the request to be cancelled.

- Ch 2.3.3, Seems that Req 2.3.2 already at least partly covers this requirement.
	Also, may I suggest that the user profile example be separated
	from the text describing the requirement, perhaps as a note or a separate
	paragraph.

- Ch 2.3.4, similar to de-authorization, there should also be a requirement about
	re-authorization. This would be useful in tasks that require refreshes, such
	as registrations and subscriptions.

- Ch 2.4, first paragraph; I think much of the motivational text could well be 
	omitted if the term "accounting" had been properly defined in Ch 1.1.

- Ch 2.4.1, This seems like a good thing, but it's hard to really understand what
	is required. Is it that accounting information is granular? I can imagine this
	to be useful not only in session duration but also in other services. 

- Ch 2.4.2 and 2.4.3, I don't quite understand the meaning of  "direct bearing on".
	I'm sure there's a better term to describe the relationship. Perhaps "link" or
	"correlation"?

- Ch 2.4.5, I believe this is a general requirement, and not only relevant to
	charging.

- Ch 2.4.6, This requirement again talks about charging when I don't think it
	needs to.

- Ch 2.4.10, Suggestion is to separate the example from the requirement text. 
	Also, the example seems to also talk about authorization based on real-time
	accounting data - perhaps a requirement for the Authorization section?

Cheers,
Aki 
  
_______________________________________________
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