Basic Network Media Services with SIP
draft-burger-sipping-netann-11

Sent to IANA as part of message about announcement:

To:      iesg@ietf.org
cc:      iana@iana.org, eburger@brooktrout.com
From:    Allison Mankin
Subject: Approve: draft-burger-sipping-netann-11.txt

Reply-To: mankin@psg.com

[iesg-secretary bcc'd]

IESG Secretary,

Please announce draft-burger-sipping-netann-11.txt.

The RFC Editor Notes present in the writeup are correct. 

Allison

-------

No action for iesg-secretary:
I draw to the IANA's attention that there is an IANA Note
in the writeup/announcement.  This is for the
SIP/SIPS URI Parameters Registry (RFC 3969) - we wrote to
IANA/IESG about this 12 April 2005.  The writeup provides the
parameters to be added to the registry for IANA, in the
registry format.

Allison

netann caused realization of misunderstanding on SIP URI parameters.
But thought is to write a guideline draft on pitfalls since there are risks
with over-using them (as netann does cover)

The IANA action is not done - IANA actions are on a long queue, but change
should be public

To:     
cc:      , ,
        , ,
Subject: RE: An error not* by you: please correct the IANA matrix on SIP uri
          parameters

Ack.  Allison, I'll take care of this and let Gonzalo know if I have any
questions.

Thank you,

Michelle


- -----Original Message-----
From: Allison Mankin [mailto:mankin@psg.com]
Sent: Tuesday, April 12, 2005 7:33 PM
To: iana@iana.org
Cc: jon.peterson@neustar.biz; gonzalo.camarillo@ericsson.com;
rohan@cisco.com; dean.willis@softarmor.com; iesg@ietf.org
Subject: An error not* by you: please correct the IANA matrix on SIP uri
parameters

Dear IANA,

During the collective work on RFC 3969 -

3969 The Internet Assigned Number Authority (IANA) Uniform Resource
    Identifier (URI) Parameter Registry for the Session Initiation
    Protocol (SIP). G. Camarillo. December 2004.

we (ADs, Editor, Chairs) allowed two IANA registration policies to wind up
in the final version, both Specification Required and that it be a
"standards track RFC" (Section 4.2).  But in fact, the working group
consensus was for Specification Required, and there was careful analysis of
the reasoning for this.  Therefore, IANA, please modify the information
shown on http://www.iana.org/numbers.html to state Specification Required.
This will restore the intention of the working group.  I'll separately file
an erratum with the RFC Editor.

If you have any questions about this, please let Gonzalo or me know and
we'll answer quickly!

Allison

P.S. an Informational draft registering new SIP URI parameters is about to
be

draft-burger-sipping-netann

Discussed the SIP uri parameter issue with SIPPING chairs - they asked to restore the SIP consensus
that Specification Required was enough for registering, because parameters are widely used,
dropped easily, have low threshold.  I suggest they write a guideline on the issues against
doing all forms of SIP extension using these.  Is it part of the sip architecture document or
standalone?  I send mail to iana to fix the matrix back to Specification Required since that's what
the uri parameters document says.  This makes netann releasable.

[Note]: 'Expert -Reviewed by SIPPING WG; eventual decision was that it should not be chartered (there was not yet readiness to go to consensus on work like this) but should advance as an independent individual Info  - its details were sound from SIP viewpoint.  An Apps AD should look at its use of country code and language tags for localization...' added by Amy Vezza

[Ballot discuss]
I'm afraid this looks deeply broken.  Re-using the user section of the URI in
order to accomplish this work is contrary to my reading of Sections 1.1 and
3.2.1 of 2396bis and my understanding of its predecessors.  There are many
other smaller problems.  For example, cifs is mentioned as a URI scheme but
is not yet registered--see http://www.iana.org/assignments/uri-scheme).
The document suggests using two different userinfo parts while its engaged
in this overloading; if we did go forward overloading userinfo, that wouldn't make much
sense.

This is not ready to publish.  I would suggest a round of discussion in the uri@w3.org
mailing list and a second pass from the resulting discussion to sipping.  If it does
go forward after that review, I *strongly* urge the ADs to consider publication as
experimental, with encouragement to document the usage in the field.  If sipping
is ever going to consider folding this work into the core of SIP that would be very
useful.

[Ballot discuss]
I'm afraid this looks deeply broken.  Re-using the user section of the URI in
order to accomplish this work is contrary to my reading of Sections 1.1 and
3.2.1 of 2396bis and my understanding of its predecessors.  There are many
other smaller problems.  For example, cifs is mentioned as a URI scheme but
is not yet registered--see http://www.iana.org/assignments/uri-scheme).
The document suggests using two different userinfo parts while its engaged
in this overloading; if we did go forward overloading userinfo, that wouldn't make much
sense.

[Ballot discuss]
This document needs more review -- there seemed to be many arbitrary and controversial design choices.  Working group processing would, I think, help.

What is the exact syntax and semantics for a locale_ parameter?  Which comes first?  Can the country be omitted?  Should a user whose UA is provisioned for us_en see us_sp or uk_en if there's no exact match?

The "dialog" discussion seems incomplete -- there are very many ways to conduct dialogs, but nothing is specified.  Should dialogs be required to be secure?  Some mention should be made in the security considerations section.

I'm not sure what you mean about "exposing" control interfaces for conferences, but regardless of whether or not they're exposed, they need to be protected by real security mechanisms.  The same, of course, is true for joining a conference, but the examples don't even use sips: to achieve security.

nit: 5.1 doesn't use example.net

The /provision stuff seems like an end-run against the decision not to have a provision: URI.

7: nit: the word is "deprecated", not "depreciated"

The discussion about using local proxies to avoid security seems misplaced.  If there's an attack being perpetrated -- and that depends very heavily on the authorization model of the SIP providers -- it would seem to be up to the far end of the call to enforce any policies.  After all, my proxy is serving my interests, and has no knowledge of what is permissible or impermissible according to someone else's network.  (If that's not what you mean, I'd love to see clearer text.)

Any individual service needs its own security analysis.  The current section deals mostly with the announcement service.  It completely ignores the dialog service and the conference service described here.  Nor does it say what security services -- confidentiality, integrity, etc. -- are required at any point.

[Ballot discuss]
This document needs more review -- there seemed to be many arbitrary and controversial design choices.  Working group processing would, I think, help.

What is the exact syntax and semantics for a locale_ parameter?  Which comes first?  Can the country be omitted?  Should a user whose UA is provisioned for us_en see us_sp or uk_en if there's no exact match?

The "dialog" discussion seems incomplete -- there are very many ways to conduct dialogs, but nothing is specified.  Should dialogs be required to be secure?  Some mention should be made in the security considerations section.

I'm not sure what you mean about "exposing" control interfaces for conferences, but regardless of whether or not they're exposed, they need to be protected by real security mechanisms.  The same, of course, is true for joining a conference, but the examples don't even use sips: to achieve security.

nit: 5.1 doesn't use example.net

7: nit: the word is "deprecated", not "depreciated"

The discussion about using local proxies to avoid security seems misplaced.  If there's an attack being perpetrated -- and that depends very heavily on the authorization model of the SIP providers -- it would seem to be up to the far end of the call to enforce any policies.  After all, my proxy is serving my interests, and has no knowledge of what is permissible or impermissible according to someone else's network.  (If that's not what you mean, I'd love to see clearer text.)

Any individual service needs its own security analysis.  The current section deals mostly with the announcement service.  It completely ignores the dialog service and the conference service described here.  Nor does it say what security services -- confidentiality, integrity, etc. -- are required at any point.

[Note]: 'Expert -Reviewed by SIPPING WG; eventual decision was that it should not be chartered (there was not yet readiness to go to consensus on work like this) but should advance as an independent individual Info  - its details were sound from SIP viewpoint.  An Apps AD should look at its use of country code and language tags for localization...' added by Allison Mankin

[Note]: 'Expert -Reviewed by SIPPING WG; eventual decision was that it should not be chartered (there was not yet readiness to go to consensus on work like this) but should advance as an independent individual - its details were sound from SIP viewpoint.  An Apps AD should look at its use of country code and language tags for localization...' added by Allison Mankin

[Note]: 'Expert -Reviewed by SIPPING WG; eventual decision was that it should not be chartered (there was not yet readiness to go to consensus on work like this) but should advance as an independent individual - its details were sound from SIP viewpoint.  An Apps AD should look at its use of country code and language tags for localization...' added by Allison Mankin

This received Expert Review from the SIPPING WG, though it was not a chartered work item.  The reason was that it bordered on chartered work, and the many discussion of whether it should be chartered, led to an eventual decision to do a careful review of the draft and make a recommendation for or against individual publication - the recommendation by the WG was in favor.