Architectural Considerations for Providing Carrier Class Telephony Services Utilizing Session Initiation Protocol SIP-based Distributed Call Control Mechanisms
draft-dcsgroup-sipping-arch-01
Discuss
Yes
(Jon Peterson)
No Objection
(Allison Mankin)
(Cullen Jennings)
(David Kessens)
(Magnus Westerlund)
(Margaret Cullen)
(Scott Hollenbeck)
Abstain
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Bert Wijnen Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-08-19)
Unknown
The IPR statement is not one that we normally use There is no IANA Considerations section
Russ Housley Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-08-18)
Unknown
The Introduction says: > > The authors have submitted this document to the IETF in order to > provide general information regarding the DCS architecture and to > convey the motivation behind the SIP enhancements recommended in the > accompanying protocol drafts. We believe that providing SIP > extensions for the concepts and mechanisms described in this set of > drafts will significantly enhance SIP's ability to function as a > carrier-class signaling protocol. > Two things concern me. First, this is not the publication of a working group, so I would rather it say something like: "The authors have written this document in order to ..." Second, it is unclear what "accompanying protocol drafts" are being references. I would prefer something like: "... convey the motivation for SIP enhancements recommended to the IETF by the authors," dropping the rest of the text. The Introduction also says that comments from SIP and SIPPING were incorporated in the document. Yet, this is not a working group document. Clearly, there is not consensus for this document in those working groups. Theretofore, the reference to review is misleading to the reader. Please delete it. Acknowledging specific contributions is more appropriate.
Jon Peterson Former IESG member
Yes
Yes
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2004-08-19)
Unknown
Reviewed by Lucy Lynch, Gen-ART
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
(was Discuss)
Abstain
Abstain
(2005-10-19)
Unknown
I still think the note below should be addressed, but I will move to abstain for the document, in order to help things move forward: The companion piece to this, PKT-SP-DCS-D03-000428, available at: ftp://ftp.cablelabs.com/pub/pkt-sp-dcs-d03-000428.pdf makes clear that one of the reasons that this architecture is proposed (contrary to then end-to-end design of SIP, as Allison notes) is to enable intercept by law enforcement. See page 62, 3.3.10 DCS-LAES and DCS-REDIRECT. I believe that this means we should be clear in the title that this is "Packet Cable Labs' Distributed Call Control Architecture and Mechanisms" and that Allison's eventual note should incorporate some of the language used for Baker-slem. To be clear, I don't object to our publishing documents which reference lawful intercept and the mechanisms for it, but I do think we need to be consistent in labelling them.