Subject: Re: [XCON] Review of draft-ietf-xcon-ccmp-03

From: [email-masked]
Date: Mon, 02 Nov 2009 18:37:31 +0100

Hi Richard,

first of all let us thank you for your thorough review. It proved  
really helpful in suggesting us how to refine the document. Indeed, we  
made a lot of modifications to the document form -03 to -04 version.  
The current version should keep into account most of the reviewers'  
comments and suggestions. The most inportant part of the new version  
relates to the way CCMP handles update modifications. We do believe  
that in its current form, the document is really on the right track to  
reach its steady (and standard!) state.

Please find our detailed answers in-line.

DISCLAIMER: This is going to be a VEEERY LONG message ;-).

> General comments:
> 1. The protocol seems pretty well thought out.  Most of the below
> comments are focused on clarity, but there are also a couple of
> technical issues to be addressed.

Sounds good! This makes a good start, already.

>
> 2. It seems like this document and the data model should both use the
> same specification language, either XSD or RelaxNG, to facilitate
> parsing/validation.

Up to now, we have always sticked to the xsd approach. If needed, we  
can provide a RelaxNG specification of the CCMP.

>
> 3. The document uses a mixture of single (') and double (") quotes
> around things like element names.  Might be nice to standardize on one
> or the other.

Done. We chose double quotes as the "standard".

>
> Specific comments:
> Abstract
> The abstract says that CCMP is stateless, but that seems a little weird
> given that the whole point of the protocol is to modify the state of
> the conference server.  I understand the intent (the protocol itself is
> stateless), but you might think about rewording.

Done. We changed text in the following way:

"Even though the goal of the CCMP is to appropriately manage  
conference state, the mechanisms upon which the protocol itself is  
built are based on a state-less request/response paradigm."

Does it look clearer now?

>
> Section 4/5
> These two sections could probably stand to be merged.  I think it would
> be helpful to have the content of Section 5 (especially Figure 1)
> before most of Section 4, except maybe the first paragraph.
>
> Section 5
> Make sure that the label for Figure 1 stays with the figure.
>
> Section 6
> This section seems to be a little confused about what its purpose is.
> The stated purpose is to give an overview of the conference and user
> objects, but it has several tangential comments about how these objects
> are handled in certain cases.  Think about tightening the scope (see
> below).

As to the above points, we restructured the overall document in a way  
that looked more logical to us. We now have the following organization:

4: XCON Conference Control System Architecture
     4.1.  Conference Objects
     4.2.  Conference Users
5.  Protocol Overview
     5.1.  Protocol Operations
     5.2.  Implementation Approach
6.  CCMP messages
     6.1.  CCMP Request Message Type
     6.2.  CCMP Response Message Type
     6.3.  Detailed messages

>
> Section 6.1, Paragraph 1
> It might be helpful to provide a reference to Section 7.1 (Cloning
> Tree) of RFC 5239 here.

Done.

>
> Section 6.1, Paragraph 2, "A client MAY specify a parent element..."
> The phrase "parent element" is a little confusing here, since we're
> talking about XML objects, and the "parent" relationship is not in
> terms of XML elements, but rather objects in the cloning tree.  Suggest
> changing this sentence to "A client MAY specify a parent object (a
> conference or blueprint) from which to inherit values."

Done.

>
> Section 6.1, Paragraph 2, "When creating conferences..."
> This sentence seems like it belongs in Section 7.2.3.4 instead of here.
>
> Section 6.2, Paragraph 1, "Users are inherited as well..."
> For clarity, suggest adding "When a conference is cloned from a parent
> object..."

Done.

> Section 6.2, Paragraph 3
> This paragraph seems like it belongs elsewhere, e.g., in Section
> 7.2.3.4 or 7.2.3.6.
>
> Section 7.2
> It took me a little while to figure out why all the messages in the
> example are doubled up: "<ccmpRequest><ccmpRequest>..."  It would be
> helpful here to explain the general design methodology being followed
> that leads to that.  As I understand it, the idea is that you can carry
> multiple request and response messages within a single request or
> response.  This idea would be helpful to note, as well as some idea of
> how request and response messages are correlated.  Also, since you
> define elements for the detailed messages types, it would be clearer to
> use those types in the examples (in Section 8), rather than casting
> with xsi:type.
>

First, let us clarify that the protocol does not envisage that  
multiple request (response) messages can be carried in a single  
request (response). The relation is always one request (response)  
message per request (response). The reason why you see the use of the  
"xsi:type" instance specifier depends on our choice to specify the  
protocol messages in an object-oriented fashion. We defined an  
abstract structure associated with a generic request (response) and  
containing the properties that are common to any CCMP message. Such  
structure gets then specialized by actual message instances, which can  
add to the basic message structure their own specific properties. BTW,  
this approach allows for a direct mapping of the schema file onto code  
implementations that can be automatically obtained through automated  
binding technologies (e.g. JAXB for Java-based implementations). The  
alternative would be to use the "xs:choice" schema element to describe  
all message alternatives. While being equivalent at the logical level,  
such approach typically brings to more weird mappings onto  
implementations.

> Section 7.2.1, confUserId, "This attribute is required ..."
> Should there be RFC 2119 requirement here? "This attribute is REQUIRED..."

Done.

>
> Section 7.2.1, password
> I'm confused about how this parameter interacts with the
> <conference-password> element in the data model: In the data model,
> conference passwords are only scoped within a given <conf-uri>, whereas
> a password for a CCMP request would presumably need to be scoped at the
> level of the conference.  Or is the CCMP password an independent value
> not reflected in the conference object?

In rfc 4575, and  in the Data Model as well, <conf-uris>  is defined  
as "a sequence of <entry> child elements - each containing the URI to  
be used in order to access the conference by different signaling  
means". For each such element, a password can be defined. We put the  
XCON-URI among the above mentioned idetifiers (even though, strictly  
speaking, it is not a signaling URI).
Hence, we also defined, for the XCON-URI, a password, like in the  
following sample excerpt:

<info:conf-uris>
      <info:entry>
           <info:uri>xcon:[email-masked]</info:uri>
           <info:display-text>Conference XCON-URI</info:display-text>
           <xcon:conference-password>3456</xcon:conference-password>
      </info:entry>
</info:conf-uris>

>
> Section 7.2.1, Figure 2
> It was helpful to have this structure here.  It would be even better if
> a brief example could be provided as well.  Likewise for other sections
> below.

We thought it would be sufficient to say that, for all interesting  
scenarios, examples are provided in section 8. What is your feeling  
about this?

>
> Section 7.2.2.1
> It's a little confusing to have the error messages introduced at this
> point in the document, since the actions themselves haven't been
> defined.  Perhaps Table 2 (probably with the introductory text to
> Section 7.2.3) could be moved up to Section 7.2.1 to give a clearer
> idea of what the operations do.
>
> Section 7.2.3, Paragraph 3 (counting the bulleted list as 1 para)
> You need a different symbol than "N/A*" here, since * is also used with
> a different meaning in the table.

Right. With the new structure of the document, these points should  
have been fixed.

>
> Section 7.2.3.3, Paragraph 3
> The first sentence seems odd -- it's not clear in general that it
> another blueprint would be useful to the conference client, so why
> would it be RECOMMENDED to try another?  Suggest changing to the
> following: "If a response code fo "objectNotFound" is received in a
> 'blueprintResponse' message, a conference control client may attempt to
> retrieve another conference blueprint if more than one had been
> received in the "blueprintsResponse" message."

Done.

>
> Section 7.2.3.4, Paragraph 6 (counting 2 bullets as 1 para)
> The following phrase is confusing:
> "
> The 'confInfo' represents an object of type "conference-type"
> containing all the changes to be applied...
> "
> "Conference-type" object, i.e., conference objects, represent
> conference state, not changes.  I see in the example (Section 8) that
> the intent is to allow clients to send only a fragment of the
> conference object, rather than the whole thing.  There should be more
> discussion here about how the client constructs the right fragment to
> express his changes, and how the server interprets the fragment it gets.

You're definitely right on this. In version -04 of the protocol we  
decided to adopt, for CCMP updates, a mechanism à la event package,  
i.e. introduce versioning in CCMP messages. In order to effectively  
manage modifications to conference data, a versioning approach is  
exploited in the CCMP. In the following I'm pasting the part of  
section 5.1 of version -04 which explains this point:

***** BEGIN SNIPPET FROM DRAFT *****

More precisely, each conference object is associated with a version  
number indicating the most up to date view of the conference at the  
server's side. Such version number is reported to the clients when  
answering their requests. A client willing to make modifications to a  
conference object has to send an update message to the server. In case  
the modifications are all successfully applied, the server sends back  
to the client a "success" response which also carries information  
about the current server-side version of the modified object. With  
such approach, a client which is working on version "X" of a  
conference object and finds inside a "success" response a version  
number which is "X+1" can be sure that the version it was aware of was  
the most up to date. On the other hand, if the "success" response  
carries back a version which is at least "X+2", the client can detect  
that the object that has been modified at the server's side was more  
up to date than the one it was working upon. This is clearly due to  
the effect of concurrent modification requests issued by independent  
clients. Hence, for the sake of having available the latest version of  
the modified object, the client can send to the conference server a  
further "retrieve" request. We remark that in no case a copy of the  
conference object available at the server is returned to the client as  
part of the update response message. Such a copy can always be  
obtained through an ad-hoc "retrieve" message. Based on the above  
considerations, all CCMP response messages except those associated  
with the retrieval of either the list of blueprints or the list of  
conferences will have to contain a mandatory "version" parameter. This  
does not hold for request messages, for which the "version" parameter  
is not at all required, since it represents useless information for  
the server: as long as the required modifications can be applied to  
the target conference object with no conflicts, the server does not  
care whether or not the client had an up to date view of the  
information stored at its side. This said, it stands clear that a  
client which has subscribed at the server, through the XCON event  
package [I?D.ietf?xcon?event?package], to notifications about  
conference object modifications, will always have the most up to date  
version of that object available at his side.

***** END SNIPPET FROM DRAFT *****

>
> Section 7.2.3.5-10
> Since users and sidebars are both sub-elements of the conferene object,
> what's the rationale for handling them via separate CCMP requests?  Is
> the idea that it simplifies permissions management for the server (in
> the case where some users are only allowed to access users/sidebars),
> since the server doesn't have to look at what's in the changes to check
> permissions?

It can also be useful in cases where the user is not interested in the  
entire conference object, but just in some parts of it.

>
> Section 7.2.3.5-10
> Also, it seems like these messages should follow the pattern of the
> blueprint[s] and conf[s] messages above: The plural messages should be
> retreive-only, while the singular messages should allow other
> operations.

Indeed, the idea here is that conferences and blueprints are  
independently stored at the server. With the plural version of the  
message you retrieve their
URIs, whereas with the singular version of the message you make a  
drill-down query addressed to one specific server-side object.  
Sidebars can only be retrieved by accessing the corresponding element  
contained in the conference object associated with the 'main'  
conference they belong to. That's why we only envisaged the second  
kind of message (which, btw, has the plural representation due to the  
name of the data model elements dealing with sidebars).

Hope this shades light on the comment above.

>
> Section 7.2.3.5-6
> How do these CCMP operations interact with the signaling protocols?
> Presumably when a user joins via a CSP, he is added to the conference
> object; is this equivalent to a userRequest/create operation?

Join operations with CCMP are equivalent to join operations via a CSP.  
If a user wants to enter a conference via CCMP, she/he can issue a  
userRequest/create message. Such request should act as a trigger for  
the required signaling between the conference focus and the user. We  
identified two distinct cases. The former relates to a user who  
already has an xcon-userid (which means that the conference server is  
aware of the mapping xcon-userid<-->CSP URI). In such case, the  
userRequest/create message carries the user's xcon-userid inside the  
'confUserId' parameter; the 'userInfo' parameter, in turn, contains a  
<user> element whose 'entity' attribute is the mentioned xcon-userid.
The latter case refers to a user to whom no xcon-userid has been  
assigned yet. In such case, the userRequest/create message carries a  
void confUserId parameter, while the 'userInfo' parameter specifies  
the sender's CSP address (e.g. her/his SIP URI). The server-created  
xcon-userId is returned to the client inside the 'confUserId'  
parameter of the response (which optionally also contains a whole  
<user> element inside the 'userInfo' parameter).

In both cases, once done with the described CCMP interaction,  
focus-user signaling starts. In the call flow examples draft, at page  
28 ("adding a party") we also put a picture illustrating a possible  
CCMP-CSP interaction in the case of user Alice trying to add user Bob  
to a conference. In the mentioned example, after the CCMP request is  
completed, the conference focus contacts Bob at the SIP address  
communicated by Alice.

Indeed, all of the scenarios envisaged in RFC 4353 (page 14, "adding  
participants") can be appropriately realized through the CCMP.

>
> Section 7.2.3.5, Paragraph 2
> s/userInfo/usersInfo/

Done.

>
> Section 7.2.3.5, Bullet 1 (retreive)
> Change SHOULD NOT to MUST NOT, since it is ignored anyway.

Done.

>
> Section 7.2.3.5, Bullet 2 (update)
> Same concern here as with 7.2.3.4 above -- how do you represent changes
> with a users-type object?

See answer to 7.2.3.4 above...

>
> Section 7.2.3.6, Paragraph 1, "Note that a user..."
> This sentence seems like a non-sequitur: If a client is not XCON-aware,
> then it's not going to generate these messages.  Recommend saying
> instead that some CSP operations might have the same effect as these
> operations, i.e., that when a user joins/leaves/etc, the conference
> server might perform an action that would otherwise be performed via a
> userRequest.

The above sentence refers to the fact that the XCON Data Model also  
contains information about users who are non XCON-aware participants  
in a conference. Such users DO NOT interact with the conference server  
via the CCMP. Hence, we are not referring here neither to the  
generation of CCMP messages on their side, nor to the interaction  
between CSP and CCMP (which we briefly described above -- see answer  
to your question about Section 7.2.3.5-6). We might make a reference  
here to the call flows document, which illustrates most of the notable  
use-cases associated with such interaction. What do you think about  
this? Alternatively, if the sentence in the draft is misleading, we  
might just remove it.

>
> Section 7.2.3.6, 'update' paragraph
> Same concern here as with 7.2.3.4 above -- how do you represent changes
> with a user-type object?
>

See answer to 7.2.3.4 above...

> Section 7.2.3.8, 'update' paragraph
> Same concern here as with 7.2.3.4 above -- how do you represent changes
> with a conference-type object?

See answer to 7.2.3.4 above...

>
> Section 7.2.3.10, 'update' paragraph
> Same concern here as with 7.2.3.4 above -- how do you represent changes
> with a conference-type object?

See answer to 7.2.3.4 above...

>
> Section 9
> Is this the process for dereferencing an XCON-URI?  If so, you should say so.

This section illustrates how to derive the HTTP/HTTPS URI of the  
"Conferencing Server" (i.e. the Conference Control Server). Should we  
make this explicit (and also replace "Conferencing Server" with  
"Conference Control Server")?

>
> Section 11, Paragraph 3
> The second sentence here ("Because the conferencing client...") doesn't
> make sense.  The reason you're not requiring HTTP authentication and
> cookies is that CCMP has its own authentication.  Suggest replacing with
> "
> A conferencing client that conforms to this specification is not
> required to support HTTP authentication [RFC2617] or cookies [RFC2965].
>  These mechanisms are unnecessary because CCMP requests carry their own
> authentication information (in the 'confUserId' and 'password' fields;
> see Section 7.2.1).
> "

Done! Sounds better this way...

>
> Section 11, Paragraphs 4 and 7
> Change first sentence to "CCMP requests MUST be carried in the body of
> an HTTP POST request.  If a CCMP server receives an HTTP request using
> a method other than POST, it must respond with an error message, e.g.,
> 404 (not found)."  In light of this change, paragraph 7 could be
> deleted. On the other hand, it seems like it wouldn't be unreasonable
> for the server to respond to a HEAD request.  In which case: "CCMP
> requests MUST be carried in the body of an HTTP POST request.  A CCMP
> server MAY respond to HEAD requests.  If a CCMP server receives an HTTP
> request using a method other than POST or HEAD, it must respond with an
> error message, e.g., 404 (not found)."

We think the above paragraphs might stay unchanged except for the  
error message returned, which should be a 405 (method not allowed),  
rather than a generic 404.
What's your feeling about that?

>
> Section 12
> The security considerations here are relatively comprehensive, but a
> little scatter-shot.  I will provide a more thorough review of this
> section later.

Perfect. We'll wait for your feedback on that specific part.

>
> Section 14.4.1-2
> I'm guessing you mean to register "Conference Server" tags rather than
> "Location Server" tags, and for CCMP rather than HELD.

Your guess is definitely right ;-).

Regards,

Simon

Quoting Richard Barnes <[email-masked]>:

> Hi all,
>
> In my effort to get up to speed on XCON, I'm in the process of
> reviewing the active working group drafts (in addition to the other
> relevant background).  My review of draft-ietf-xcon-ccmp-03 is below.
>
> --Richard
>
>
> -----
> Draft:  draft-ietf-xcon-common-data-model-13
> Reviewer: Richard Barnes
> Review Date: 18 Aug 09
>
> General comments:
> 1. The protocol seems pretty well thought out.  Most of the below
> comments are focused on clarity, but there are also a couple of
> technical issues to be addressed.
>
> 2. It seems like this document and the data model should both use the
> same specification language, either XSD or RelaxNG, to facilitate
> parsing/validation.
>
> 3. The document uses a mixture of single (') and double (") quotes
> around things like element names.  Might be nice to standardize on one
> or the other.
>
>
> Specific comments:
> Abstract
> The abstract says that CCMP is stateless, but that seems a little weird
> given that the whole point of the protocol is to modify the state of
> the conference server.  I understand the intent (the protocol itself is
> stateless), but you might think about rewording.
>
> Section 4/5
> These two sections could probably stand to be merged.  I think it would
> be helpful to have the content of Section 5 (especially Figure 1)
> before most of Section 4, except maybe the first paragraph.
>
> Section 5
> Make sure that the label for Figure 1 stays with the figure.
>
> Section 6
> This section seems to be a little confused about what its purpose is.
> The stated purpose is to give an overview of the conference and user
> objects, but it has several tangential comments about how these objects
> are handled in certain cases.  Think about tightening the scope (see
> below).
>
> Section 6.1, Paragraph 1
> It might be helpful to provide a reference to Section 7.1 (Cloning
> Tree) of RFC 5239 here.
>
> Section 6.1, Paragraph 2, "A client MAY specify a parent element..."
> The phrase "parent element" is a little confusing here, since we're
> talking about XML objects, and the "parent" relationship is not in
> terms of XML elements, but rather objects in the cloning tree.  Suggest
> changing this sentence to "A client MAY specify a parent object (a
> conference or blueprint) from which to inherit values."
>
> Section 6.1, Paragraph 2, "When creating conferences..."
> This sentence seems like it belongs in Section 7.2.3.4 instead of here.
>
> Section 6.2, Paragraph 1, "Users are inherited as well..."
> For clarity, suggest adding "When a conference is cloned from a parent
> object..."
>
> Section 6.2, Paragraph 3
> This paragraph seems like it belongs elsewhere, e.g., in Section
> 7.2.3.4 or 7.2.3.6.
>
> Section 7.2
> It took me a little while to figure out why all the messages in the
> example are doubled up: "<ccmpRequest><ccmpRequest>..."  It would be
> helpful here to explain the general design methodology being followed
> that leads to that.  As I understand it, the idea is that you can carry
> multiple request and response messages within a single request or
> response.  This idea would be helpful to note, as well as some idea of
> how request and response messages are correlated.  Also, since you
> define elements for the detailed messages types, it would be clearer to
> use those types in the examples (in Section 8), rather than casting
> with xsi:type.
>
> Section 7.2.1, confUserId, "This attribute is required ..."
> Should there be RFC 2119 requirement here? "This attribute is REQUIRED..."
>
> Section 7.2.1, password
> I'm confused about how this parameter interacts with the
> <conference-password> element in the data model: In the data model,
> conference passwords are only scoped within a given <conf-uri>, whereas
> a password for a CCMP request would presumably need to be scoped at the
> level of the conference.  Or is the CCMP password an independent value
> not reflected in the conference object?
>
> Section 7.2.1, Figure 2
> It was helpful to have this structure here.  It would be even better if
> a brief example could be provided as well.  Likewise for other sections
> below.
>
> Section 7.2.2.1
> It's a little confusing to have the error messages introduced at this
> point in the document, since the actions themselves haven't been
> defined.  Perhaps Table 2 (probably with the introductory text to
> Section 7.2.3) could be moved up to Section 7.2.1 to give a clearer
> idea of what the operations do.
>
> Section 7.2.3, Paragraph 3 (counting the bulleted list as 1 para)
> You need a different symbol than "N/A*" here, since * is also used with
> a different meaning in the table.
>
> Section 7.2.3.3, Paragraph 3
> The first sentence seems odd -- it's not clear in general that it
> another blueprint would be useful to the conference client, so why
> would it be RECOMMENDED to try another?  Suggest changing to the
> following: "If a response code fo "objectNotFound" is received in a
> 'blueprintResponse' message, a conference control client may attempt to
> retrieve another conference blueprint if more than one had been
> received in the "blueprintsResponse" message."
>
> Section 7.2.3.4, Paragraph 6 (counting 2 bullets as 1 para)
> The following phrase is confusing:
> "
> The 'confInfo' represents an object of type "conference-type"
> containing all the changes to be applied...
> "
> "Conference-type" object, i.e., conference objects, represent
> conference state, not changes.  I see in the example (Section 8) that
> the intent is to allow clients to send only a fragment of the
> conference object, rather than the whole thing.  There should be more
> discussion here about how the client constructs the right fragment to
> express his changes, and how the server interprets the fragment it gets.
>
> Section 7.2.3.5-10
> Since users and sidebars are both sub-elements of the conferene object,
> what's the rationale for handling them via separate CCMP requests?  Is
> the idea that it simplifies permissions management for the server (in
> the case where some users are only allowed to access users/sidebars),
> since the server doesn't have to look at what's in the changes to check
> permissions?
>
> Section 7.2.3.5-10
> Also, it seems like these messages should follow the pattern of the
> blueprint[s] and conf[s] messages above: The plural messages should be
> retreive-only, while the singular messages should allow other
> operations.
>
> Section 7.2.3.5-6
> How do these CCMP operations interact with the signaling protocols?
> Presumably when a user joins via a CSP, he is added to the conference
> object; is this equivalent to a userRequest/create operation?
>
> Section 7.2.3.5, Paragraph 2
> s/userInfo/usersInfo/
>
> Section 7.2.3.5, Bullet 1 (retreive)
> Change SHOULD NOT to MUST NOT, since it is ignored anyway.
>
> Section 7.2.3.5, Bullet 2 (update)
> Same concern here as with 7.2.3.4 above -- how do you represent changes
> with a users-type object?
>
> Section 7.2.3.6, Paragraph 1, "Note that a user..."
> This sentence seems like a non-sequitur: If a client is not XCON-aware,
> then it's not going to generate these messages.  Recommend saying
> instead that some CSP operations might have the same effect as these
> operations, i.e., that when a user joins/leaves/etc, the conference
> server might perform an action that would otherwise be performed via a
> userRequest.
>
> Section 7.2.3.6, 'update' paragraph
> Same concern here as with 7.2.3.4 above -- how do you represent changes
> with a user-type object?
>
> Section 7.2.3.8, 'update' paragraph
> Same concern here as with 7.2.3.4 above -- how do you represent changes
> with a conference-type object?
>
> Section 7.2.3.10, 'update' paragraph
> Same concern here as with 7.2.3.4 above -- how do you represent changes
> with a conference-type object?
>
> Section 9
> Is this the process for dereferencing an XCON-URI?  If so, you should say so.
>
> Section 11, Paragraph 3
> The second sentence here ("Because the conferencing client...") doesn't
> make sense.  The reason you're not requiring HTTP authentication and
> cookies is that CCMP has its own authentication.  Suggest replacing with
> "
> A conferencing client that conforms to this specification is not
> required to support HTTP authentication [RFC2617] or cookies [RFC2965].
>  These mechanisms are unnecessary because CCMP requests carry their own
> authentication information (in the 'confUserId' and 'password' fields;
> see Section 7.2.1).
> "
>
> Section 11, Paragraphs 4 and 7
> Change first sentence to "CCMP requests MUST be carried in the body of
> an HTTP POST request.  If a CCMP server receives an HTTP request using
> a method other than POST, it must respond with an error message, e.g.,
> 404 (not found)."  In light of this change, paragraph 7 could be
> deleted. On the other hand, it seems like it wouldn't be unreasonable
> for the server to respond to a HEAD request.  In which case: "CCMP
> requests MUST be carried in the body of an HTTP POST request.  A CCMP
> server MAY respond to HEAD requests.  If a CCMP server receives an HTTP
> request using a method other than POST or HEAD, it must respond with an
> error message, e.g., 404 (not found)."
>
> Section 12
> The security considerations here are relatively comprehensive, but a
> little scatter-shot.  I will provide a more thorough review of this
> section later.
>
> Section 14.4.1-2
> I'm guessing you mean to register "Conference Server" tags rather than
> "Location Server" tags, and for CCMP rather than HELD.
>
>
>
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xcon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/