A User Agent Profile Data Set for Media Policy
draft-camarillo-rai-media-policy-dataset-04

[Ballot discuss]
This discuss & comment probably looks worse than it is.
I'd hope it'll all be easily sorted.

(1) cleared

(2) 4.1, Why MUST a UA include the remote-host-port in all
session-info documents? That seems a bit privacy unfriendly to
say the least. I can see that it might be needed sometimes, but
why all the time, and why can't the UA just not tell the policy
server who its calling?  (Same comment about elsewhere where the
same information is a MUST.)

(3) cleared

[Ballot comment]
All DISCUSSes and substantive comments were taken care of in version -03; thanks.

========
Other comments; no need to respond to these.  Really, I'm just grumbling.

I have to grumble about the shepherd writeup for this:

  The document, in particular the registration of the media type/subtype
  media-policy-dataset+xml, has been reviewed on the ietf-types mailing list.

It has not "been reviewed" there at all.  A request for review was posted, and there were no responses.  That's not a bad thing, but it should have been explained that way, not presented as a review.

I also have to grumble about the IANA Considerations section, which does not clearly specify what registries it's asking for things to be put into.  IANA figured it out, so I'm not asking for any changes here.  Just for future: please be clear about this, so IANA never has to guess (and will not, therefore, ever guess wrong).

[Ballot discuss]
Hmm so under what circumstances would I not wan the protocol used to distribute session info and session policy doucments to not ensure authentication, privacy, and message integrity?

Is the gist of the must for shared-secret that you consider that to be the only item that MUST be kept private?  Not user id too?

[Ballot comment]
s3.3: Says the recipient MUST ignore the attribute.  Is the recipient the user agent or the user? I suspect it's the former - shouldn't it say that instead?

s3.3.1: Is there an override on this?  I'm thinking I'm with Stephen here.  An additional reason is that normally display stuff (my technical term) is out-of-scope - isn't it?

s4.2: optional is redundant: r/MAY contain the optional/MAY contain the

[Ballot comment]
Section 4.3.1:

  The  element MUST contain one  element, one or
  more  elements and one  element.  The
    element MAY contain one  element.

That last MAY strikes me as ambiguous. Did you mean MUST contain zero or one  elements?

Section 4.4:

  Multiple  elements MAY only be present in a
  container if each applies to a different set of streams (e.g., one
    element for incoming and one for outgoing
  streams).
 
Another ambiguous MAY. Instead can I suggest:
 
  Multiple  elements MUST NOT be present in a
  container unless each applies to a different set of streams (e.g.,
  one  element for incoming and one for
  outgoing streams).
 
See also 5.3, 5.4, 5.6. "MAY only" is a bad construct.

Section 6.7.5:

  The use of this token is described in the Framework for SIP
  Session Policies [I-D.ietf-sip-session-policy-framework].  Since the
  token value must be encodable as a SIP URI parameter value, it MUST
  consist of ASCII characters, that is, in the range U+0020 to U+007E.

Either strike ", that is, ", or change "ASCII characters" to "visible ASCII characters plus space". And you do want to allow space? And not TAB? And not other things that can be %encoded? I'm not clear on the requirement here. For the record, "token" is not defined this way in 3261. Just looking for clarification.

[Ballot discuss]

This discuss & comment probably looks worse than it is.
I'd hope it'll all be easily sorted.

(1) 3.3.1, visibility attribute says if UA is "permitted" to
show the user stuff - yuk! Shouldn't that be the UA developer's
choice? I'd say s/permitted/advised/ would be fine. I think the
"SHOULD NOT display" here is just inappropriate as its nothing
to do with interoperability and is just silly, since people will
make tools to show that stuff if you try hide it. (I realise
that my suggested change conflicts with Barry's suggestion for
fixing the issue in his comment, but I think the way to fix the
problem we've both identified is to get rid of the pretence that
you can hide stuff you send the UA.)

(2) 4.1, Why MUST a UA include the remote-host-port in all
session-info documents? That seems a bit privacy unfriendly to
say the least. I can see that it might be needed sometimes, but
why all the time, and why can't the UA just not tell the policy
server who its calling?  (Same comment about elsewhere where the
same information is a MUST.)

(3) I think section 9 (or somewhere else, I don't care) needs to
call out when TLS is needed, that is, when TLS MUST be used and
how. (I'm only asking about TLS since S/MIME usage here is
apparently mythical.) In particular, I think you need to say
when a UA MUST authenticate a policy server or source of policy
information, and how it can check that its getting the right
policy from the right source or giving stuff to the right
server.  I think sending out remote host/port information and
accepting intermediary information in particular would seem to
call for use of TLS with server-authentication, though there may
be additional cases too.  I would imagine that you'd need to
check that the policy-server element (if present) matches the
TLS server cert somehow. If the policy-server is absent, or when
a UA is sending sensitive information, then I don't know how
you'd know you're giving/getting the right policy info.
Finally, do merge operations need a web-origin like concept?
Without that, it'd seem like anywhere I visit might be able to
corrupt my UA's "policy state" (to invent a term that might be
missing.)

Sorry to lump a few different things together in point (3); I
suspect that we'll tease them apart in the discussion, but I'm
not sure right now how to do that properly.

[Ballot comment]

- 3.3.3: What is the allowed precision for the 'q' attribute?
Does a UA have to be able to properly handle
0.0000000000000000000000000000000000000000001?

- 3.3.4: Is the 'media-type' attribute restricted to the top
level types?  If so, maybe say so. (From later, it appears to be
just the top level type.)

- 3.3.4: Would 'media-type' == "multipart" or "application" or
"message" make sense? If not, maybe say so. If so, what'd those
mean? What if a new top level type is finally defined?  What is
a UA supposed to to with that?

- 3.3.6: Does the MUST NOT for the value "no" need a bit more
context? E.g. "MUST NOT establish the media stream when this
policy is relevant" or something? Is there a danger that a UA
might otherwise remember this setting for too long, e.g. if it
roams?

- 5.1, What is the logical AND of media-intermediaries? I don't
get that. (Or can it happen? Maybe I got confused here:-)

- 5.7, Why call out the "visibility" attribute here? Trying to
keep allowed-ports secret (if that's the goal) this way would be
silly - anyone can probe.

- 6.3, Is 1 "kilobit per second" 1024 bits per second? Might be
worth saying so explicitly in case higher speeds cause
confusion, e.g. "mega bit" might be taken as 1024kbps or
1,000,000bps.

- 6.3, Why bother try hiding the max-bw? The only real effect I
could see would be an increase in the number of conspiracy
theories;-)

- The last two comments also apply for 6.4 & 6.5.

- 6.7.1, Is this for anything other than debug? If so, what?
(Its not stated, and brings up questions in my little head about
authenticating policy servers.)

- 6.7.4, can a request-URI element contain PII? If so, how would
that be protected?

- 7.1, the policy-server URI has no scheme. What's up there?
(The webfinger discussion on apps-discuss and the acct: URI
scheme proposed might be of use here?)

- Section 9, maybe s/privacy/confidentiality/ in 1st para, since
I think that's what you mean.

- Section 9: section 4.1 calls for mandatory inclusion of the
local & remote host/port and perhaps creates a new attack - try
get a UA to send me session-info documents to see who they're
talking to?  I think that'd warrant a mention here to tell UA
developers to be cautious in sending out such private
information. (And here I do mean privacy-sensitive and not
requiring confidentiality:-)

- Section 9, Section 4.4's media intermediaries also seems to
increase the attack surface. Doesn't that warrant a mention?
Maybe say that UAs need to be cautious here in accepting
instructions about which intermediaries to use?

[Ballot discuss]
[Update: I neglected to take into account the new media-types procedures document we just approved.  The media-type registration request has been done correctly, and IESG approval of this RFC is adequate to have IANA make the registration.  My apology for this erroneous part of the DISCUSS, which point is now cleared.]

-- Section 3.3.4 --
  The value of the 'media-type' attribute MUST
  be the media type, such as 'audio', 'video', 'text', or
  'application'.

It looks like this value is meant to be one of the registered top-level media types in the Media Types Registry, yes?  If so, please say that.  As it is, it seems underspecified: you give four examples, but I might be allowed to put "font" in there, which we've batted around as a possible new top-level media type that doesn't yet exist... I'm not sure.

I think it's unlikely that you want to allow unregistered top-level types.

Maybe this?:
NEW
  The value of the 'media-type' attribute is the media type of
  the stream, and MUST be a (top-level) Media Type that is
  registered in the Media Types IANA registry.  Examples are
  'audio', 'video', 'text', and 'application'.

This also applies to the  element.

For the  element, you say this:
-- Section 6.2.1 --
  The  element contains a media type and subtype
  that identifies a codec.  The value of this element MUST be a media
  type and subtype [RFC4855] separated by a "/" (e.g., audio/PCMA,
  audio/G726-16 [RFC4856] or video/H263 [RFC4629]).

By using the RFC4855 citation, are you really saying this?:
NEW
  The  element contains a media type and subtype
  that identifies a codec.  The value of this element MUST be a media
  type and subtype that is registered as an RTP Payload Type [RFC4855],
  separated by a "/" (e.g., audio/PCMA, audio/G726-16 [RFC4856] or
  video/H263 [RFC4629]).

(Of course, you might want to allow for unregistered subtypes, so I'm not sure exactly what you want.  What I am sure about is that the document needs to be clear about where these primarily come from, and when it's appropriate to stray.)

[Ballot discuss]
It doesn't appear that you've properly requested the media-type registration you're asking for in Section 10.1.  You posted a "preliminary review" message to ietf-types (which garnered no feedback, alas), but that's not the formal request.  To do that, go to http://www.iana.org/cgi-bin/mediatypes.pl and fill out the form.  Based on IANA's question, it seems that hasn't been done -- they will initiate the expert review in response to that.  I'll hold this DISCUSS as a reminder for that to happen.

-- Section 3.3.4 --
  The value of the 'media-type' attribute MUST
  be the media type, such as 'audio', 'video', 'text', or
  'application'.

It looks like this value is meant to be one of the registered top-level media types in the Media Types Registry, yes?  If so, please say that.  As it is, it seems underspecified: you give four examples, but I might be allowed to put "font" in there, which we've batted around as a possible new top-level media type that doesn't yet exist... I'm not sure.

I think it's unlikely that you want to allow unregistered top-level types.

Maybe this?:
NEW
  The value of the 'media-type' attribute is the media type of
  the stream, and MUST be a (top-level) Media Type that is
  registered in the Media Types IANA registry.  Examples are
  'audio', 'video', 'text', and 'application'.

This also applies to the  element.

For the  element, you say this:
-- Section 6.2.1 --
  The  element contains a media type and subtype
  that identifies a codec.  The value of this element MUST be a media
  type and subtype [RFC4855] separated by a "/" (e.g., audio/PCMA,
  audio/G726-16 [RFC4856] or video/H263 [RFC4629]).

By using the RFC4855 citation, are you really saying this?:
NEW
  The  element contains a media type and subtype
  that identifies a codec.  The value of this element MUST be a media
  type and subtype that is registered as an RTP Payload Type [RFC4855],
  separated by a "/" (e.g., audio/PCMA, audio/G726-16 [RFC4856] or
  video/H263 [RFC4629]).

(Of course, you might want to allow for unregistered subtypes, so I'm not sure exactly what you want.  What I am sure about is that the document needs to be clear about where these primarily come from, and when it's appropriate to stray.)

[Ballot comment]
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- Section 3.3.1 --
      hidden: Specifies that the user agent SHOULD NOT display the
      property value.

SHOULD NOT, really?  If an administrator wants to hide this, she can't rely on its being hidden?  Why isn't this MUST NOT?  Or maybe what you want is this, to go with the subsequent sentence?:
NEW
      hidden: Specifies that the user agent MUST NOT display the
      property value to ordinary users.

========
Other comments; no need to respond to these.  Really, I'm just grumbling.

I have to grumble about the shepherd writeup for this:

  The document, in particular the registration of the media type/subtype
  media-policy-dataset+xml, has been reviewed on the ietf-types mailing list.

It has not "been reviewed" there at all.  A request for review was posted, and there were no responses.  That's not a bad thing, but it should have been explained that way, not presented as a review.

I also have to grumble about the IANA Considerations section, which does not clearly specify what registries it's asking for things to be put into.  IANA figured it out, so I'm not asking for any changes here.  Just for future: please be clear about this, so IANA never has to guess (and will not, therefore, ever guess wrong).

IANA has reviewed draft-camarillo-rai-media-policy-dataset-01 and has the following comments:

IANA has questions about the IANA actions requested in this document.

IANA understands that there are three actions which IANA must complete upon approval of this document.

- First, in the application media types registry located at:

http://www.iana.org/assignments/media-types/application/index.html

a new application media type will be registered as follows:

application/media-policy-dataset+xml [ RFC-to-be ]

IANA question -> registrations in the application media type registry require
Expert Review. Has this request been through Expert Review for this registry?

- Second, in the XML schema registry located at:

http://www.iana.org/assignments/xml-registry/schema.html

a new registration will be added as follows:

ID: mediadataset
URI: urn:ietf:params:xml:schema:mediadataset
Filename: [ content-from-Section-8-of-RFC-to-be ]
Reference: [ RFC-to-be ]

- Third, in the XML namespace registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new registration will be added as follows:

ID: mediadataset
URI: urn:ietf:params:xml:ns:mediadataset
Registration template: [ content-from-Section-10.3-of-RFC-to-be ]
Reference: [ RFC-to-be ]

IANA understands that these three actions are the only ones required upon approval of this document.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (A User Agent Profile Data Set for Media Policy) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'A User Agent Profile Data Set for Media Policy'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification defines an XML document format to describe the
  media properties of Session Initiation Protocol (SIP) sessions.
  Examples for media properties are the codecs or media types used in
  the session.  This document also defines an XML document format to
  describe policies that limit the media properties of SIP sessions.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-camarillo-rai-media-policy-dataset/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-camarillo-rai-media-policy-dataset/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO questionnaire for: draft-camarillo-rai-media-policy-dataset-00.txt

To be Published as: Proposed Standard

Prepared by: Mary Barnes (mary.barnes@polycom.com) on 23 April, 2012

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
  The RFC is a Proposed Standard, as indicated on the title page header.
  This document defines an XML schema and rules for such, thus it is
  appropriate as a standards track document. 
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This specification defines an XML document format to describe the
  media properties of Session Initiation Protocol (SIP) sessions.
  Examples for media properties are the codecs or media types used in
  the session.  This document also defines an XML document format to
  describe policies that limit the media properties of SIP sessions.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  This document is being progressed as an AD sponsored document. 
  It was initially developed in the SIPPING WG, as
  draft-ietf-sipping-media-policy-dataset. However, the SIPPING WG
  is now closed.  While in the SIPPING WG, there was no controversy
  in particular with regards to the document and there were no
  issues with regards to consensus for the document. 


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  This document is of interest to 3GPP.  It is one of a set of
  documents that were being progressed in the SIP and SIPPING WGs t
  define profiles for configuration data.  Earlier versions of the
  document were thoroughly reviewed in the WG.  The media type review
  was requested on Feb. 22, 2012.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Mary Barnes is the document Shepherd.  Robert Sparks is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
  The document shepherd has thoroughly reviewed this document.
 
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 
  No.  The document was thoroughly reviewed by SIPPING WG members
  during its development.
 
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
  The Relax NG schema has been reviewed by Jari Urpalainen.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
  The document shepherd has no specific concerns nor issues with this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
  Not as far as I am aware.

(9) 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?

  Note, this document is being progressed after the closure of the SIPPING WG.
  While the document was under development in the WG, there was WG consensus. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  This document has been checked using idnits 2.12.13 and no nits have
  been identified.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document, in particular the registration of the media type/subtype
  media-policy-dataset+xml, has been reviewed on the ietf-types mailing list. 

(13) Have all references within this document been identified as
either normative or informative?

  Yes, the normative and informative references have been identified.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

    No.  draft-ietf-sipping-policy-package is a normative reference, but it
    is already in the RFC Editor's queue.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.
    No.

(16) Will publication of this document change the status of any
existing RFCs?
    This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

    The IANA considerations section is consistent with the body of
    the document.  This document appropriately registers the XML schema
    and new namespace.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
    None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
    Jari Urpalainen has reviewed the XML schema and the schema was also
    validated using XSV.