Subject: [Sipping] WGLC Review: draft-ietf-sipping-capacity-attribute-01.txt

From: "Mary Barnes" <[email-masked]>
Date: Tue, 19 Sep 2006 15:15:48 -0500

Draft:  draft-ietf-sipping-capacity-attribute-01.txt
Reviewer: Mary Barnes
Review Date: 19 Sept 2006
Review Deadline: 19 Sept 2006
Status: WGLC

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication and there's a couple questions
for clarification.

Question for clarification:
----------------------------
1.  Why do you need both the bcc and the cc with the anonymize
attribute?  It seems that the bcc is more anonymous than the cc with the
anonymize attribute (in my mind a bcc is an anonymous cc, but I'm not an
email expert).  If there is a distinct reason, it should be clarified in
the document, likely around the same place in the text that you'll be
clarifying the purpose of the extension in general, as suggested by
Brian Rosen. 

2.  Section 9.  A new SIP option-tag is mentioned in the first
paragraph, but none is defined in this doc.  Is that a typo?

General Comments:
------------------
- Agree with the list discussion on changing the usage of the term
"capacity" to "copyControl". 

Editorial nits:
----------------
- Section 3, 3rd paragraph, 1st sentence. Either add an "and" before
"excludes" or change "excludes" to "excluding".
OLD:
    When the URI-list server expands the request for each recipient, it
   includes a new URI-list that contains only the targets originally
   listed in the "to" and "cc" capacities, excludes those listed in the
   'bcc' capacity. 
NEW:
   When the URI-list server expands the request for each recipient, it
   includes a new URI-list that contains only the targets originally
   listed in the "to" and "cc" capacities and excludes those listed in
the
   'bcc' capacity.  

- Section 3, 4th paragraph, last sentence.  Change "include" to "add" OR

"to any" to "with any"
OLD:
   It is not expected to have
   value other than with anonymous URIs, although technically, it is
   possible to include the 'count' attribute to any URI.
NEW:
   It is not expected to have
   value other than with anonymous URIs, although technically, it is
   possible to add the 'count' attribute to any URI.

- Section 4, 2nd paragraph, 2nd sentence.  Add "to" before "anonymize".
OLD:
   If set to a "true" value, it
   provides an indication to the URI-list server for not disclosing the
   URI itself in a URI-list sent to the recipient, but instead,
   anonymize the URI. 
NEW: 
   If set to a "true" value, it
   provides an indication to the URI-list server for not disclosing the
   URI itself in a URI-list sent to the recipient, but instead,
   to anonymize the URI. 

- Section 4, 4th paragraph, 3rd sentence.  "duplicated" -> "duplicate"

- Section 6, 1st paragraph after Figure 3, 1st sentence.  "reception" ->
"receipt"

- Section 7, 3rd paragraph. Current wording is awkward and it might be
better to reword the 1st sentence and add an Otherwise clause associated
with the SHOULD to emphasize the point.  So, I'm proposing a change
something like the following:
OLD:
   It is often desired that, if the intended recipient of the SIP
   request does not support this specification, still the SIP request
   does not fail.  In order to provide the maximum probability of
   success of those requests that include 'recipient-list-history'
   bodies, User Agents (such as URI-list services) that build SIP
   requests with the Content-Disposition header field set to 'recipient-
   list-history' SHOULD add a 'handling' parameter [4] set to
   "optional".
NEW:
   If the intended recipient of the SIP
   request does not support this specification, 
   the SIP request SHOULD NOT fail. 
   In order to ensure successful receipt of the SIP 
   requests that include 'recipient-list-history'
   bodies, User Agents (such as URI-list services) that build SIP
   requests with the Content-Disposition header field set to 'recipient-
   list-history' SHOULD add a 'handling' parameter [4] set to
   "optional".  Otherwise, the SIP request MAY fail and not be received
by 
   the intended recipient. 

- Section 8, 2nd paragraph, 1st sentence. "hand" -> "send"

- Section 8, 3rd paragraph, 3rd sentence. "was" -> "is"
OLD:
   Eavesdroppers are able to watch URI-lists contained in SIP
   requests unless the SIP message was sent over a secured channel with
   Transport Layer Security (TLS) [3] or unless the URI-list body itself
   is encrypted with S/MIME [8]. 
NEW:
   Eavesdroppers are able to watch URI-lists contained in SIP
   requests unless the SIP message is sent over a secured channel with
   Transport Layer Security (TLS) [3] or unless the URI-list body itself
   is encrypted with S/MIME [8]. 

Section 11.2 
- Rferences 10 and 11 need updating since those docs moved to SIP.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 20 Sep 2006 13:27:55 -0500

Hi,

What is the reason for not considering IPSEC tunnels in the text? DTLS
is still open issue. So better open-ended text can be phrased like

"... was sent over a secured channel provided by the underlying layers
e.g.
TLS, IPSEC ...."

How long we want to carry S/MIME with it's deploy ability issues. If
still we want to use S/MIME atleast known issues with it should be
listed similar to 3261. Or reference to section of 3261 should be given.

IMHO, SIP message means REQUEST and RESPONSE both. So the text should be
well aligned like ".... SIP request unless the SIP request ..." or with
the "message" word. 

Thx
Samir

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 20 Sep 2006 13:28:03 +0300

Hi Mary.

Inline answers to your questions and comments.

> Question for clarification:

I agree that the difference between bcc and anonymize is subtle. Let's 
see if we agree on the the semantics, and then I will write a similar 
clarification in the draft.

If the sender qualifies a URI as 'bcc', the URI-list server will remove 
that URI from the list that goes attached to the request to each of the 
recipients. The recipient will not notice that one or more extra URIs 
received the request.

If the sender qualifies a URI as 'anonymize', the URI-list server will 
replace the URI by an anonymous one. The recipient will notice that 
there have been one or more extra recipients of the same request, but 
their URIs haven't been disclosed.

I think I will add some lines around the above ones clarifying the 
difference.

> paragraph, but none is defined in this doc.  Is that a typo?

Of course, that is a copy-paste typo. There is no option tag defined by 
this document.

> General Comments:

Done in my working copy.

> Editorial nits:

I will fix the editorial nits as suggested.

BR,

        Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 21 Sep 2006 13:30:04 +0300

I think the spirit of the text is not to exclude any technology. In 
essence, any technology that is able to cypher SIP messages is suitable 
to protect privacy. We should probably  mention TLS as an example of one 
of such technologies.

/Miguel

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 21 Sep 2006 14:57:48 -0500

Hi Miguel,

My concerns were driven by the dynamic nature of cipher technologies.
And we have the problems coming from others as SIPS is mentioned as
*statically* for the security at numerous places.

IMHO, we should have boiler-plate kind of stuff in the security section
which takes into the account the security provided by underlying secure
protocol layers generically.

And then each specification addresses other security aspects for in
particular to that specification in the separate paragraph in the
Security Considerations.

Hopefully, it addresses the concerns of SIPS proponents in future.

Thx
Samir

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]]
> Sent: Thursday, September 21, 2006 3:30 AM
> To: Srivastava, Samir (SC100:8826)
> Cc: Barnes, Mary (RICH2:B601); [email-masked];
> [email-masked]
> Subject: Re: [Sipping] WGLC Review:
draft-ietf-sipping-capacity-attribute-
> 01.txt

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 22 Sep 2006 08:56:44 +0300

Hi,

recommending S/MIME and SIPS has been the standard practice in all the 
drafts SIPPING has been producing in a long time. I do not think this 
draft is the place to discuss the relationship between TLS, IPsec, VPNs, 
etc. I believe such relationship must be tackled by the SIP 
specification and its updates.

Cheers,

Gonzalo

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Sep 2006 10:07:10 -0500

> specification and its updates.

Right, but it needs to be written in some way like "using message 
privacy mechanisms such as TLS or S/MIME," rather than the current text, 
which appears to limit the solution space to TLS and S/MIME.

--
dean

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 22 Sep 2006 18:08:38 +0300

Agreed.

Gonzalo

Dean Willis wrote:
>> draft is the place to discuss the relationship between TLS, IPsec, 
>> VPNs, etc. I believe such relationship must be tackled by the SIP