Architectural Considerations for Providing Carrier Class Telephony Services Utilizing Session Initiation Protocol SIP-based Distributed Call Control Mechanisms
draft-dcsgroup-sipping-arch-01

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot discuss]
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.

[Note]: 'Will propose an IESG note modelled like the RFC Editor disclaimer, though it''s not an RFC Ed document...even though the SIP folks in times past reviewed it, it differs from the end-to-end design of SIP. ' added by Allison Mankin

[Note]: 'Will propose an IESG note modelled like the RFC Editor disclaimer, though it''s not an RFC Ed document...even though the SIP folks in times past reviewed it, it differs from the end-to-end design of SIP. ' added by Allison Mankin