High-Level Requirements for Tightly Coupled SIP Conferencing
RFC 4245

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

(Allison Mankin) Yes

(Brian Carpenter) No Objection

Comment (2005-05-12)
No email
send info
  + The draft talks about the author's "feelings" about what should be
    included in future documents.  I assume these feelings are actually
    WG consensus at this point and so I think this could be reworded a
    bit to add some credibility to the statements.

  + In 3.1 REQ-2 "AOR" is used without definition.

  + It might be nice if the requirements were numbered absolutely and
    not relatively.  E.g., in 3.2 the first requirement would be REQ-6.
    This is just really for ease and preciseness of reference since then
    there would not be a zillion REQ-1s.

(from review by Mark Allman)

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

Comment (2005-05-12)
No email
send info
Point for discussion:

The document says:

  The media graph of a SIP conference can be centralized,
  de-centralized, or any combination of both and potentially differ per
  media type.  In centralized case, the media sessions are established
  between the focus and each one of the participants.  In
  de-centralized (i.e.  distributed) case, the media graph is a
  (multicast or multi-unicast) mesh among the participants.
  Consequently, the media processing (e.g.  mixing) can be performed
  either by the focus alone or by the participants.

Is there an implicit requirement that there must be a procedure
to transition from a centralized to a decentralized model during
the conference (or change the mix, since it can be a combination)?

I can easily see the answer being "yes", "no, too expensive", 
"possibly, depends on the cost of this feature compared to other
things in protocol selection" or "dealt with by a later document",
but I am curious about whether the authors/wg see this as
a design constraint.

(Russ Housley) No Objection

Comment (2005-05-09)
No email
send info
  In section 2: s/direct peer-wise relationships/direct peer relationships/

  Please spell out the first use of the AOR acronym.

  Please include references for "digest authentication" and "certificates"
  in the security considerations section.

(David Kessens) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

Comment (2005-05-12)
No email
send info
THis document uses RFC2119 terminology (MUST and such) and indeed
does include a normative refrence to RFC2119, but there is no
citation to it anywhere in the text.