Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture
RFC 6406

Note: This ballot was opened for revision 19 and is now closed.

(Gonzalo Camarillo) Yes

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

Comment (2011-02-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Russ Housley) No Objection

Comment (2011-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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]

(Tim Polk) (was Discuss, No Record, No Objection) No Objection

(Dan Romascanu) (was Discuss) No Objection

(Robert Sparks) No Objection

Comment (2011-01-31 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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. 

(Sean Turner) No Objection

Comment (2011-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
- 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?