Subject: [clue] CLUE framework extensibility

From: "Roni Even" <[email-masked]>
Date: Sat, 9 Jun 2012 08:07:41 +0300

Hi,

The discussion about the consumer supplied layout made me think about the
framework extensibility issue.

The framework document has section 10 saying that the framework is
extensible. 

What I think is missing is how do you extend the framework and how you mark
an extension. I assume that for new attributes or new procedure we will need
a document (is it a standard track document?) and we will need to update
section 10 accordingly. One issue is if each extension stands by itself with
an identifier or do we accumulate and have a new version of the framework or
data model. I prefer the first.

Another issue related to that is that we intend to verify (there was
consensus in the room at the interim meeting) that there will not be a
capability message that according to the initial proposal as presented in
IETF81

Initial message msc : consumer capability advertisement (AKA "the hint")

-       Physical factors

-       User preferences

-       Software limitations

-       etc.

So we do not have a way now to negotiate which extensions can be used by the
consumer and the provider.

I think that this should be addressed in the framework and if it is an
attribute is should be in the data model. 

Roni

---

From: Mary Barnes <[email-masked]>
Date: Sat, 9 Jun 2012 14:52:16 -0500

I think the extensibility is something that would be covered in the
solution document(s).  The framework is identifying the information that
must be exchanged and then the data model document defines that data.  We
don't yet know what the protocol will be that exchanges that data, but I
think both the protocol and data model is where extensibility is defined.

The discussion at the interim indicated that a majority of those present
wanted to remove the message, with 1/3 feeling that they had enough
information to decide, so as a chair.  We do need confirmation on the
mailing list, along with some discussion from those that are undecided and
input from folks that were not at the interim.  I will start a separate
thread.

Mary.

On Sat, Jun 9, 2012 at 12:07 AM, Roni Even <[email-masked]> wrote:

> Hi,****
> framework extensibility issue.****
>
> extensible. ****
> What I think is missing is how do you extend the framework and how you
> mark an extension. I assume that for new attributes or new procedure we
> will need a document (is it a standard track document?) and we will need to
> update section 10 accordingly. One issue is if each extension stands by
> itself with an identifier or do we accumulate and have a new version of the
> framework or data model. I prefer the first.****
>
> ** **
>
> IETF81****
> ** **
> Initial message msc : consumer capability advertisement (AKA "the hint")**
> **
>
> -       Physical factors****
>
> -       User preferences****
>
> -       Software limitations****
>
> -       etc.****
>
> ** **
>
> So we do not have a way now to negotiate which extensions can be used by
> the consumer and the provider.****
>
> ** **
>
> attribute is should be in the data model. ****
>
> Roni****
>
> ** **
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: "Roni Even" <[email-masked]>
Date: Sun, 10 Jun 2012 00:42:38 +0300

Mary,

You are right that the message should be in the solutions but the framework
should discussed the general mechanism. For example do we allow only
standard extensions or also vendor specific ones. Are we using extensions as
separate document or should extension go as a bis draft to the framework. 

As for the capability I think that Andy during the meeting said that the
purpose of capability was for software limitations and the vote was under
this assumption. I pointed out that the authors of the draft (Including
Andy) gave different information in the past and when posing the question it
should be clear what was the idea behind the message.

Thanks

Roni

From: Mary Barnes [mailto:[email-masked]] 
Sent: Saturday, June 09, 2012 10:52 PM
To: Roni Even
Cc: CLUE
Subject: Re: [clue] CLUE framework extensibility

I think the extensibility is something that would be covered in the solution
document(s).  The framework is identifying the information that must be
exchanged and then the data model document defines that data.  We don't yet
know what the protocol will be that exchanges that data, but I think both
the protocol and data model is where extensibility is defined.   

Mary.

Hi,

-       Physical factors

-       User preferences

-       Software limitations

-       etc.

Roni

---

From: Mary Barnes <[email-masked]>
Date: Sat, 9 Jun 2012 16:54:44 -0500

Sorry - there's a typo - should be "1/3 feeling that they did NOT have
enough information..."  - corrected below.

On Sat, Jun 9, 2012 at 2:52 PM, Mary Barnes <[email-masked]>wrote:

> wanted to remove the message, with 1/3 feeling that they did not have
> enough information to decide.  We do need confirmation on the mailing list,
> along with some discussion from those that are undecided and input from
> folks that were not at the interim.  I will start a separate thread.
>
> Mary.
>
>> Initial message msc : consumer capability advertisement (AKA "the hint")*
>> ***
>>
>> -       Physical factors****
>>
>> -       User preferences****
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 10 Jun 2012 10:43:03 +0200

I agree with Mary that the extensibility mechanism probably belongs in the solutions document.

I see this as an integral part of the protocol design - all protocols should be extensible.

As regards who should be allowed to extend, this will have to be taken on a case by case basis, and will come down to a discussion of interoperability versus extensibility concerns. We will be well into the protocol design before we will be in a position to discuss that.

I would only expect to see extensibility mentioned in the framework if we did not expect it to be extensible.

I have to add the caveat that I am still not sure in my own mind what the scope of the framework document is (and where it leaves off).

Regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: 09 June 2012 22:43
To: 'Mary Barnes'
Cc: 'CLUE'
Subject: Re: [clue] CLUE framework extensibility

Mary,
You are right that the message should be in the solutions but the framework should discussed the general mechanism. For example do we allow only standard extensions or also vendor specific ones. Are we using extensions as separate document or should extension go as a bis draft to the framework.

As for the capability I think that Andy during the meeting said that the purpose of capability was for software limitations and the vote was under this assumption. I pointed out that the authors of the draft (Including Andy) gave different information in the past and when posing the question it should be clear what was the idea behind the message.
Thanks
Roni

I think the extensibility is something that would be covered in the solution document(s).  The framework is identifying the information that must be exchanged and then the data model document defines that data.  We don't yet know what the protocol will be that exchanges that data, but I think both the protocol and data model is where extensibility is defined.

The discussion at the interim indicated that a majority of those present wanted to remove the message, with 1/3 feeling that they had enough information to decide, so as a chair.  We do need confirmation on the mailing list, along with some discussion from those that are undecided and input from folks that were not at the interim.  I will start a separate thread.

Mary.

On Sat, Jun 9, 2012 at 12:07 AM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
The discussion about the consumer supplied layout made me think about the framework extensibility issue.
The framework document has section 10 saying that the framework is extensible.
What I think is missing is how do you extend the framework and how you mark an extension. I assume that for new attributes or new procedure we will need a document (is it a standard track document?) and we will need to update section 10 accordingly. One issue is if each extension stands by itself with an identifier or do we accumulate and have a new version of the framework or data model. I prefer the first.

Another issue related to that is that we intend to verify (there was consensus in the room at the interim meeting) that there will not be a capability message that according to the initial proposal as presented in IETF81

So we do not have a way now to negotiate which extensions can be used by the consumer and the provider.

I think that this should be addressed in the framework and if it is an attribute is should be in the data model.
Roni

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Tue, 12 Jun 2012 13:52:43 +1000

I agree that this should be part of an integral protocol design. We need 
to consider extensibility for adding new features as well as version 
handling for changes to the base CLUE protocol whatever that turns out 
to be.

Regards, Christian

On 10/06/2012 6:43 PM, DRAGE, Keith (Keith) wrote:
> I see this as an integral part of the protocol design – all protocols 
> should be extensible.
>
> As regards who should be allowed to extend, this will have to be taken 
> on a case by case basis, and will come down to a discussion of 
> interoperability versus extensibility concerns. We will be well into 
> the protocol design before we will be in a position to discuss that.
>
> I have to add the caveat that I am still not sure in my own mind what 
> the scope of the framework document is (and where it leaves off).
>
> Regards
>
> Keith
>
> ------------------------------------------------------------------------
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Roni Even
> *Sent:* 09 June 2012 22:43
> *To:* 'Mary Barnes'
> *Cc:* 'CLUE'
> *Subject:* Re: [clue] CLUE framework extensibility
>
> Mary,
>
> You are right that the message should be in the solutions but the 
> framework should discussed the general mechanism. For example do we 
> allow only standard extensions or also vendor specific ones. Are we 
> using extensions as separate document or should extension go as a bis 
> draft to the framework.
>
> As for the capability I think that Andy during the meeting said that 
> the purpose of capability was for software limitations and the vote 
> was under this assumption. I pointed out that the authors of the draft 
> (Including Andy) gave different information in the past and when 
> posing the question it should be clear what was the idea behind the 
> message.
>
> Thanks
>
> Roni
>
> *From:*Mary Barnes [mailto:[email-masked]]
> *Sent:* Saturday, June 09, 2012 10:52 PM
> *To:* Roni Even
> *Cc:* CLUE
> *Subject:* Re: [clue] CLUE framework extensibility
>
> solution document(s). The framework is identifying the information 
> that must be exchanged and then the data model document defines that 
> data. We don't yet know what the protocol will be that exchanges that 
> data, but I think both the protocol and data model is where 
> extensibility is defined.
>
> The discussion at the interim indicated that a majority of those 
> present wanted to remove the message, with 1/3 feeling that they had 
> enough information to decide, so as a chair. We do need confirmation 
> on the mailing list, along with some discussion from those that are 
> undecided and input from folks that were not at the interim. I will 
> start a separate thread.
>
> Mary.
>
> mark an extension. I assume that for new attributes or new procedure 
> we will need a document (is it a standard track document?) and we will 
> need to update section 10 accordingly. One issue is if each extension 
> stands by itself with an identifier or do we accumulate and have a new 
> version of the framework or data model. I prefer the first.
>
> capability message that according to the initial proposal as presented 
> in IETF81
>
> -Physical factors
> -User preferences
> -Software limitations
> -etc.
> [email-masked] <mailto:[email-masked]>