[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