IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-04-08. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Amy
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
Telechat:
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
3.3.2 Returning Items
1211 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
Telechat:
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
1218 EDT back
1223 EDT back
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1348 EDT into Executive Session
(at 2010-04-08 08:30:17 PDT)
draft-ietf-mediactrl-sip-control-framework
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.
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)
> 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, <port>, 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).
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
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
<http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues> 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
<http://tools.ietf.org/html/draft-saintandre-tls-server-id-check> 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):
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.
I support Alexey's discuss issue #4 and Gonzalo's issues #3 and 8.
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 <connection-address>. 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
<connection-address> sub-field.
2. It is unclear what the allowable transports are. The text in Section 4.1
states:
The third sub-field, <proto>, 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?).
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.
Please see my GEN-ART review comments on 3/16 (http://www.ietf.org/mail- archive/web/gen-art/current/msg05149.html).
draft-ietf-mediactrl-ivr-control-package
The document mentions the need for a standards-track RFC. It would be
better to define such policy by referring to the terms defined in RFC
5226. In this case, standards action.
At the beginning of the Introduction, There are two capitalized terms in the text: "Media Control Channel Framework" and "Control Framework". Stating whether the terms are equivalent would be useful. Make sure all acronyms are expanded on their first use (e.g., DTMF).
I think the document is in a pretty good shape despite the length of my
comments.
Below are some blocking comments that need to be discussed and possibly
addressed before I can recommend approval of this document:
1) In Section 4:
The MS MUST
support one or more schemes using communication protocols suitable
for fetching resources (e.g. HTTP).
I don't think this is good enough for interoperability. You should specify a
mandatory to implement protocol for fetching resources.
I suggest you mandate
use of HTTP and HTTPS. (The latter is important for providing data
confidentiality)
The same issue is relevant in section 4.3.1.4 - a mandatory to implement
protocol for recording data.
2) Use of authentication information in URIs in the "src" attribute (in multiple
sectons):
E.g. in Section 4.2.1:
src: specifies the location of an external dialog document to
prepare. A valid value is a URI (see Section 4.6.9) including
authentication information if defined by the URI scheme (e.g.
basic access authentication in HTTP).
Is this supposed to include the password as well?
If yes, how can this be represented in URIs?
If not, where is this information coming from?
3) Multiple typos in XML examples (I haven' checked all, but spotted some
problems):
4.2.2.1:
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart dialogid="d3" connectionid="connection1">
<dialog>
<prompt>
<media loc="http://www.example.com/getpin.wav"/>
</prompt>
<control ffkey="2" rewkey="3"/>
I think "rewkey" should be "rwkey"
</dialog>
<subscribe>
<dmtfsub matchmode="control"/>
</subscribe>
</dialogstart>
</mscivr>
4.3.1.1.3:
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="c1">
<dialog>
<prompt>
<par>
<media type="audio/x-wav"
loc="http://www.example.com/media/comments.wav"/>
<media type="video/3gpp;codecs='s263'"
loc="http://www.example.com/media/camera.3gp"/
Missing ">".
</par>
</prompt>
</dialog>
</dialogstart>
</mscivr>
4.3.1.1.3.1:
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="c1">
<dialog>
<prompt>
<par endsync="first">
<seq>
<media type="audio/x-wav"
loc="http://www.example.com/media/date.wav"/>
<media type="audio/x-wav"
loc="http://www.example.com/media/intro.wav"/>
<media type="audio/x-wav"
loc="http://www.example.com/media/main.wav"/>
<media type="audio/x-wav"
loc="http://www.example.com/media/end.wav"/>
</seq>
<media type="video/3gpp;codecs='s263'"
loc="rtsp://www.example.com/media/camera.3gp"/
Missing ">"
</par>
</prompt>
</dialog>
</dialogstart>
</mscivr>
4) In 4.2.2.2:
The <stream> element has the following attributes:
media: a string indicating the type of media associated with the
stream. The following values MUST be used for common types of
media: "audio" for audio media, and "video" for video media. The
attribute is mandatory.
Is there a registry (or at least a full list) of valid names?
Or did you mean "MIME type"?
5) In 12.2.2:
format This property is optional. If defined, the value of the
property is an array. Each array element is an object which
specifies information about one format of the media stream. The
object contains at least one property called name whose value is
the subtype of the media format ([RFC4855]).
Here you say subtype, but your example later in the same section shows:
In this case, session.connection.protocol.sip.media[0].type evaluates
to "audio", session.connection.protocol.sip.media[0].direction to
"recvonly" (i.e. the endpoint only receives media from the dialog -
the endpoint does not send media to the dialog), and
session.connection.protocol.sip.media[0].format[0].name evaluates to
"audio/PCMU" and
I.e. I think this should be "PCMU", or you need to correct the definition above.
session.connection.protocol.sip.media[0].format[0].rate evaluates to
"8000".
6) In Section 12.4:
| <exit | <params> <param |
| expr="userAuthorized"> | name="__reason">exit</param> <param |
| | name="__exit">true</param> </params> |
This doesn't seem to match your definition of how "expr" is converted to
<params>
7) In 4.2.6.1:
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="d6"/>
<dialogexit status="1">
<params>
<param name="mode">recording</param>
<param name="recording1" type="audio/x-wav">
<![CDATA[
R0lGODlhZABqALMAAFrMYr/BvlKOVJKOg2xZUKmenMfDw8tgWJpV
]]>
You have a problem here, as your data is base-64 encoded, yet you don't specify
anywhere in the payload that that is being the case. And there is no text saying
when this is implied for particular MIME types.
So I think this is missing information about Content-Transfer-Encoding.
It looks
like Content-Transfer-Encoding (pick your attribute name) needs to be another
attribute to "param".
</param>
</params>
</dialogexit>
</event>
</mscivr>
8) In 4.6.10:
A string formated as a IANA MIME media type ([MIME.mediatypes]).
Firstly, I think this should also point to exact ABNF for this.
It is also not
clear if Content-type parameters are allowed in this field. Some of your uses of
this type imply so, while other don't.
For MIME type/subtype ABNF, please reference Section 4.2 of RFC 4288.
I would
also encourage you to specify proper ABNF for this production (and to reference
"type-name" and "subtype-name" from Section 4.2 of RFC 4288)
9) In 4.3.1.4:
append: indicates whether recorded data is appended or not to a
recording location if a resource already exists. A valid value is
a boolean (see Section 4.6.1). A value of true indicates that
recorded data is appended to the existing resource at a recording
location. A value of false indicates that recorded data is to
overwrite the existing resource. The attribute is optional. The
default value is false.
How is append/overwrite mapped to underlying protocol being used?
In particular, I think this is underspecified in case of HTTP.
10) In 12:
This section and its subsections are using RFC 2119 language, so they
look normative for somebody who chooses to implement VoiceXML as a dialog
language. This in its turn means that some of the following references:
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[VXML20] McGlashan, S., Burnett, D., Carter, J., Danielsen, P.,
Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K.,
and S. Tryphonas, "Voice Extensible Markup Language
(VoiceXML) Version 2.0", W3C Recommendation, March 2004.
[VXML21] Oshry, M., Auburn, RJ., Baggia, P., Bodell, M., Burke, D.,
Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee,
A., Porter, B., and K. Rehor, "Voice Extensible Markup
Language (VoiceXML) Version 2.1", W3C Recommendation,
June 2007.
[VXML30] McGlashan, S., Auburn, RJ., Baggia, P., Barnett, J.,
Bodell, M., Burnett, D., Carter, J., Oshry, M., Rehor, K.,
Young, M., and R. Hosn, "Voice Extensible Markup Language
(VoiceXML) Version 3.0", W3C Working Draft, December 2008.
are Normative (they are currently Informative).
11) BCP 18 (RFC 2277) requires that any human readable text is explicitly or
implicitly tagged with a language tag. This affects the following fields in your
document:
4.2.4. <response>
reason: string specifying a reason for the response status. The
attribute is optional. There is no default value.
4.2.5.1. <dialogexit>
reason: a textual description which the MS SHOULD use to provide a
reason for the status code; e.g. details about an error. A valid
value is a string (see Section 4.6.6). The attribute is optional.
There is no default value.
4.4.2. <auditresponse>
reason: string specifying a reason for the status. The attribute is
optional.
4.4.2.2.5.1. <variabletype>
desc: a string providing some textual description of the type and
format. The attribute is optional.
Language tagging is missing here
<format>: element with a desc attribute (optional description)
As above
and a content model describing a supported format in the <variable>
format attribute. The element is optional.
I think the easiest way to address this would be to add xml:lang attribute to
various identified places (and update the XML Schema accordingly), however other
alternatives might be more suitable for you.
(See
<http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues> for a
bit more details)
Also note that some of the examples might have to be updated to show language
tagging.
4.2.2.2.1. <region>
The <region> element is used to specify the region within a video
layout where a video media stream is displayed.
What is a "region"? Is this the same as the DVD region?
4.3.1.1.1. <variable>
A <variable> element has the following attributes:
value: specifies the string to be rendered. A valid value is a
string (see Section 4.6.6). The attribute is mandatory.
type: specifies the type to use for rendering. A valid value is a
string (see Section 4.6.6). The attribute is mandatory.
format: specifies format information to use in conjunction with the
type for the rendering. A valid value is a string (see
Section 4.6.6). The attribute is optional. There is no default
value.
Are these defined somewhere in more details?
For example, the MS could support <variable> type/format combinations
such as:
Is this the complete list?
4.6.4. Non-Negative Integer
The value space of non-negative integer is the infinite set
{0,1,2,...}.
(And the same comment for positive integers)
Is making this unbounded truly necessary? This might be a burden on
implementations and many (most?) will limit it anyway.
4.6.11. Language Identifier
A language identifier labels information content as being of a
particular human language variant. Following the XML specification
for language identification [XML], a legal language identifier is
identified by a RFC566 ([RFC5646]) and RFC4647 ([RFC4647]) code where
typo: RFC5646
the language code is required and a country code or other subtag
identifier is optional.
1. Please clarify how implementations will achieve interoperability with regard
to the <variable> element, given that there are no registries or specifications
for the 'type' and 'format' attributes. This applies also to the <variabletype>
element.
2. The <par> element defines no restrictions on its <media> children, with the
result that a dialog could be defined to simultaneously play multiple audio
streams or multiple video streams. However, the specification does not define
how to handle multiple streams of the same media type. It would be better to at
least recommend that a <par> element contain only one <media> element of the
same media type (not including sub-type). If this is perhaps defined in W3C.REC-
SMIL2-20051213, please note that.
3. I concur with Alexey Melnikov's DISCUSS regarding inclusion of credentials in
the 'src' attribute for <dialogprepare>, <dialogstart>, and <grammar> and the
'loc' attribute for the <media> element.
4. Please see my comments on draft-ietf-mediactrl-mixer-control-package, since
many of them also apply to draft-ietf-mediactrl-ivr-control-package. As one
example, see my comments regarding the mixed content model for the <param>
element.
1. The following sentence does not parse: If no <media> child element is specified, the MS MUST provide a recording location where the recording format is implementation- specific.
draft-ietf-morg-sortdisplay
draft-ietf-krb-wg-preauth-framework
A couple of trival things to look at... Please expand acronyms on first use. For example KDC in the Abstract --- "padata" is used in section 1 before it is explained in section 2. --- Section 3 When a Kerberos client wishes to obtain a ticket using the authentication server, it sends an initial Authentication Service (AS) request. If pre-authentication is required but not being used, then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error. Unless this is defining existing behavior (in which case you should include a reference) you should substitute /will/MUST/
Section 5.1 says:
>
> New mechanisms MUST NOT be hard-wired to use a specific algorithm.
>
While I am a strong supported of algorithm agility, I can imagine a
pre-authentication mechanism that is not algorithm agile. Given the
type fields in the protocol, many of the reasons for a MUST NOT
statement are already addressed. Would it be appropriate for two
pre-auth mechanism to be defined that use ZKPP techniques, one that
makes use for discrete log and another that makes use of elliptic
curve?
I find the Abstract quite difficult to understand. I had to read the Introduction in order to understand it. The middle paragraph is not useful without a lot of context. The Introduction uses "padata type" with no explanation. It should be expanded, and a reference to the base Kerberos specification with a section number would help the reader. Someone without detailed knowledge of Kerberos will be confused by the use of AS and KDC in the first two sentences of Section 3. Perhaps the audience of this document is Kerberos experts, but I suspect that an additional sentence here could avoid a lot of confusion.
In Section 3.2: > The KDC SHOULD NOT send data that is encrypted in "encrypted with"? > the long-term > password-based key of the principal. In Section 5.1: > New mechanisms MUST NOT be hard-wired to use a specific algorithm. What kind of algorithm? In Section 6.4.2: > A padata type PA-FX-FAST is defined for the Kerberos FAST pre- > authentication padata. The corresponding padata-value field > [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST- > REQUEST. As with all pre-authentication types, the KDC SHOULD > advertise PA-FX-FAST in a PREAUTH_REQUIRED error. KDCs MUST send the > advertisement of PA-FX-FAST with an empty pa-value. Clients MUST > ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED > error. Did you mean KDC_ERR_PREAUTH_REQUIRED above? (In 2 places) In Section 8.1: I suggest deleting the table of registered values from this section before the document is published as an RFC. This would avoid confusion if the corresponding IANA registry becomes out of sync with this table.
Please consider clarifying the first paragraph of 4.4 (particularly the sentence starting "Note that the client machine"). Also consider additional clarity around "clients MUST be prepared for tokens somewhat larger than the size of all messages in conversation". Does that mean all the messages in _this_ conversation so far? If so, is it the maximum or sum of previous messages? Or was the intent simply to tell implementers to slightly more than double the size of the buffers they were previously allocating?
In section 9, I couldn't parse 1st sentence of 2nd paragraph (maybe the "to" is extraneous): "Regarding to the facilities provided by the Encrypted Challenge FAST factor, the challenge key " In section 6.4.1.1 and 9: r/fast factor/FAST factor (x5)
draft-ietf-ccamp-gmpls-ether-svcs
The SECDIR review by Paul Hoffman noted that the security considerations
indicates that no new security considerations are introduced by the protocol.
However, the normal RSVP has hop-by-hop integrity protection but this ID uses
non-hop-byhop notifications. So, it seems that in the "normal RSVP-TE security
model" does not actually provide end-to-end notification integrity. I did not
see a response that indicated that a security consideration addressing non-hop-
by-hop integrity is not needed and the rationale for it.
draft-ietf-ccamp-ethernet-traffic-parameters
The document has this text:
The permitted Ethernet Link Type values are:
Value Switching Granularity
----- ---------------------
0 Provided in signaling. See [GMPLS-ESVCS]
1 Ethernet Port (for port-based service)
2 Ethernet Frame (for EVC-based service)
255 Reserved value
Values 0 through 239, and 255 are assigned by IANA via IETF
Standards Action. Value 255 is reserved by the
present document.
I think this should be "Values 3 through 239 are assigned by IANA via
Standards Action [RFC5226]. Value 255 is reserved by the present
document." There is no need to assign values that have already been
assigned (such as 0-2 and 255).
Also, entries values 0, 1, and 2 should have a reference above.
It is this document, but I am actually not sure where in this
document their definition can be found.
Finally, there is confusing overlap with Section 9. It would be
perhaps better to specify the actual behaviour and formats in this
section and the IANA rules only in Section 9. My comments apply to
both the IANA section and this text, however.
The document has this text:
Type Length Format Description
------------------------------------------------------
0 TBD Reserved Reserved value
1 TBD Reserved Reserved value
2 24 see Section 3.1 Ethernet Bandwidth
Profile [MEF10.1]
3 8 [GMPLS-ESVCS] Layer 2 Control
Processing (L2CP)
255 TBD Reserved Reserved value
I am not sure I understand why Length values can be "TBD". TBD values
need to be filled in before the RFC comes out, did you intend to have
IANA fill them, or does TBD stand for "not applicable" or "any value
is acceptable here"?
Also, this list has similar issues to the one shown above.
Section 4.1 has this text:
The Flag 2 (CM) indicates whether the color-aware or color-
blind property is employed by the bandwidth profile. When Flag
2 is set to value 0 (1), the bandwidth profile algorithm is
said to be in color blind (color aware) mode.
I would like to see a reference to what the color-aware/blind property
is.
In a number of cases the following text is used to describe the assignment status of code points "Values 256 through 65535 are not to be assigned at this time." It would be useful to forward reference the IANA section which actually specifies this as "Standards Action" Alternatively the authors could omit all the policy statements from the body text (which duplicates the IANA section) and put the policy in one place (the IANA section).
Should MEF10.1 (which defines coupling and color mode) be a normative reference
for this document?
In section 8, the first paragraphs is "This document introduces no new security considerations to either [RFC3473]." The word "either" implies there was another RFC listed. Should "either" be removed from the sentence or should another RFC be added?
draft-ietf-ccamp-gmpls-mef-uni
A few editorial comments: section 4, first sentence says there is one additonal requirement. Is that what is described in 4.1? The text doesn't explciitly state what the additional requirement is. It might be good to add to the first sentence ",as described in section 4.1." s/one additional ... requirements/one additional ... requirement/ s/takes occurs/occurs/ or s/takes occurs/takes place/ idnits raises some issues that should be resolved.
In section 6, it is hard to parse: "information that takes occurs per Section 7.2 of [RFC4974]."
draft-ietf-mediactrl-mixer-control-package
[Updated, adding issued # 5 below]
1) I would like to "upgrade" Peter's comment # 2 to DISCUSS:
There are XML errors in the text and examples, such as the following (a missing
"/" in the second tag):
<video-layout>mylayout:single-view<video-layout>
2) In 4.2.2.5. <stream>:
media: a string indicating the type of media associated with the
stream. The following values MUST be used for common types of
media: "audio" for audio media, and "video" for video media. The
attribute is mandatory.
(This is largely the same as Peter's COMMENT # 5)
Is there a registry (or at least a full list) of valid names?
Or did you mean the type part of a MIME type?
3) In 4.6.6. MIME Media Type:
A string formatted as a IANA MIME media type ([MIME.mediatypes]).
Firstly, I think this should also point to exact ABNF for this.
It is also not clear if Content-type parameters are allowed in this field.
For MIME type/subtype ABNF, please reference Section 4.2 of RFC 4288.
I would
also encourage you to specify proper ABNF for this production (and to reference
"type-name" and "subtype-name" from Section 4.2 of RFC 4288)
4)
4.2.2.5.3. <region>
The <region> element is used to explicitly specify the region within
a video layout where the media stream is displayed.
The <region> element has no attributes and its content model
specifies the name of the region layout.
I don't think this description is sufficient for understanding by somebody not
involved in this work. Is there a good reference to add here?
5) BCP 18 (RFC 2277) requires that any human readable text is explicitly or
implicitly tagged with a language tag. This affects the following fields in your
document:
4.2.3. <response>
reason: string specifying a reason for the response status. The
attribute is optional.
4.2.4.2. <unjoin-notify>
reason: a textual description providing a reason for the status
code; e.g. details about an error. A valid value is a string (see
Section 4.6.4). The attribute is optional. There is no default
value.
4.2.4.3. <conferenceexit>
reason: a textual description providing a reason for the status
code; e.g. details about an error. A valid value is a string (see
Section 4.6.4). The attribute is optional. There is no default
value.
4.3.2. <auditresponse>
reason: string specifying a reason for the status. The attribute is
optional.
I think the easiest way to address this would be to add xml:lang attribute to
various identified places (and update the XML Schema accordingly), however other
alternatives might be more suitable for you.
(See
<http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues> for a
bit more details)
Also note that some of the examples might have to be updated to show language
tagging.
1. The <param> element has a mixed content model:
The <param> element content model (text and/or XML) is the value of
the parameter. Values in XML format MUST use a namespace other than
the one used in this specification. Note that a text value which
contains XML characters (e.g. "<") needs to be escaped following
standard XML conventions.
This seems inadvisable because it significantly complicates parsing. For
instance, the following examples would be valid:
<param><one xmlns='http://example.com/one'/>234567</para>
<param>123<four xmlns='http://example.com/four'/></para>
<param>123<four xmlns='http://example.com/four'/>567</para>
<param>123<four xmlns='http://example.com/four'/>567<eight
xmlns='urn:ietf:params:xml:ns:example'/></para>
Please justify the mixed content model or define a more reasonable approach,
such as:
<param><value>123</value></param>
and:
<param><four xmlns='http://example.com/four'/></para>
(but, possibly, never both <value/> and something qualified by a foreign
namespace)
1. The <video-layout> element is not very XML-friendly, given that it forces an
implementation to parse through the XML character data. Currently the spec
defines a format like this for XCON formats:
<video-layout>dual-view-2x1-crop</video-layout>
Or like this for extensions
<video-layout>mylayout:single-view</video-layout>
Have the authors considered a more XML-friendly approach, such as this?
<video-layout>
<dual-view-2x1-crop/>
</video-layout>
<video-layout>
<mylayout xmlns='http://example.com/foo'>single-view</mylayout>
</video-layout>
The specification could then instruct implementations to appropriately handle
child elements that are qualified by other namespaces.
2. There are XML errors in the text and examples, such as the following (a
missing "/" in the second tag):
<video-layout>mylayout:single-view<video-layout>
3. In Section 4.2.1.4.3 the text has "The MS receives <join>, <modifyjoin> and
<join> commands" but the authors might mean "The MS receives <join>,
<modifyjoin> and <unjoin> commands" or might not have intended to include the
second <join> element.
4. Regarding the <video-switch> element, see previous comments about <video-
layout>.
5. Regarding the media attribute of the <stream> element, a reference to
http://www.iana.org/assignments/media-types/ would be appropriate. Also, are
values other than "audio" and "video" allowed?
6. Please spell out the DTMF acronym on first use (Section 4.2.2.5.2).
7. In Section 4.6.1 the value space of boolean is defined as {true, false}, but
does the lexical representation match that from W3 XML Schema, Section 3.2.2.1?
It seems not, because the schema has:
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" />
<xsd:enumeration value="false" />
</xsd:restriction>
</xsd:simpleType>
Why define a special boolean datatype when W3 XML Schema already has
xsd:boolean?
8. You might want to specify whether the schema is normative or informative.
9. The description of the default value for the 'tones' attribute does not match
the schema.
draft-ietf-ippm-twamp-session-cntrl
I support Sean's Discuss, and the spec needs to point back to the
original RFCs so that the semantics of HMAC and other fields are
adequately specified for the new commands.
Secondly, I found this text a bit odd:
o If the RECOMMENDED REFWAIT timer is implemented, it SHOULD be
enforced when any test session is in-progress (started and not
stopped).
The text should probably read "If the REFWAIRT timer is implemented ..."
Earlier text already recommends REFWAIT to be implemented, it should
not be repeated here.
A few nits you might sort out along the way... I don't think that using 2119 language in the Abstract or Introduction is very appropriate. That language is really intended for specifying protocol behavior. --- Section 1 This memo is intended to be an update to the TWAMP core protocol specified in [RFC5357]. It is not required to implement the feature described in this memo to claim compliance with [RFC5357]. It is a bit late for intentions :-) I think this is an update fair and square. The second sentence could also do with some polish. What is not required to implement the feature? --- It is not immediately clear to me whether this feature also applies to OWAMP. I think not, so it is slightly confusing that Section 1 says... This memo describes an OPTIONAL feature for TWAMP. TWAMP (and OWAMP) start all previously requested and accepted test sessions at once. --- Section 2 The scope of the memo is currently limited to specifications of the following features: So at what point might it change? --- My Discuss used to read... A small issue I would like to clarify before supporting the publication of this document. In Section 1 you have... Implementers of this feature may also wish to implement the "Reflect Octets" feature, described in [I-D.ietf-ippm-twamp-reflect-octets], once it has been published as an RFC. This feature allows a Control- Client to insert a locally-specified request number into the Request- TW-Session command (in octets originally designated MBZ=Must Be Zero), and a compliant Server will return the request number in its reply (Accept message). The Reflect Octets feature makes multiple simultaneous session requests possible, and supports the operation of many simultaneous test sessions (similar to the goal of this memo). Do I read this to mean that the working group is developing two solutions to the same problem? One (the other) having wider applicability. Can you clarify the working group thinking on this? - Al has clarified for me that there is no overlap between the - work, but it would be really nice if the quoted paragraph - could be rewritten to avoid implying that there are two - different solutions to the same problems.
A couple minor edits: s/must be one or greater/MUST be one or greater/g s/one or more the sessions/one or more of the sessions/g
3.2. Start-N-Sessions Command with Individual Session Control The message is terminated with a single block HMAC, as illustrated above. How is this calculated? I suspect you meant HMAC as defined in Section 3.2 of RFC 4656, but it would be good to say this explicitly somewhere in the document (Somewhere around Introduction? HMAC is used in several places in the document.)
I support Sean's Discuss on HMAC pecification.
The HMAC algorithm used in section 3.3, 3.4, and 3.5 needs to be specified. I
assume it's the same one that's specified in [RFC4656]/[RFC5357], but I'd prefer
an explicit statement that says as much. Please either add a normative
reference to the HMAC algorithm or a pointer to the appropriate section in
[RFC4656]/[RFC5357].
draft-ietf-nsis-ntlp-statemachine
In Appendix A the authors state: "This appendix contains the state diagrams in ASCII format. Please use the PDF version whenever possible: it is much easier to understand." It would be useful if the authors made it clear to the readers at the beginning of the document that a PDF version existed and that in their view this was a clearer representation of the state machine. In particular it should be noted at the top of section 6 that a more readable version exists. The authors also need to add a note stating which version the reader should take as correct in the event of a difference between the two documents. Given the authors' stated preference for the .pdf version, and the informational nature of this document have they considered eliminating any version ambiguity by reducing the content of the ASCII version to a shell that points to the .pdf version?
Section 7 says... This document does not raise new security considerations. Any security concerns with GIST are likely reflected in security related NSIS work already (such as [1] or [6]). Could you manage to be any less certain of the fact? :-)
COMMENTS (general): 1) I realize this is informational, but I think it still needs to be clear. I have difficulty understanding the variables defined in 5.2. The definitions do not describe who sets these values when, and who uses the values when, and what the acceptable values are. 2) Cmode and Dmode are defined by self-reference: "Cmode: The message MUST be transmitted in Cmode." (and is CMode the same as C_mode in section 5.2?) 3) There are numerous spelling and grammar mistakes that lessen the quality of this specification. (a spell-check is likely to miss the use of bellow, where below should be used.) 4) There are two Figure 1's, and no Figure 2's in the document. Any references to figures need to be checked to make sure they point to the correct figure. COMMENTS (detailed): 1) section 5 has some acronymns that have not been defined yet. 2) I did not understand the sentence starting "Presented in this document state machines ...". Does this mean "The state machines presented in this document ..."? 3) section 5,1 is entitled procedures, but, for example, a T_No_Response timer is not a procedure. If this is meant to be about procedures, than each entry should include a verb. 4) The Tx/Rx entries are sorted sometimes by listig all the Tx words then the rx words, but sometimes in Tx/Rx pairs. 5) some procedures are mixed case (Install) and some are capitalized (DELETE). 6) some procedures are verbs (DELETE MRS) and some are nouns (Established MA) 7) section 5.2 'policy) is provided." Provided by whom? 8) Cmode is not defined before use 9) I didn't understand the definition of NewPeer. When is this variable set, and when is it used? 10) section 6.2 points to the .txt version in Appendix A; Appendix A says to use the PDF version. I think there are three different versions, and maintaining consistency will be difficult. Which diagram form is the normative diagram? And the normative reference is to the GIST standard [1]. This multitude of versions doesn't strike me as clear and unambiguous. I recommend the Apppendix be called the State Tables, while section 6 is a state diagram, supplemented by a PDF, that reflects the normative state machine defined in [1]. 11) 6.2 point 4) is this the "currently established" MRS? It appears there might be more than one MRS - a currently established and a pending-established MRS. 12) 6.2 5) "NSLP applications requests sending data." Does this mean the applications requests that data be sent? or is it requesting the data to be sent? 13) 6.2 17) "Confirm message has not been received by downstream GIST peer." How would one know if the downstream peer recieved it or not? Is there an ACK? Then 17) should priobabyl say the ACK was not recieved. 14) 6.3 "based on local policy" seems to imply that the pervious part of the sentence is conditional. "If local policy permits, then MRS is installed immediately." and "If local policy requires an explicit confirm for MRS installation, then ..." 15) Security Considerations should be clearer than "likely reflected in ..." 16) I recommend moving the Acknowledghement of Christian into the acknowledgement section and eliminating the contributors section. And "since 01 version" seems superfluous in the 09 version. 17) Appendix says see PDF version; where is the PDF version to be found?
[I found the following very confusing, but can't see any real harm so I am making this a comment...] The state machine is inconsistent with respect to transition numbering: In the querying node state machine (figure 1), transition numbers are shared if the conditions and actions are identical (transitions 4 and 5), but differe where the conditions are identical but the actions are the different (i.e., transitions 5 and 14). In the responding node state machine (Figure 3), the two instances of transition 5 have identical conditions and different actions. However, transactions 6 and 12 also have identical conditions and different actions. Is there a rationale behind the transaction numbering?
The first and second sentence in the security considerations are somewhat
contradictory. If this document doesn't add any new considerations, then the
second sentence should be modified to be less vague. If there are
considerations not addressed in the two referenced RFCs then they need to be
added in to this document.
draft-ietf-pce-pcep-svec-list
The following Last Call comment was part of the Gen-ART Review by
Miguel Garcia posted on 3 March 2010:
>
> Section 5.2, first sentence in the 2nd paragraph. I guess the
> sentence looks incomplete. At least, it looks like an introductory
> part, but there is no consequence:
>
> If a PCC sends path computation requests to a PCE and then sends
> another path computation requests, which are dependent on the
> first requests and has been associated by using a SVEC list.
>
Adrian asked the authors to provide fixed text, but it has not
appeared yet.
This is a discuss-discuss. I intend to clear on the call, unless the
sponsoring AD requests that I hold on a particular point.
Are there issues with nesting of associated SVECs? For example, if the
SVEC-list presented in 4.2 was modified as follows:
OLD
<SVEC> without the dependency flag
Request-ID #X, Request-ID #Y, Request #Z
NEW
<SVEC> with one or more dependency flags
Request-ID #X, Request-ID #Y, Request #Z
<SVEC> without the dependency flag
Request #Z
thefinal SVEC is not directly associated with the first SVEC, but is
associated indirectly via Request #X. Is this intended/permitted? Is
this something to be avoided? It would seem to cause explosive growth
in complexity...
More pragmatically, is there any guidance we should give to PCCs
regarding tha construction of *practical* associated SVECs?
Section 4.2 last paragraph, immediately preceding the SVEC-list:
Why is #Z omitted from the parenthetical?
Section 5.1: if the PCE can't handle the associated SVEC objects it "may
send a PCErr message". This implies it might construct the paths
anyway. Is there a mechanism to inform the PCC that the requested
associations were not considered during path construction?
draft-harkins-emu-eap-pwd
I do not have the level of confidence in the cryptographic mechanisms that would be required to support standards track publication, but I am comfortable with publishing as Informational.
There's no requirement to support any EC curve(s) (section 2.10). Should some
text be added that says if you do support EC algorithms then you should/must
support the following curves (preferably ones that are well vetted like the ones
in RFC5480).
EC algorithms support compressed, uncompressed, and hybrid keys? Should this
document explicitly prohibit compressed and hybrid keys?
Section 2.6 notes that security of the protocol relies on good random numbers.
I'd like to add somewhere (possibly a pointer to RFC 5114 or another RFC) that
it also relies upon the inherent strength of the group and the size of the
exponent used.
Section 2.10 picks DH Groups 14 and 19. Please provide some rationale for the
choice either in 2.10 or the security considerations (e.g., IKE picked it so we
did too).
Sec 2.10: Please provide a pointer to where the DH Group information can be found. A reference to RFC5114 is in Sec 7, but one here would be helpful. Sec 7 bullet C: What is the "this" referring to in the last sentence?