Re: [Megaco] Contribution AVD-2173 -- Implications Of Context At tribute Descri ptors
You're undoubtedly right on date -- the great IETF legal intercept debate occurred in the fall, following Megaco discussion of the same topic. I had Red Bank in mind, but this is one thing that didn't happen in Red Bank. Nevertheless, the fact that contributions are going in to the present meeting to fill in gaps kind of makes my point. We really didn't think context properties through, so that up to now they haven't had the same solid foundation as termination properties. I'm arguing we need more time to think through the semantic issues at the least, and to make sure that the protocol aspects are as regular as we can make them. Agreed that you can't drop existing properties on the floor. But we can do something like requiring that the new form be used when later-version implementations are talking to each other. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Thursday, October 25, 2001 9:08 PM To: Taylor, Tom-PT [CAR:B881:EXCH] Cc: 'megaco@ietf.org'; 'itu-sg16@mailbag.intel.com' Subject: Re: [Megaco] Contribution AVD-2173 -- Implications Of Context Attribute Descri ptors G'Day Tom, For the record context properties were added in August 1999, to put that in context (pardon the pun) the handling of "context" (ie. linking, unlinking) was still being discussed in May 1999. So I don't think it was a last minute addition. I believe that with the contribution to this meeting (AVD-2120) and the ones to the previous meeting on this topic address the concerns in your bullet points. These use already established methods in H.248 to achieve your points (obviously there are some syntax additions). Can you please give some specific examples of what is not covered? Regarding the deprecation of existing context properties I believe this is pretty much out of the question as these are being used in implementations today. Regards, Christian Tom-PT Taylor wrote:
My apologies for the late delivery of this contribution. For the moment
locked out of the PictureTel server, so here's the text:
TITLE: Implications Of Context Attribute Descriptors
___________________
Summary
This contribution is written to express concern over the proposed inclusion of context attribute descriptors in H.248v2. This innovation is seen upon reflection as a major change in the H.248 protocol architecture, and threatens the coherence of the protocol. It is proposed as an alternative that we gain further experience by seeing if it is possible to avoid the specification of new context properties while solving the problems of MCU decomposition. When we are satisfied that we can enunciate clear criteria for adding properties to contexts as opposed to terminations and further, that we are aware of all of the implications of context properties for the protocol, we can proceed to update the protocol accordingly.
1. Introduction
H.248v1 defines three context properties: the Topology Descriptor, the Emergency flag, and the Priority flag. These additions were desirable, but were made at a fairly late stage in the development of the protocol. As a result, the work was done in an ad hoc manner and introduced irregularities into the operation of the protocol.
Delayed Contribution 129 (Porto Seguro) proposed the introduction of a context attributes descriptor to contain new context properties and to allow addition of such properties in packages. On the one hand, the present contribution argues that this step, while desirable, does not go far enough to assimilate context properties into the overall protocol structure. On the other hand, introduction of the ability to define context properties in packages at this stage in the development of the protocol may cause confusion and threaten protocol interoperability at a practical level.
2. A Complete Implementation Of Context Properties
A complete implementation of context properties requires that the protocol satisfy the following requirements: * there is a well-defined method for setting property values; * there is a well-defined method for modifying or clearing property values; * there is a well-defined method for auditing values that have been set on a context; * it would be highly desirable to have a method for determining what context properties an MG supports.
Beyond these protocol matters come questions of semantics. We must decide whether the permissible properties of a context can depend on what media are flowing in it, or on the properties of the terminations currently in the context. Since the active streams are a property of a context, we must decide whether context properties can be associated with specific streams, and if so, what syntax is used for the purpose. There are undoubtedly other issues which may come to light.
As a possibly controversial final step, it would seem desirable to assimilate the existing context properties into the new syntactic structures which would evolve. With appropriate requirements for transitional interworking, the existing syntax for topology and the emergency and priority flags should be deprecated and counterparts should be defined within the context attribute descriptor.
3. Potential Confusion
The final point this contribution makes is that if we do not establish a clear definition within the protocol specification of which properties should be context attributes and which should be termination properties, packages will inevitably be defined which solve the same problem with differing mechanisms. This will be unhelpful to achieving the interoperability of different implementations.
4. Conclusion and Proposal
Context attributes should be formalized only after careful study of all of the issues. In concrete terms, this contribution proposes either that the generalization of context attributes should be left to H.248v3 or else
I'm that
H.248v2 be delayed beyond the proposed February 2002 target.
Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)
_______________________________________________ Megaco mailing list Megaco@ietf.org http://www1.ietf.org/mailman/listinfo/megaco
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
G'Day Tom, I don't see how additional contributions makes your point. The contributions are for the new mechanism of context properties added by packages. The idea of a standards process is that you build up functionality from meeting to meeting, these are simply building the functionality proposed. People have had since August 1999 to think of problems with context properties. Rather than asking for an indefinite extension to think and requesting that context properties be removed because there might be something hidden, I would like some concrete examples of the problems. I'll start travelling to the Dublin meeting soon so perhaps we can discuss further then. Regards, Christian Tom-PT Taylor wrote:
You're undoubtedly right on date -- the great IETF legal intercept debate occurred in the fall, following Megaco discussion of the same topic. I had Red Bank in mind, but this is one thing that didn't happen in Red Bank.
Nevertheless, the fact that contributions are going in to the present meeting to fill in gaps kind of makes my point. We really didn't think context properties through, so that up to now they haven't had the same solid foundation as termination properties. I'm arguing we need more time to think through the semantic issues at the least, and to make sure that the protocol aspects are as regular as we can make them.
Agreed that you can't drop existing properties on the floor. But we can do something like requiring that the new form be used when later-version implementations are talking to each other.
-----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Thursday, October 25, 2001 9:08 PM To: Taylor, Tom-PT [CAR:B881:EXCH] Cc: 'megaco@ietf.org'; 'itu-sg16@mailbag.intel.com' Subject: Re: [Megaco] Contribution AVD-2173 -- Implications Of Context Attribute Descri ptors
G'Day Tom,
For the record context properties were added in August 1999, to put that in context (pardon the pun) the handling of "context" (ie. linking, unlinking) was still being discussed in May 1999. So I don't think it was a last minute addition.
I believe that with the contribution to this meeting (AVD-2120) and the ones to the previous meeting on this topic address the concerns in your bullet points. These use already established methods in H.248 to achieve your points (obviously there are some syntax additions). Can you please give some specific examples of what is not covered?
Regarding the deprecation of existing context properties I believe this is pretty much out of the question as these are being used in implementations today.
Regards, Christian
Tom-PT Taylor wrote:
My apologies for the late delivery of this contribution. For the moment
locked out of the PictureTel server, so here's the text:
TITLE: Implications Of Context Attribute Descriptors
___________________
Summary
This contribution is written to express concern over the proposed inclusion of context attribute descriptors in H.248v2. This innovation is seen upon reflection as a major change in the H.248 protocol architecture, and threatens the coherence of the protocol. It is proposed as an alternative that we gain further experience by seeing if it is possible to avoid the specification of new context properties while solving the problems of MCU decomposition. When we are satisfied that we can enunciate clear criteria for adding properties to contexts as opposed to terminations and further, that we are aware of all of the implications of context properties for the protocol, we can proceed to update the protocol accordingly.
1. Introduction
H.248v1 defines three context properties: the Topology Descriptor, the Emergency flag, and the Priority flag. These additions were desirable, but were made at a fairly late stage in the development of the protocol. As a result, the work was done in an ad hoc manner and introduced irregularities into the operation of the protocol.
Delayed Contribution 129 (Porto Seguro) proposed the introduction of a context attributes descriptor to contain new context properties and to allow addition of such properties in packages. On the one hand, the present contribution argues that this step, while desirable, does not go far enough to assimilate context properties into the overall protocol structure. On the other hand, introduction of the ability to define context properties in packages at this stage in the development of the protocol may cause confusion and threaten protocol interoperability at a practical level.
2. A Complete Implementation Of Context Properties
A complete implementation of context properties requires that the protocol satisfy the following requirements: * there is a well-defined method for setting property values; * there is a well-defined method for modifying or clearing property values; * there is a well-defined method for auditing values that have been set on a context; * it would be highly desirable to have a method for determining what context properties an MG supports.
Beyond these protocol matters come questions of semantics. We must decide whether the permissible properties of a context can depend on what media are flowing in it, or on the properties of the terminations currently in the context. Since the active streams are a property of a context, we must decide whether context properties can be associated with specific streams, and if so, what syntax is used for the purpose. There are undoubtedly other issues which may come to light.
As a possibly controversial final step, it would seem desirable to assimilate the existing context properties into the new syntactic structures which would evolve. With appropriate requirements for transitional interworking, the existing syntax for topology and the emergency and priority flags should be deprecated and counterparts should be defined within the context attribute descriptor.
3. Potential Confusion
The final point this contribution makes is that if we do not establish a clear definition within the protocol specification of which properties should be context attributes and which should be termination properties, packages will inevitably be defined which solve the same problem with differing mechanisms. This will be unhelpful to achieving the interoperability of different implementations.
4. Conclusion and Proposal
Context attributes should be formalized only after careful study of all of the issues. In concrete terms, this contribution proposes either that the generalization of context attributes should be left to H.248v3 or else
I'm that
H.248v2 be delayed beyond the proposed February 2002 target.
Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)
_______________________________________________ Megaco mailing list Megaco@ietf.org http://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________ Megaco mailing list Megaco@ietf.org http://www1.ietf.org/mailman/listinfo/megaco
participants (2)
-
Christian Groves -
Tom-PT Taylor