[Speermint] Review of draft-houri-speermint-rtc-provisioning-reqs-00.txt

[Hannes Tschofenig <[e-mail]>]

Hi all,

I went through draft-houri-speermint-rtc-provisioning-reqs-00.txt and 
here are some high level comments:


* I was a bit lost with the proposed terminology. I am not so sure 
whether it is inline with the terms used in the terminology document.

Let us take a look at the following figure:

                                      +----+
                                      | LF |
                           -------    +----+     -------
                          /       \    |  |     /       \
                         |        LF---+  +---LF         |
                         |         |           |         |
                         |        PF-----------PF        |
                         |         |           |         |
                         |   SIP  SF-----------SF  SIP   |
                         | Service |           | Service |
                         |Provider MF---------MF Provider|
                         |    I    |           |    R    |
                         |         |           |         |
                         |         |           |         |
                          \       /             \       /
                           -------               -------

This figure is taken from the architecture document. When you talk about 
provisioning then I suspect you talk about the communication between the 
SF and the MF. Right?

Are you focused on
(a) the communication between the SF and the MF belonging to the same 
SIP Service Provider OR
(b) the communication between components interacting between Service 
Provider I and R from the figure above (e.g., the PF(I) and PF(R) 
talking to each other)?

* The requirements need to use RFC 2119 language and should to be 
motivated. Take a look at the ECRIT requirements draft to see what I 
mean. Here is the document:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-12.txt

For example, I don't understand the following requirement:

    CORE-REQ-003: It should be possible to provide the FQDN of the edge
    proxies of the other community.

What is the motivation for the requirement?

* CORE-REQ-004

    CORE-REQ-004: It should be possible to provide necessary details
    regarding firewall and NAT that will enable easier connection of
    other communities to the community

Are you talking about policies or the process of allowing the flow to go 
through the firewall/NAT? For example, you might want to trigger an 
interaction between the SF and the MF for this purpose.

If firewall traversal is in your scope why is QoS outside the scope. 
They are conceptually very similar: Some actions perform on a specific 
traffic pattern.

To make things a bit more complicated: Do you consider both path-coupled 
and path-decoupled NAT/Firewall (and eventually QoS) signaling?

* CORE-REQ-008

    CORE-REQ-008: It should be possible to provide the possible
    encryption methods that are expected by the community.

Encryption methods for securing signaling traffic I suspect. Let us 
assume that a key management like IKE(IKEv2) or the TLS handshake 
protocol is used. These protocol provide ciphersuite / algorithm 
negotiation. Would this meet your needs or do you have something else in 
mind?

* CORE-REQ-010

    CORE-REQ-010: It should be possible to provide the maximum number of
    allowed concurrent connection that are acceptable by the community.

What type of connection?

* Some requirements in Section 4 sound like "Please tell me what SIP 
extensions are implemented by a specific service provider."
Is my understanding correct?

* References have to be split into normative & informative requirements.
You only list RFC 2119 (although you do not use it); this would be a 
normative reference.

Note that the RFC 2119 language refers to the implementation of a 
protocol that will be later developed (I guess). The text in the 
security consideration section should also refer to the protocol that 
might be developed in the future. Hence, requirement CORE-REQ-002 fits 
very well in the security consideration section.


Ciao
Hannes

_______________________________________________
Speermint mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint