Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services
draft-ietf-sipping-uri-services-07

[Ballot comment]
>  recipients as the ones specified by the client).  To prevent this
>  attack, clients SHOULD integrity protect URI lists using mechanisms
>  such as S/MIME, which can also provide URI-list confidentiality if
>  needed.

Given I've never seen S/MIME deploy outside limited enclaves, I question
if this mitigation will actually deploy on Internet scale.  Can you
suggest an alternative mitigation option that may not be as strong as
S/MIME, but might actually be deployable (e.g., hop-to-hop TLS/DTLS,
leap-of-faith keying similar to SSH, etc)?

I find it both misleading and distasteful to use "SHOULD" when it's
something that's likely to remain unimplemented or rarely deployed.

I do not view this issue as a barrier to proposed status, but it would
be a barrier to future advancement so it might be better to be realistic
now.

>            recipient-list    the body contains a list of URIs

This is unclear and misleading for a "disposition".  A disposition
should describe how the content is used, while the media type should
describe what's in the content.  This should be easy to fix.

I suggest instead
            recipient-list    process as URI list

A more verbose description would be:

The "recipient-list" disposition results in a conversion of the body's
content-type to an abstract list of URIs which are then processed by the
service.

[Ballot discuss]
Section 3.1., paragraph 2:
>    REQ 2:  The invocation mechanism SHOULD NOT require more than one RTT
>      (Round-Trip Time).

  Discuss-discuss: I'm not sure if I fully understand this requirement.
  Is this trying to express that an invocation operation on a URI-list
  should execute in less than some time duration? If so, this seems to
  be extremely dependent on a lot of external conditions. Also, since
  the time duration is defined as a round-trip time, the round-trip time
  between which two nodes in the network is meant here?


Section 8.1., paragraph 4:
>    [I-D.ietf-sipping-consent-framework]
>              Rosenberg, J., "A Framework for Consent-Based
>              Communications in the Session Initiation  Protocol (SIP)",
>              draft-ietf-sipping-consent-framework-05 (work in
>              progress), June 2006.

  Discuss: This is a DOWNREF, but easily fixed by citing the
  standards-track draft-ietf-sip-consent-framework instead of the older
  SIPPING draft.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
addition in "MAIL CONTENT DISPOSITION Values and Parameters"
registry located at
http://www.iana.org/assignments/mail-cont-disp
sub-registry "Mail Content Disposition Values"

Name + Description + Reference
----- + ------------ + ---------
recipient-list + the body contains a list of URIs + [RFC-ietf-sipping-uri-services-07.txt]

We understand the above to be the only IANA Action for this
document.

IANA Last Call Comment:

IANA has a question about the IANA Actions required upon
approval of this document.

Upon approval, this document requires a single action from
IANA. In the Mail Content Disposition Values and Parameters
registry located at:

http://www.iana.org/assignments/mail-cont-disp

the IANA will register a new value:

recipient-list the body contains a list of URIs

However, in this registry there are three subregistries:

- Mail Content Disposition Values
- Mail Content Disposition Parameters
- Mail Content Disposition Parameter Values

In which of these registries should the new recipient-list
value be added?

removing from agenda so that it can be on agenda with its
normative reference the consent-framework, which it turns
out is close to ready.  (Also need to check about a downref LC -
revisit target status of framework)

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the
Internet Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?

Yes. The draft was reviewed by chairs Rohan Mahy and Dean Willis, and
was primarily authored by chair Gonzalo Camarillo.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has been well-reviewed by key WG members and has been
"socialized" inside IETF and external SDOs including OMA. There may
be an external review requirement for the registration of a new
Content-Disposition value in the IANA mail-cont-disp registry.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

I expect there to be a significant interest in the security aspects
of this document, although I believe the presentation here is
adequate. This draft relates to the consent-framework draft, which
generated an extensive discussion with AD Sam Hartman on the security
aspects.

1.d) Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

I have no unresolved concerns with this document beyond its
inadequate abstract. A replacement abstract is provided in an
Instruction below.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document seems to have strong concurrence from the subset of the
working group that cares. Although not unamimous, this is a fairly
significant subset of the working group.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.

I am unaware of any such concerns.

1.g) Have the chairs verified that the document adheres to all of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

The current draft passes idnits 1.85. It contains no XML or ABNF that
requires verification. The IANA considerations are minimal and appear
to be adequately described. No additional issues were noted in a
visual inspection.

1.h) Is the document split into normative and informative
references? Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear
state? (note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until
all such IDs are also ready for publication as RFCs.)

The references are properly defined and all normative references are
to published RFCs.


Instruction on Abstract: Replace the abstract with the text of the
Technical Summary.

Technical Summary:

Traditional SIP requests are sent to a single recipient indicated by
the Request URI. Conferencing and other scenarios raised a need to
send a single request to multiple recipients. This document provides
a general methodology, including security considerations, for sending
a SIP request to multiple recipients by including a list of
recipients (URI-list) in the request and targeting the Request URI to
an intermediate service node that will process the list and generate
a singular request for each recipient. This document defines a new
value of the Content-Disposition header used to invoke URI-list
processing on the intermediate service node. It is expected that
future standards-track documents will define the usage of URI list
services with each SIP request type.

Working Group Summary:

This work has progressed fairly steadily in the SIPPING working
group, and is part of larger set of documents including the Consent
framework and mechanism and specific URI-list services definitions
for MESSAGE, INVITE, and REFER requests. While there was initially
substantial angst in the working group over the fundamental
requirements of a consent-based (opt-in, as opposed to opt-out)
model, the framework represented by this document has not been
particularly contentious.


Protocol Quality:

No implementations of this specification are known to exist. However,
the Open Mobile Alliance is in the process of developing systems
specifications that exercise URI-list services for conferencing with
INVITE and REFER requests. The details of these services are defined
in other drafts, but to the extent that this draft applies, OMA has
not reported any difficulties with this specification.