RE: [Speermint] draft-houri-speermint-rtc-provisioning-reqs-00.txt

Avshalom,

   I look forward to discussing this at the interim meeting. As the
first paragraph of my comments noted, it will be good to get more
feedback from the wg on this.

You wrote:
> I am still not sure where this type of requirements that are coming
> from a certain application as presence and IM should fit.
> Should they be part of the general requirements document? Should the
> be a use case document?

We should separate 2 topics here:
	- general requirements related to presence and IM as
applications subject to session peering. There are certainly generic
requirements that can be derived from these;
	- provisioning requirements in the context of session peering:
this is what your rtc-provisining draft is about.

I thought your focus on this draft was the latter, provisioning
requirements (which happened to be originated in the IM world but given
the wording, they could be applicable beyond IM).

Jean-Francois

> -----Original Message-----
> From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
> Sent: Sunday, September 17, 2006 7:50 PM
> To: speermint@ietf.org
> Subject: Re: [Speermint] draft-houri-speermint-rtc-provisioning-reqs-
> 00.txt
> 
> 
> Jean-Francois
> 
> While it is easy to conclude that the document has to be rewritten and
> incorporate your's and Hannes's comments
> I am still not sure where this type of requirements that are coming
> from a certain application as presence and IM should fit.
> Should they be part of the general requirements document? Should the
> be a use case document?
> 
> We should discuss this question in the interim.
> 
> Another issue that I have is that I did not see any reference to
> presence and IM in the terminology, requirements and architecture
> documents.
> I think that it was concluded that SPEARMINT is not only for VOIP but
> VOIP is the only example that is being used.
> 
> --Avshalom
> 
> 
> 
> 
> "Jean-Francois Mule" <jf.mule@cablelabs.com>
> 
> 15/09/2006 01:27
> 
> 
> To
> 	Avshalom Houri/Haifa/IBM@IBMIL
> cc
> 	<speermint@ietf.org>, <aoki@aol.net>, <timrang@microsoft.com>
> Subject
> 	[Speermint] draft-houri-speermint-rtc-provisioning-reqs-00.txt
> 
> 
> 
> 
> 
> 
> Avshalom,
> 
>   I read through your draft and here are a few comments.
> I need more input and feedback from the wg in order to understand what
> sub-sets of requirements should be refined and added to the main
> requirement doc for VoIP interconnect.
> 
> --- Terminology alignment
> As Hannes pointed out, it would be a plus if you could update the
> document to use the terminology proposed in speermint. That said, I
> think we can all map the "single community" to a "peer network". The
> latter includes users but that should be ok.
> 
> While I am familiar with clearinghouses for RTC and VoIP traffic in
> particular, I am not sure it adds value in speermint and some of your
> requirements related to clearinghouses could be isolated to peer
> networks (ADD-REQ-006, ADD-REQ-008). I would recommend presenting this
> as a special case or example of a federation where one member of the
> federation has a special role of enforcing some federation and peer
> policies.
> 
> 
> --- Core requirements
> 
> You wrote:
> | CORE-REQ-001: It should be possible to push and pull
> | provisioning data between communities
>  ^^^^^^^^^^^^^^^^^
> s/communities/peer networks
> Some 'data' has to be exchanged between peers to enable session
> peering
> but the provisioning models vary based on the solutions and may not
> require push or pull directly between the providers.
> End users may provide some URIs with domain names which suffice to
> enable session peering if the domain is RFC3263-enabled in case of SIP
> URIs for e.g.
> Or, providers may just configure DNS for their respective domain names
> appropriately (there may be a pull from DNS).
> In short, depending on the session peering models, a pull or push of
> data between peer networks may not be necessary.
> 
> 
> | CORE-REQ-002: It should be possible to secure the pushing and
> pulling
> | of provisioning data.  Provisioning data should be provided only to
> | the appropriate community and only on a need to know basis.
> This again is arguable. As we have discussed in the context speermint,
> a
> domain name should be resolvable in the public DNS (the domain's IPs
> may
> not be reachable by all though). So some provisioning data may be
> shared
> with everyone, it all depends on the peer network policies.
> 
> | CORE-REQ-003: It should be possible to provide the FQDN of the edge
> | proxies of the other community.
> Ok; this could be automated too (3263?).
> 
> (snip)
> 
> | CORE-REQ-006: It should be possible to provide the details of the
> | certificates that are expected by the other community.  I.e. common
> | name, certificate issuer and expiration.
> You clearly have some specific applications in mind with certain trust
> models between peer networks in support of them.
> 
> Etc.
> 
> In conclusion, I'm having a hard time understanding how these high-
> level
> and general requirements fit in and whether they can be met without
> providing more details on the applications and your assumptions.
> 
> Jean-Francois.
> 
> 
> 

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint