Media Control Channel Framework
draft-ietf-mediactrl-sip-control-framework-12

[Ballot comment]
Framework Transaction:  A Framework Transaction is defined as a
      sequence composed of a control framework message originated by
      either a Control Client or Control Server and responded to with a
      control Framework response code message.  Note that the control
      framework has no "provisional" responses.  A control framework
      transaction MUST complete within 5 seconds and is referenced

Why this value is hardcoded value? How did you decide on 5 seconds?

      throughout the draft as 'Transaction-Timeout'.


[The following was formerly a DISCUSS:]

1) In Section 4.1:

  The 'cfw-id' attribute MUST be globally unique over space and time
  (using an appropriate algorithm) and MUST NOT clash with instances of
  the 'cfw-id' used in other SIP offer/answer exchanges.

I think the text here (and in Section 4.2) would benefit from a description of some way to generate unique ids.

7)
13.1.1.  Control Package Registration Template

Who can change/update a registration?

Also, can an Independent Stream RFC replace definition in an IETF Stream RFC?

[Ballot discuss]
I think this document is in a good shape. Please find below some comments that I would like to discuss before recommending approval of this document:

7)
13.1.1.  Control Package Registration Template

Who can change/update a registration?

Also, can an Independent Stream RFC replace definition in an IETF Stream RFC?

[Ballot comment]
Framework Transaction:  A Framework Transaction is defined as a
      sequence composed of a control framework message originated by
      either a Control Client or Control Server and responded to with a
      control Framework response code message.  Note that the control
      framework has no "provisional" responses.  A control framework
      transaction MUST complete within 5 seconds and is referenced

Why this value is hardcoded value? How did you decide on 5 seconds?

      throughout the draft as 'Transaction-Timeout'.


[The following was formerly a DISCUSS:]

1) In Section 4.1:

  The 'cfw-id' attribute MUST be globally unique over space and time
  (using an appropriate algorithm) and MUST NOT clash with instances of
  the 'cfw-id' used in other SIP offer/answer exchanges.

I think the text here (and in Section 4.2) would benefit from a description of some way to generate unique ids.

[Ballot discuss]
I think this document is in a good shape. Please find below some comments that I would like to discuss before recommending approval of this document:

6)
13.1.  Control Packages Registration Information

  As this document specifies no package or template-package names, the
  initial IANA registration for control packages will be empty.  The
  remainder of the text in this section gives an example of the type of
  information to be maintained by the IANA; it also demonstrates all
  three possible permutations of package type, contact, and reference.

Why can a contact or a reference be optional in a registration?
Publishing as an RFC already requires them.

7)
13.1.1.  Control Package Registration Template

Who can change/update a registration?

Also, can an Independent Stream RFC replace definition in an IETF Stream RFC?

[Ballot comment]
Framework Transaction:  A Framework Transaction is defined as a
      sequence composed of a control framework message originated by
      either a Control Client or Control Server and responded to with a
      control Framework response code message.  Note that the control
      framework has no "provisional" responses.  A control framework
      transaction MUST complete within 5 seconds and is referenced

Why this value is hardcoded value? How did you decide on 5 seconds?

      throughout the draft as 'Transaction-Timeout'.

[Ballot discuss]
I think this document is in a good shape. Please find below some comments that I would like to discuss before recommending approval of this document:

1) In Section 4.1:

  The 'cfw-id' attribute MUST be globally unique over space and time
  (using an appropriate algorithm) and MUST NOT clash with instances of
  the 'cfw-id' used in other SIP offer/answer exchanges.

I think the text here (and in Section 4.2) would benefit from a description of some way to generate unique ids.

6)
13.1.  Control Packages Registration Information

  As this document specifies no package or template-package names, the
  initial IANA registration for control packages will be empty.  The
  remainder of the text in this section gives an example of the type of
  information to be maintained by the IANA; it also demonstrates all
  three possible permutations of package type, contact, and reference.

Why can a contact or a reference be optional in a registration?
Publishing as an RFC already requires them.

7)
13.1.1.  Control Package Registration Template

Who can change/update a registration?

[Ballot discuss]
Updated for revision -12. There is one issue that I did not see a text change for, and I also didn't receive email about it (I think).

Section 6.3.2., paragraph 1:

>    A 'REPORT' message is used by a Control Server when processing of a
>    CONTROL Command extends beyond the Transaction-Timeout, as measured
>    from the Client.

  DISCUSS: How does the server know how the client measures
  Transaction-Timeout, i.e., when the client started its
  Transaction-Timeout timer for the request? If the server starts its
  5-second timer when the request is received, it is pretty much
  guaranteed that the 202 will not be received by the client before its
  5-second timer fires (transmission delay).

[Ballot comment]
The document could benefit from a copy edit. For example:

1. The abstract is overly broad. The first sentence could describe dozens of different documents:

  This document describes a Framework and protocol for application
  deployment where the application programming logic and media
  processing are distributed.

Perhaps at least specifiy more fully the target applications?

2. Why is "Framework" capitalized (e.g., in the abstract)?

3. Some acronyms are not spelled out on first use in the document (e.g., SIP, RTP, SDP).

4. Section 2 refers to both BCP 14 and BCP 15 (!).

5. It's not a good idea to place conformance text in the terminology section ("A control framework transaction MUST complete within 5 seconds...").

6. Much of the overview is dedicated to justification of the protocol, often with marketing-style language "Generic protocol allows for easy extension", "The ability to select a Control Server based on Service level capabilities is extremely powerful when considering a distributed, clustered architecture", etc.). This text might have been useful during WG discussions but seems out of place in the finished document.

7. Some references are missing. For example, the Overview mentions "standard SIP third party call control" but does not refer to a specification for this standard on first mention. Similarly, Section 12.2 mentions IPsec but does not provide a reference.

8. Section 13.1 uses the term "RFC Editor submission" but RFC 5226 uses the term "RFC Editor Independent submission".

The document could also benefit from proofreading, but I have not provided a list of typographical and grammatical errors.

[Ballot discuss]
[DISCUSS #1 redacted based on discussion with Robert Sparks]

2. It is unclear what the allowable transports are. The text in Section 4.1 states:

  The third sub-field, , MUST equal a standard transport value.

However, no reference is made to an IANA registry or a definitive list of transports.

3. It is unclear how a party ensures the uniqueness of the 'cfw-id' attribute, as described here:

  The 'cfw-id' attribute MUST be globally unique over space and time
  (using an appropriate algorithm) and MUST NOT clash with instances of
  the 'cfw-id' used in other SIP offer/answer exchanges.

As one example, the 'cfw-id' might be a UUID as defined by RFC 4122.

In addition, it appears that the 'cfw-id' might be security-critical, as implied by Sections 6.1 and 12.1. Therefore a reference to RFC 4086 might be appropriate.

4. The Content-Length is described as "the size of the message body in decimal number of octets" (Section 6.1) but the ABNF defines it as:

  Content-Length = "Content-Length:" SP 1*DIGIT

A decimal number can be expressed to any number of places using digits to the right of the decimal point. Do you really mean that the size of the message body can be expressed in fractions (e.g., 131.43 octets), or only whole numbers?

5. Handling of the 'Seq' header is not clearly specified. The text in Section 6.3.2 states that the 'Seq' header MUST be incremented by 1, but does not state whether an entity receiving a message with a 'Seq' header that is more than 1 larger than the previous header value needs to return an error.

6. Does a Control Package name include the version number? Section 8.1 states:

  The package name MUST also register a
  version number for the package which is separated with a '/' symbol
  e.g. package_name/1.0.

This could be taken to mean that (1) "package_name/1.0" is the complete package name or (2) "package_name" is the mere package name and "1.0" is the package version number. The ABNF appears to imply (1) because it says:

  Packages = "Packages:" SP package-name *(COMMA package-name)
  package-name = alpha-num-token
  alpha-num-token = ALPHANUM  3*31alpha-num-tokent-char
  alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/"

This appears to allow "/" in the "mere package name". If so, how will software parse the complete package name to determine the package version number? Will it parse the complete package name from the end and split the name at the first "/" character it finds? Can the version number include a "/" character? The ABNF does not appear to disallow that.

7. The formal syntax does not state which fields are defined in RFC 5234.

8. The security considerations state the that framework "provides assurances that the connected host is the host that it meant to connect to and that the connection has not been hijacked" but does not cross-reference the specific sections of the document that explain these protections.

9. The section on "Control Channel Policy Management" does not provide enough information to judge whether any such mechanisms exist, whether control packages need to define these mechanisms or whether doing so is the responsibility of other extension documents, how it can be determined that access to resources and use of control channels relates to policy, etc. At the least, it would help implementers if this document could clarify when the 403 channel response code is used and how to handle such a response code (e.g., can the response include human-readable information that enables a client to assist a human user in figuring out to go about obtaining the appropriate permissions to complete the intended action?).

[Ballot comment]
INTRODUCTION, paragraph 15:
>    The motivation for the creation of this Framework is to provide an
>    interface suitable to meet the requirements of a distributed,
>    centralized conference system, as defined by the IETF.  It is not,
>    however, limited to this scope and it is envisioned that this generic
>    Framework will be used for a wide variety of de-coupled control
>    architectures between network entities.

  Claiming that this framework will be used for a variety of other
  control architectures between network entities is a pretty bold
  forward-looking statement, especially for an abstract. Suggest to
  remove.


Section 3., paragraph 13:
>    m=application 7575 TCP cfw

  Please use a dynamic port (> 49152) in this all examples.


Section 4.1., paragraph 12:
>      The Control Framework has an IANA-registered
>    recommended port defined in Section 13.5.  This value is not a
>    default as a client is free to choose explicit port numbers.
>    However, SDP SHOULD use the registered port number, unless local
>    policy prohibits its use.

  I fail to see why the to-be-registered port number isn't the default
  if it SHOULD be used?


Section 18.1., paragraph 10:
>    [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
>              Extensions (S/MIME) Version 3.1 Message Specification",
>              RFC 3851, July 2004.

  Obsolete normative reference: RFC 3851 (Obsoleted by RFC 5751)


Section 18.2., paragraph 2:
>    [I-D.ietf-sip-outbound]
>              Jennings, C., "Managing Client Initiated Connections in
>              the Session Initiation Protocol  (SIP)",
>              draft-ietf-sip-outbound-20 (work in progress), June 2009.

  Outdated reference: draft-ietf-sip-outbound has been published as RFC
  5626

[Ballot discuss]
>    Transaction-Timeout:  The maximum allowed time between a Control
>      Client or Server issuing a framework message and receiving a
>      corresponding response.  The value for 'Transaction-Timeout' is 5
>      seconds.

  DISCUSS: As I understand it, Transaction-Timeout has two meanings. For
  clients, it's the *minimum* amount of time they need to wait for the
  server to respond. For the server, it's the amount of time after which
  they should let the client know that processing will take longer. The
  mechanism as described isn't very robust. First, 5 seconds is not
  sufficiently larger than some Internet RTTs, which may cause spurious
  transaction failures even under normal operating conditions. Second,
  clients and servers use the same value, which means that if there is
  any delay spike or congestion along the path, a spurious transaction
  failures will occur.


Section 4.1., paragraph 11:
>    The second sub-field, , MUST represent a port on which the
>    constructing client can receive an incoming connection if required.
>    The port is used in combination with the address specified in the
>    'Connection Data line defined previously to supply connection
>    details.  If the constructing client can't receive incoming
>    connections it MUST still enter a valid port entry. The use of the
>    port value '0' has the same meaning as defined in a SIP Offer/Answer
>    exchange[RFC3264].

  DISCUSS: How can the server tell if the client can receive incoming
  connections on the specified port or not? Or do you mean to say that
  port '0' needs to be specified when the client can't receive incoming
  connections?


Section 6.3.2., paragraph 1:

>    A 'REPORT' message is used by a Control Server when processing of a
>    CONTROL Command extends beyond the Transaction-Timeout, as measured
>    from the Client.

  DISCUSS: How does the server know how the client measures
  Transaction-Timeout, i.e., when the client started its
  Transaction-Timeout timer for the request? If the server starts its
  5-second timer when the request is received, it is pretty much
  guaranteed that the 202 will not be received by the client before its
  5-second timer fires (transmission delay).

[Ballot comment]
In the Abstract:

"... suitable to meet the requirements of a distributed, centralized
conference system, as defined by the IETF."

This sentence about the scope of the document is confusing. It could
be rephrased so that it is clear that the document deals with
centralized conferences as defined in XCON (i.e., a central conference
server) where the central conference server is distributed.

Fix the following sentence in Section 4.2:

The Control Client entity then creates a to the Control Server, using
  B2BUA type functionality.

Also in Section 4.2, the reference to the 3pcc spec should appear the
first time 3pcc is mentioned.

In Section 10, the Content-Length in the SIP messages in the examples
could be easily calculated for completeness (e.g., it would be zero in
the BYE request and its response)

[Ballot discuss]
In Conventions and Terminology Section:

This section is not the right place to introduce a normative MUST
statement (in the definition of Framework Transactions).

In Section 4.1:

  The SDP being constructed MUST contain only a single occurrence of
  a control channel definition outlined in this specification.

Can the SDP contain other media lines if they are not control channels?

Also in Section 4.1:

  If the constructing client can't receive incoming
  connections it MUST still enter a valid port entry.  The use of the
  port value '0' has the same meaning as defined in a SIP Offer/Answer
  exchange[RFC3264]

Is this MUST defining new behavior or it is just describing what a
regular user agent following the offer/answer model would do?

Also in Section 4.1: given that the use of the registered port is at
the SHOULD level, why cannot it be considered the "default" value?

Also in Section 4.1, the text about reusing or establishing a new TCP
connection contains normative statements about behavior that is
already specified normatively in RFC 4145. The text can remain for
informational purposes but the normative statements could be removed.

[Ballot comment]
The document could benefit from a copy edit. For example:

1. The abstract is overly broad. The first sentence could describe dozens of different documents:

  This document describes a Framework and protocol for application
  deployment where the application programming logic and media
  processing are distributed.

Perhaps at least specifiy more fully the target applications?

2. Why is "Framework" capitalized (e.g., in the abstract)?

3. Some acronyms are not spelled out on first use in the document (e.g., SIP, RTP, SDP).

4. Section 2 refers to both BCP 14 and BCP 15 (!).

5. It's not a good idea to place conformance text in the terminology section ("A control framework transaction MUST complete within 5 seconds...").

6. Much of the overview is dedicated to justification of the protocol, often with marketing-style language "Generic protocol allows for easy extension", "The ability to select a Control Server based on Service level capabilities is extremely powerful when considering a distributed, clustered architecture", etc.). This text might have been useful during WG discussions but seems out of place in the finished document.

7. Some references are missing. For example, the Overview mentions "standard SIP third party call control" but does not refer to a specification for this standard on first mention. Similarly, Section 12.2 mentions IPsec but does not provide a reference.

8. Section 13.1 uses the term "RFC Editor submission" but RFC 5226 uses the term "RFC Editor Independent submission".

The document could also benefit from proofreading, but I have not provided a list of typographical and grammatical errors.

[Ballot discuss]
1. In the Overview and in Section 4.1, it is not clear how the client determines the IP address for connecting to the server. The information provided by the server is as follows in the Overview:

  c=IN IP4 mserver.example.com
  m=application 7563 TCP cfw

The Overview text states:

  The connection address (taken from 'c=') and port (taken from 'm=') are
  used to identify the remote port in the new connection.

And (in Section 4.1):

  The third sub-field for Connection Data is .  This
  supplies a representation of the SDP originators address, for example
  dns/IP representation.  The address is the address used for
  connections.

But the client needs to connect to an IP address and cannot directly make a TCP connection to a domain name or hostname. How does it resolve mserver.example.com to an IP address? Via A or AAAA lookup? If the document does not specify the client behavior then it will be impossible to build interoperable implementations.

Also, allowing a domain name or hostname in "c=" appears to be in conflict with Section 5.7 of RFC 4566, which allows only an IP address as the value of the  sub-field.

2. It is unclear what the allowable transports are. The text in Section 4.1 states:

  The third sub-field, , MUST equal a standard transport value.

However, no reference is made to an IANA registry or a definitive list of transports.

3. It is unclear how a party ensures the uniqueness of the 'cfw-id' attribute, as described here:

  The 'cfw-id' attribute MUST be globally unique over space and time
  (using an appropriate algorithm) and MUST NOT clash with instances of
  the 'cfw-id' used in other SIP offer/answer exchanges.

As one example, the 'cfw-id' might be a UUID as defined by RFC 4122.

In addition, it appears that the 'cfw-id' might be security-critical, as implied by Sections 6.1 and 12.1. Therefore a reference to RFC 4086 might be appropriate.

4. The Content-Length is described as "the size of the message body in decimal number of octets" (Section 6.1) but the ABNF defines it as:

  Content-Length = "Content-Length:" SP 1*DIGIT

A decimal number can be expressed to any number of places using digits to the right of the decimal point. Do you really mean that the size of the message body can be expressed in fractions (e.g., 131.43 octets), or only whole numbers?

5. Handling of the 'Seq' header is not clearly specified. The text in Section 6.3.2 states that the 'Seq' header MUST be incremented by 1, but does not state whether an entity receiving a message with a 'Seq' header that is more than 1 larger than the previous header value needs to return an error.

6. Does a Control Package name include the version number? Section 8.1 states:

  The package name MUST also register a
  version number for the package which is separated with a '/' symbol
  e.g. package_name/1.0.

This could be taken to mean that (1) "package_name/1.0" is the complete package name or (2) "package_name" is the mere package name and "1.0" is the package version number. The ABNF appears to imply (1) because it says:

  Packages = "Packages:" SP package-name *(COMMA package-name)
  package-name = alpha-num-token
  alpha-num-token = ALPHANUM  3*31alpha-num-tokent-char
  alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/"

This appears to allow "/" in the "mere package name". If so, how will software parse the complete package name to determine the package version number? Will it parse the complete package name from the end and split the name at the first "/" character it finds? Can the version number include a "/" character? The ABNF does not appear to disallow that.

7. The formal syntax does not state which fields are defined in RFC 5234.

8. The security considerations state the that framework "provides assurances that the connected host is the host that it meant to connect to and that the connection has not been hijacked" but does not cross-reference the specific sections of the document that explain these protections.

9. The section on "Control Channel Policy Management" does not provide enough information to judge whether any such mechanisms exist, whether control packages need to define these mechanisms or whether doing so is the responsibility of other extension documents, how it can be determined that access to resources and use of control channels relates to policy, etc. At the least, it would help implementers if this document could clarify when the 403 channel response code is used and how to handle such a response code (e.g., can the response include human-readable information that enables a client to assist a human user in figuring out to go about obtaining the appropriate permissions to complete the intended action?).

[Ballot comment]
Framework Transaction:  A Framework Transaction is defined as a
      sequence composed of a control framework message originated by
      either a Control Client or Control Server and responded to with a
      control Framework response code message.  Note that the control
      framework has no "provisional" responses.  A control framework
      transaction MUST complete within 5 seconds and is referenced

Why this value is hardcoded value? How did you decide on 5 seconds?

      throughout the draft as 'Transaction-Timeout'.


In Section 3:

  The link (2) from Figure 2 represents the User Agent SIP INVITE
  dialog usage interactions and associated media flow.  A User Agent
  creates a SIP INVITE dialog usage with the Control Client entity.
  The Control Client entity then creates a to the Control Server,

A word is missing before "to the Control ..."

  using
  B2BUA type functionality.  Using the interaction illustrated by (2),
  the Control Client negotiates media capabilities with the Control
  Server, on behalf of the User Agent, using SIP Third Party Call
  Control [RFC3725].


13.3.  Control Framework Status Codes

  The following information MUST be provided in an RFC publication in
  order to register a new Control Framework status code:

  o  The status code number.
  o  The RFC number in which the method is registered.

No Description field in the registration template?

13.10.  MIME Media Type Registration for 'application/
        framework-attributes+xml'

    Optional parameters: Same as charset parameter

parameter *of*

        application/xml as
        specified in RFC 3023.

[Ballot discuss]
I think this document is in a good shape. Please find below some comments that I would like to discuss before recommending approval of this document:

1) In Section 4.1:

  The 'cfw-id' attribute MUST be globally unique over space and time
  (using an appropriate algorithm) and MUST NOT clash with instances of
  the 'cfw-id' used in other SIP offer/answer exchanges.

I think the text here (and in Section 4.2) would benefit from a description of some way to generate unique ids.

2) In Section 9:

  control-resp-start = pCFW SP trans-id SP status-code [SP comment] CRLF
  comment = utf8text

If comment is intended to be human readable, then it must include a language tag as per BCP 18.
See  for some examples of how to address that.

3) In Section 9:

  Content-Type = "Content-Type:" SP media-type
  media-type = type "/" subtype *( ";" gen-param )

(Comment) I note that there is no SP before gen-param. Is this intentional?

  type = token
  subtype = token

I think you should reference "type-name" and "subtype-name" from Section 4.2 of RFC 4288 when defining media-type.

4) In:
12.2.  Transport Level Protection

Saying "just use TLS" for server authentication is not sufficient.
So text about TLS server identity verification procedure is missing.
See  for more details on this and for examples showing what can be specified here.

5)
12.3.  Control Channel Policy Management

  It can be determined that access to resources and use of control
  channels relates to policy.  It can be considered implementation and
  deployment detail that dictates the level of policy that is adopted.
  The authorization and associated policy of a control channel can be
  linked to the authentication mechanisms described in this section.
  For example, strictly authenticating a control channel either using
  SIP digest or TLS authentication allows entities to protect resources

I am confused about how this is relevant in this case.
Can you please show an example of how a control channel can be authenticated using SIP digest?

  and ensure the required level of granularity.

6)
13.1.  Control Packages Registration Information

  As this document specifies no package or template-package names, the
  initial IANA registration for control packages will be empty.  The
  remainder of the text in this section gives an example of the type of
  information to be maintained by the IANA; it also demonstrates all
  three possible permutations of package type, contact, and reference.

Why can a contact or a reference be optional in a registration?
Publishing as an RFC already requires them.

  The table below lists the control packages defined in the "Media
  Control Channel Framework".

    Package Name      Contact                  Reference
    ------------      -------                  ---------
    example1          [contact@example.org]
    example2          [contact@example.org]    [RFCXXXX]
    example3                                  [RFCXXXX]

7)
13.1.1.  Control Package Registration Template

DISCUSS DISCUSS (lightweight DISCUSS): Who can change/update a registration?

8)
In Section 9:

  UTF8-NONASCII = %xC0-DF UTF8-CONT
                / %xE0-EF 2UTF8-CONT
                / %xF0-F7 3UTF8-CONT
                / %xF8-FB 4UTF8-CONT
                / %xFC-FD 5UTF8-CONT

This is very different from RFC 3629, in particular RFC 3629 doesn't allow for 5/6 octet sequences. Why is the difference?
I suggest you just reference ABNF from RFC 3629 directly.

  UTF8-CONT    = %x80-BF

9)
13.6.1.  Registration of MIME Media Type application/cfw

      Encoding considerations: See section 4 of RFC XXXX

This is not quite compliant with Section 4.8 of RFC 4288.
Please add some text specifying if this field is 7bit/8bit/binary/framed.


Also, the following information is missing from the registration template:
        Additional Information:  Magic Number(s):
        File extension(s):
        Macintosh File Type Code(s):

IANA has seven questions about the IANA Actions required upon approval
of this document.

Upon approval of this document, IANA understands that it must complete
nine separate actions in order to meet the requirements of the
document. In summary, IANA understands that four new subregistries are
to be created under the new SIP Control Framework parameters registry,
a port number is to be allocated from the 'User Registered' range, 2
MIME types are to be registered, an SDP attribute is to be assigned, a
URN Sub-Namespace is to be registered, and a XML Schema is to be
registered.

Specifically, IANA understands the following actions will be required
upon approval of the document:

-> IANA will create a new registry called SIP Control Framework
Parameters. IANA understands that this will be a registry that only
contains subregistries and does not contain any parameters or
registrations of its own.

IANA QUESTION:
Should this registry be located in the existing, general SIP parameters
registry located at http://www.iana.org/assignments/sip-parameters, or
should it be an entirely new, separate registry? Once this registry is
created, IANA understands that four new sub-registries will be
contained within it.

-> Once the SIP Control Framework Parameters registry is created, IANA
will create within it a completely new sub-registry called Control
Packages. There are no initial registrations in the Control Packages
sub-registry. Any future registrations for this registry are to be done
using the RFC 5226 "RFC Required" rules. IANA notes that the document,
when approved, provides a template for future requests for Control
Package registration. IANA also notes that a sample of what the
sub-registry should look like is provided in Section 13.1.

IANA QUESTION: the sample registry shows a line without an RFC
reference under the column "reference." Is this possible if any Control
Package registration requires a full RFC.

-> Once the SIP Control Framework Parameters registry is created, IANA
will create within it a completely new sub-registry called Control
Framework Method Names. There are four initial registrations in the
Control Framework Method Names sub-registry. Any future registrations
for this registry are to be done using the RFC 5226 "RFC Required"
rules. The four initial registrations in this sub-registry are:

Method Name Reference
----------- ---------
CONTROL - [RFCtbd]
REPORT - [RFCtbd]
SYNC - [RFCtbd]
K-ALIVE - [RFCtbd]

-> Once the SIP Control Framework Parameters registry is created, IANA
will create within it a completely new sub-registry called Control
Framework Status Codes. Any future registrations for this registry are
to be done using the RFC 5226 "RFC Required" rules. Reading the
document, it appears that the status codes being registered are the
three-digit codes defined in Section 7 of the document. IANA finds no
status codes defined in Section 9 of the document.

IANA QUESTION: do the authors intend that the three digit response
codes documented in Section 7 of the document form the initial
registrations for the Control Framework Status Codes sub-registry?

-> Once the SIP Control Framework Parameters registry is created, IANA
will create within it a completely new sub-registry called Control
Framework Header Fields. There are ten initial registrations in the
Control Framework Header Fields sub-registry. Any future registrations
for this registry are to be done using the RFC 5226 "RFC Required"
rules. The ten initial registrations in this sub-registry are:

Header Field Name Reference
----------------- ---------
Control-Package [RFCtbd]
Status [RFCtbd]
Seq [RFCtbd]
Timeout [RFCtbd]
Dialog-ID [RFCtbd]
Packages [RFCtbd]
Supported [RFCtbd]
Keep-Alive [RFCtbd]
Content-Type [RFCtbd]
Content-Length [RFCtbd]

-> Upon approval of this document, IANA will register an available port
number from the User Registered range.

IANA QUESTION: what should be the port name and short port name for
this port? Are both TCP and UDP port registrations required?

-> Upon approval of this document, IANA will register two MIME Media
types. The two MIME media types will be:

application/cfw

and

application/framework-attributes+xml

These will be registered in the registry located at
http://www.iana.org/assignments/media-types/application/ using the
details provided in Sections 13.6.1 and 13.10 of the document
respectively.

-> Upon approval of the document IANA is directed to register a SDP
Attribute: 'cfw-id'

IANA QUESTION: It is not clear to IANA what part of the SDP
parameters registry located at
http://www.iana.org/assignments/sdp-parameters this attribute is to be
registered. To what registry in
the SDP parameters registry should 'cfw-id' be assigned?

-> Upon approval of this document, IANA will register a new URN
sub-namespace in the registry located at http://www.iana.org/assignments
/xml-registry/ns.html. The URI being registered is
"urn:ietf:params:xml:ns:control:framework-attributes"

IANA QUESTION: What are the id and registration Template values to be
used with this registration?

-> Upon approval of this document, IANA will register a new XML schema
in the registry located at http://www.iana.org/assignments/xml-registry
/schema.html. The XML for the schema is provided in section 16 of the
approved document.

IANA QUESTION: what should the id and filename be for this registration?

IANA understands that these are the only actions required for IANA
completion upon approval of the document.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Eric Burger is the document shepherd. I have personally reviewed this
version of the document, and it is ready for forwarding to the IESG
for publication.

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

The document has had reviews by key WG members as well as RAI expert
review.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

None.

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

None.

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

Strong consensus for publishing.

(1.f) 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
entered into the ID Tracker.)

None.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Checked with ID nits 2.11.05. One warning is the document uses
readable 2119 boilerplate instead of the passive voice drivel most
documents use. We prefer readability, but editors can do what editors
must if the RFC Editor does not like it.

(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

We do have normative and informative references. All normative
references are published and there are no down-refs.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes. The ABNF has a nit: please remove the second definition of
UPALPHA in Section 9.1

(1.k) 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 document describes a Framework and protocol for application
deployment where the application programming logic and media
processing are distributed. This implies that application
programming logic can seamlessly gain access to appropriate
resources
that are not co-located on the same physical network entity. The
framework uses the Session Initiation Protocol (SIP) to establish an
application-level control mechanism between application servers and
associated external servers such as media servers.

Working Group Summary
Nothing out of the ordinary happened in the WG to note.

Document Quality
This document has sufficient normative statements and examples for one
to create an implementation. There are at least four, independent
implementations of the protocols and framework described by this
document.