Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-bliss-call-completion-18

From: <[email-masked]>
Date: Fri, 4 Jan 2013 13:04:39 +0100

Hi Salvatore,

thanks for checking the draft.

Issue 'how is the m parameter provided': will be changed accordingly.

Issue 'security considerations for no reply / not logged in indication': information about these states are conveyed indirectly by accepting SUBSCRIBEs or CC INVITEs with this purpose, but only in the latter use case this really allows conclusions on the current state of the callee.
Even though it is mentioned in the first bullet in the list in section 11that there should be a temporal relation between selection for CC and the CC call, I agree it would be good to clarify the besides information on busy/not busy also information on what causes busy/not busy is revealed, and to clarify that these 2 aspects have the same security implications.

Thanks for your support.

Regards, Martin

________________________________
Von: Salvatore Loreto [mailto:[email-masked]]
Gesendet: Mittwoch, 26. Dezember 2012 18:19
An: [email-masked]; [email-masked]; The IESG
Betreff: APPSDIR review of draft-ietf-bliss-call-completion-18

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:   draft-bonica-special-purpose-04
Title: Call Completion for Session Initiation Protocol (SIP)
Reviewer:  Salvatore Loreto
Review Date:  Dec 26th 2012

Summary:

This draft is ready for publication.

Major Issues:

none.

Minor Issues:

(1)
Section 4.1, in the second to last paragraph

   In a more restricted system, this determination can depend
   on the mode of the CC call in question, which is provided by the 'm'
   parameter.

It would be better specify what 'm' parameter you are referring, I guess it is the URI 'm' parameter so   s/which is provided by the 'm' parameter/which is provided by the URI 'm' parameter (2) Section 11. Security considerations. The information is confined to a busy/not-busy indication, and in legitimate use, will be subscribed to stereotyped ways that limit the disclosure of status information:

that is not completely true, as it can also convey indications about 'No Reply' or 'Not Logged-in'. The sections does not say anything if there are different security implications related to those two different indications.  Nits: none Best Regards,

--
Salvatore Loreto, PhD
www.sloreto.com<http://www.sloreto.com>