Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture
draft-ietf-speermint-architecture-19
Yes
(Gonzalo Camarillo)
No Objection
(Dan Romascanu)
(Jari Arkko)
(Lars Eggert)
(Ron Bonica)
(Stewart Bryant)
(Tim Polk)
Note: This ballot was opened for revision 19 and is now closed.
Gonzalo Camarillo Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2011-02-02)
Unknown
You will need to remove the citation from the Abstract. --- You will find it worth your while to shake up your ADs to find out why [I-D.ietf-speermint-requirements] is stuck. --- There is a minor alignment problem with the lines indicating the edges of the networks in Figure 1. --- Section 3 The originating or indirect SSP would likely perform steps 1-4, the target SSP would likely perform steps 4, and either one is likely to perform step 5. I found this a little vague. Who else could perform these steps? --- 4. Relationships Between Functions/Elements I didn't like this section :-( You have functions and functional elements with the same name. And you appear to also have implementation components with overlapping names. All in all, you appear to be observing that functions are performed by functional elements, and that functional elements can be implemented in different places according to implementation choices. --- 5.1.2.2. Routing Table There is nothing wrong with the text in this section, but it does not mention the "routing table" at all, and that seems odd.
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2011-01-31)
Unknown
Deep in section 2 (on page 5) the document notes "An SSP may also be referred to as an Internet Telephony Service Provider (ITSP). While the terms ITSP and SSP are frequently used interchangeably, this document and other subsequent SIP peering-related documents should use the term SSP". Please consider moving, or copying that to the first paragraph of the introduction.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2011-02-03)
Unknown
Please consider the comments from the Gen-ART Review by Avshalom Houri on 2-FEB-2011: Line 357: o An SBE can contain a SF function. -> o An SBE can contain an SF function. Line 421: Function (LUF) to determine a target address, and then is resolves -> Function (LUF) to determine a target address, and then it resolves Line 466: resolving these URIs to URIs for specific protocols such a SIP or -> resolving these URIs to URIs for specific protocols such as SIP or Line 485: particular order and, importantly, not all of them may be used. -> particular order and, importantly, not all of them have to be used. Line 537: SIP proxy. Optionally, a SF may perform additional functions such as -> SIP proxy. Optionally, an SF may perform additional functions such as Line 540: encryption. The SF of a SBE can also process SDP payloads for media -> encryption. The SF of an SBE can also process SDP payloads for media Line 582: The section defines uses of TLS between two SSPs [RFC5246] [RFC5746] -> The section defines the usage of TLS between two SSPs [RFC5246] [RFC5746]
Sean Turner Former IESG member
No Objection
No Objection
(2011-02-03)
Unknown
- In Section 4, the term "Session Border Controller" is not defined in RFC5486 or this document - it seems like a definition should be included. - In Section 4, the first three bullet points would have "function function" if the acronyms were spelled out - this might be okay but some people view it as incorrect. - In the fourth bullet of Section 4, it's not clear what "can communicate" means - is this a restrictive statement, does it mean that only the left-most function can initiate an exchange or something else altogether. It seems like a clarification is in order. - In Section 5.1.2.2, the term "carrier-of-record" is used. The term is not defined or used elsewhere and seems to be important to the proper functioning of the procedure. A clarification would seem to be in order. - In Section 5.1.3.2, IPSec is mentioned in the originating procedures. There is no corresponding mention in the target procedures section which seems to be an omission that should be corrected. - In Section 9, I'm not following the following senetence: In order to maintain a consistent approach, unique and specialized security requirements common for the majority of peering relationships, should be standardized within the IETF. Are you trying to say: The IETF should standardize unique and specialized security requirements common for the majority of peering relationships?
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was Discuss, No Record, No Objection)
No Objection
No Objection
(2011-02-21)
Unknown