Subject: [XCON] Comments on draft-ietf-xcon-framework-07.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 24 Apr 2007 15:38:40 +0300

Hi,

a few comments on the XCON framework.

The title of the framework, the abstract, and several sections, state 
that this document defines a data model for centralized conferencing. 
This is confusing because the framework does not actually define the 
data model; the data model draft does. Therefore, I would suggest that 
the framework clearly states that the definition of the data model is in 
the data model draft.

The document has a section (Section 2) that references RFC 2119 but then 
does not use normative language. If the idea is to have an informational 
framework, that section can be removed.

The 1st paragraph of Section 5 states that the common conference 
information type is extensible for including multiple sub-type. What 
exactly does that mean? Extensions to the data model will continue using 
the same media type.

The 2nd paragraph of Section 5.2 says that policies are not explicitly 
defined within the data model, but rather are reflected in the system 
realization. Given that policies will be studied after the data model is 
completed, I would avoid talking to much about policies until we have a 
clear view on how they will be implemented.

Section 7.1 describes the cloning tree. Part of that concept is the 
cloning of policies. Again, since policies are for further study, I 
would avoid talking too much about them at this point. In fact, this 
cloning tree concept will probably need to be further described in the 
policies draft to be written in the future.

Nits:

Page 5, 3rd paragraph.
OLD:
A Binary Floor Control Protocol (BFCP)...

NEW:
A floor control protocol (e.g., BFCP)...

Figure 1: spacing problem on the right-most vertical line (which is made 
of dots).

Figure 2: the same type of spacing problem.

Cheers,

Gonzalo

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 25 Apr 2007 14:54:02 -0500

Hi Gonzalo,

Thanks for your comments - responses are embedded below [MB].

Mary

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Tuesday, April 24, 2007 7:39 AM
To: XCON
Cc: Barnes, Mary (RICH2:AR00)
Subject: Comments on draft-ietf-xcon-framework-07.txt

Hi,

the data model draft.

the same media type.

[MB] Good catch. That is a leftover from the removal of the template
concepts.  I think it should just read: "The common conference
information type is extensible." [/MB]

[MB] I agree that much of that section no longer fits based on the
discussion from IETF-68 (and this also impacts the last paragraph of
section 5).

Did we ever take that point to the mailing list as a conclusion or does
anyone have any concerns about removing this whole section and munging
section 5.1 into section 5 and having only a general statement about
policy?  I'll take this item as an issue to the mailing list, as I don't
think many people are going to read it here :) [/MB]

[MB] I still think we need this parent enforceable concept here, no
matter how we implement the policies.  I think this is one of the
reasons why I was one of the ones that did not want to remove all the
policy data from the data model (i.e., I think some of the basic
read/write and allowed sort of stuff may be necessary).  Again, I'll
take this point as part of the discussion of the issue to the list.
[/MB]

Nits:

[MB] I'll fix these in the -08. [/MB]

Page 5, 3rd paragraph.
OLD:

NEW:

of dots).

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Apr 2007 10:10:09 +0300

Hi Mary,

OK. Let's discuss the policy stuff separately at some point.

By the way, you did not given any answer to the first two comments of 
the email (the draft says that it defines a data model and it references 
RFC 2119).

Cheers,

Gonzalo

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 26 Apr 2007 07:59:03 -0500

Sorry, I did miss the first couple points.  I've embedded the responses
below [MB].  

Thanks,
Mary

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Thursday, April 26, 2007 2:10 AM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-xcon-framework-07.txt

Hi Mary,

RFC 2119).

Cheers,

Gonzalo

> the framework clearly states that the definition of the data model is
in
[MB] Obviously, the title and other references to a data  model predate
the data model draft.   This document does present the data model at a
high level as I think that's necessary to provide an idea of what the
conference object contains. I'm wondering if it wouldn't be okay to just
qualify the reference to data model as "high level data model" in the
abstract and introduction. Then, the next reference to data model (other
than definitions) is in section 5, where we do include the reference to
the data model document. [/MB]

> framework, that section can be removed.
[MB] There are actually lots of MUSTS and some SHOULDS in this document
but they're not all caps.  I can go in and add the caps. [/MB]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Apr 2007 12:53:24 +0300

Hi Mary,

> the data model document. [/MB]

I agree the framework should introduce the data model and maybe describe 
it at a high level. However, the framework should not state that it 
defines the data model. That would be confusing. The same way, the 
framework talks about floor control and BFCP but does not claim to 
define BFCP. Therefore, I would suggest that the framework clearly 
explains that the data model is defined elsewhere.

> but they're not all caps.  I can go in and add the caps. [/MB]

Is our intention to have an informational framework or a standards-track 
framework? What type of MUSTs and SHOULDs do you have in mind?

Thanks,

Gonzalo

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 30 Apr 2007 06:54:54 -0500

Hi Gonzalo,

[MB] I think I need to be more explicit here. I'm proposing to change
the text in the abstract as follows:
OLD:
   The Centralized Conferencing Framework defines logical entities 
   and naming conventions, along with a conferencing data model. 

NEW: 
   The Centralized Conferencing Framework defines logical entities 
   and naming conventions and introduces a high level conferencing data
model. 

and then mirroring that same change in the Introduction. 

I think it could also be made more clear by renaming Section 5 from: 
"Centralized Conferencing Data Model" to "Centralized Conferencing Data"
since as you suggest, this section isn't really defining a data model,
but rather describing the context for the conference object. 

And, then we can change the first sentence in that section as follows:
OLD:
   The centralized conference data model is logically represented by the
   conference object.

NEW: 
   The centralized conference data is logically represented by the
   conference object.

Note: that last sentence of the that first paragraph is already proposed
to be removed based on Oscar's comments. 

[/MB]

[MB] Per the response to Oscar and per the WG charter, this doc should
be Proposed Standard and I'll include that when I make the next revision
and update the template.  There are musts (and shoulds) right now that
aren't caps, such as: 
- Section 7.3: "Any desired changes must be targeted towards the active
conference. "
- Section 8.4: " This conference object ID must be included in all
   floor control messages. "
- Section 11: "The protocols used for
   manipulation and retrieval of confidential information MUST support a
   confidentiality and integrity mechanism."
Certainly, there's not alot, but I still think it's worthwhile to keep
the reference to 2119.
[/MB]

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 30 Apr 2007 15:37:11 +0300

Hi Mary,

> the text in the abstract as follows:

the changes you suggest sound sensible.

> - Section 7.3: "Any desired changes must be targeted towards the active

Section 7.3 describes an example and, thus, should not have normative 
statements.

>    floor control messages. "

This type of statement belongs to the floor control protocol specification.

>    confidentiality and integrity mechanism."

I do not think we need normative statements for this type of security 
stuff. The documents defining the individual parts (e.g., floor control, 
conference control) will take care of that. The framework document is 
useful to know how all those pieces fit together.

> Certainly, there's not alot, but I still think it's worthwhile to keep

If the normative statements we are going to be adding are all like the 
ones above, I would suggest making the framework an informational RFC.

Cheers,

Gonzalo

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 30 Apr 2007 10:56:56 -0500

Hi Gonzalo,

I don't have any issue with changing this to informational, although,
having the musts, shoulds all being in examples highlights perhaps the
need to have a call flow BCP type document.

I'll let the chairs let us know one way or the other. 

Thanks,
Mary

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Monday, April 30, 2007 7:37 AM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-xcon-framework-07.txt

Hi Mary,

>    floor control messages. "

This type of statement belongs to the floor control protocol
specification.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 30 Apr 2007 19:42:10 +0300

Hi,

sure, getting guidance from the chairs on the intended status would be 
great.

> need to have a call flow BCP type document.

The protocol specs (e.g., SIP, BFCP) already specify the interactions 
between nodes in the context of those protocols. A BCP along the lines 
you describe would be useful if the interactions between different 
protocols would be particularly complicated (e.g., which SIP message to 
send when a conference is terminated through the conference control 
protocol). However, I do not think the inter-protocol interactions we 
are dealing with in XCON are complicated enough to grant yet another 
specification. Or do you have a few scenarios in mind that may be 
difficult to understand for an implementer without a document with examples?

Cheers,

Gonzalo

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 30 Apr 2007 11:56:36 -0500

I don't think we need a BCP right now for the flows, but once we decide
the Conference Control Protocol, I think a BCP with flows (e.g., taking
some of the examples in the framework down to another level of detail)
would be very useful. 

Mary

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Monday, April 30, 2007 11:42 AM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-xcon-framework-07.txt

Hi,

difficult to understand for an implementer without a document with
examples?

Cheers,

Gonzalo

---

From: Alan Johnston <[email-masked]>
Date: Mon, 30 Apr 2007 21:15:40 -0500

Our working group charter lists the framework as a PS, not 
informational, and we did discuss it in Prague and agree to do that.

I do recall that in the SIPPING conferencing work, we ended up making 
the conference framework document informational and the cc-conferencing 
a BCP.  We could do something similar as Mary points out below.

A question - does the working group believe that implementors can just 
read BFCP, the common data model, the event package extension, and the 
future conference control protocol documents and be able to implement 
without reading the framework?  If so, that suggests the framework can 
be informational. If not, if there is significant overall detail in the 
framework, then we should not make it informational for the sake of 
implementors.

Thanks,
Alan