Subject: RE: [Megaco] Re: Concerns re "H.248v2 Profile Handling", ITU prop osal AVD-2122

From: "Blatherwick, Peter" <[email-masked]>
Date: Tue, 30 Oct 2001 16:25:11 -0500

Further comments inserted in-line below.   -- Peter

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: October 30, 2001 12:02
To: Blatherwick, Peter
Cc: [email-masked]; 'Tom-PT Taylor'; Rosen, Brian
Subject: [Megaco] Re: Concerns re "H.248v2 Profile Handling", ITU
proposal AVD-2122

> G'Day Peter,

> Well I'm glad to see some comments :). 

> (On soapbox)
> I do not understand your problems with the ITU process. The
contributions are placed on the Pictel website where people can freely
download documents. Tom Taylor posted that these documents were stored
(and also on previous occasions). Thus people in the IETF have access to
the documents at the same time as those in Sg16. All discussion on email
regarding H.248/Megaco takes place on the IETF list. So if people
comment on the list it is also taken into consideration at the SG16
meeting. Tom attends SG16 and also puts the lists opinions across. I
also have trouble understanding this view as yourself and others on this
list have attended SG16 and know the procedures. (off soapbox)

[PB] Alas, I should not have mentioned the great process debate...  
Reality is, for me, I have much less access to the ITU process, and 
was not able to get my hands on the proposal until Tom moved it to 
the shared server.  Since I'm travel frozen, I cannot participate in 
the meeting-based decisions.  

> I will address your concerns below. Hopefully you will see that this
contribution isn't limiting anything people have done or limiting them
in the future and is fixing problems that we currently have with the
profile mechanism.

> Regards, Christian

>"Blatherwick, Peter" wrote:
>> 
>> Hello all:
>> 
>> I have some serious concerns regarding the ITU-T SG-16 proposal AVD-2122, "H.248v2 Profile Handling".  While I also have several more detail-level comments, my main concerns are over the appropriateness of a few of the basic concepts.  I believe that such a fundamental piece of the protocol deserves considerable in-depth analysis and discussion, so I hope we can bring it to this list for better resolution.  The ITU process for this proposal remains quite opaque for many of us, especially those suffering current travel and other budgetary restrictions. I would like to see Profile definition be a charter item for IETF Megaco WG, as proposed at IETF-51 by Brian Rosen and me, to be worked in conjunction with our colleagues in SG-16.

> [CHG] I'm all for comments for the list. I don't think we need to
charter a new item for profile definition. We already have profiles. The
problem is that they are poorly described.

[PB] Yes, unfortunately, the situation is we have profiles but not any 
rules on what they are and how they're defined.  In the case of a 
fundamental interop mechanism such as this, the rules are extremely 
important, maybe even more important than the actual syntax.  We 
decided to drop this from version 1, to be completed later when 
we had some experience to base it on.  (Perhaps Tom can comment 
on status of this item for re-chartering, based on our discussion 
and subsequent posting from IETF-51.)  

>> 
>> Before the list gets the impression I am entirely against this proposal, that is definitely not the case.  I certainly believe there is much hard thinking to do in the area of Profile definition, and strongly support the ideas of a clearly defined set of rules on what constitutes a Profile and what it is allowed to define, 

> [CHG] I agree, the current proposal tries to give a guideline on what
can be specified in a profile. The description of the headings are
examples thus people are free to choose what they need. If we tightly
specify a set of rules I suspect that we will have to update the IPPhone
profile and the MSF profiles to fit that.

[PB] Yes, I like that part.  Suggest more descriptive text will 
be required to define guidelines on what is allowed to be defined, 
along with the relatively loose template for profile descriptions 
docs.  This would not (or shouldn't at least) invalidate any 
existing profile.  Seems to be what you're getting at as well, so 
I think we agree here. (?)

>> a standardized method of documenting Profile definitions (along the
lines of current Package definitions), and a clear IANA process to avoid
name space clashes.  

> [CHG] Obviously I agree this needs to be done. The contribution does
propose an IANA registratiom mechanism but I don't think that this is
too hard. A name, version and possibly a reference is all that is
required. I can't see what more needs to be done here.

[PB] YES, IANA process is a good thing.  However, just what is 
submitted to IANA is secondary, driven by other decisions.  
Suggest we keep this in mind, but make decisions on specifics 
later.  

>> Just that I don't think we're there yet, and don't want to see a hasty
decision that leads us to entrenched approaches we will regret later.

> [CHG] Again I agree. I hope you can identify areas where this is the
case.

>> 
>> My primary concerns are:
>> 
>> 1) Use of a Package to define Profile support.  To my mind this is not the intent of Packages, so I would not want to see the concepts confused.  I also feel the two stage ServiceChange + Audit process this implies is less efficient than it could otherwise be.  While I understand the ITU mandate for backward compatibility, I believe there are other ways to achieve this, for example use of a simple list in the Profile parameter of ServiceChange.   Backward compatibility is good only if it works and the solution does not go against the core intent.

> [CHG] The package solution ensures that there doesn't need to be a
protocol syntax update. If people don't want to support multiple
profiles then they don't have to. Much like other packages. Having a
list in Servicechange would mandate that everyone has to support this,
which is clearly something that we don't want.

[PB] True, no specific syntax update, and that's a good goal.  
However, if the MGC does not support the special package, then we 
still have not achieved the goal of supporting multiple profile 
negotiation.  Use of a list I *think* could be made backward 
compatible in the sense that if a single profile is supported 
then the list is one item and looks the same as before.  
Something has to change for support of multiples, so I'd rather 
confine it to where it belongs conceptually.  

>> 
>> 2) Need for multiple Profiles.  It is not at all clear to me we actually need to support multiple Profiles in a single MG.  Support of multiple simultaneous Profiles opens up a very large potential for ambiguities and inconsistency issues between the Profiles, which is in my opinion very hazardous for interoperability.  

> [CHG] MGs will be developed that can support different scenarios. One MG
can support IP to ATM, IP to IP, Access to Trunk, Trunk to Trunk, Access
to Access etc. It is highly likely that a single
MG could support all of the MSF profiles. The mechanism proposed allows
the MGC to find out which profiles the MG supports and PICK ONE. ie. the
existing mechanism is retained. There are not multiple simultaneous
profiles being
used. 

[PB] Oops, did not catch the change, relative to previous 
proposal, that a single profile is selected in all cases.  
However, I then fail to see a major motivator to support multiples, 
which in my mind would be to allow an MG to announce it supports 
(say) both analog phone support and trunk support in the same box, 
then the MGC can do both at the same time, at the same gateway.  

>> Since Profiles are fundamentally intended to improve interoperability by
removing ambiguity, anything which potentially reduces this should be
considered suspect at best.  Even if we decide we do in fact need
multiple profiles, I would like to see a cleaner, more layered
mechanism, along the lines of the inheritance already defined for
Packages, to handle this.

> [CHG] I would be very hesitant having the concept of layered and
inherited profiles. The very concept of layering and inheritence would
mean that you do have to support simultaneous profiles.

[PB] I am also hesitant on this (multiple simultaneous profiles), 
but see layering/inheritance as a pretty decent way to manage it 
should we decide we want to.  For example, if we state rules that 
extended profiles cannot override their "superclass", then if 
profile X defines (say) ALF/UDP transport and binary encoding, and 
profile XX extends it, then profile XX cannot re-define transport 
and encoding but could for example define a naming convention and 
package support.  Similarly, if profile Y defines a naming convention, 
then profile YY which extends it could define a non-conflicting naming 
convention but is not allowed to alter or overlap the profile Y one.  
We may even be able to handle the real requirement (multi-functional 
MGs) and still be able to select a single profile at servicechange 
to accomplish this.  At least this simplifies the interop problem and 
would be similar in form to the way we do packages (which I believe 
works very well).  

>> 
>> 3) Possibly different mechanisms for text and binary encodings.  If I understand correctly (which may be dubious) at least one of the options would introduce further differences between text and binary encodings.  Such differences are already quite problematic, so I would certainly hope that we could find some way to make the mechanism identical under the two encoding schemes.

> [CHG] Currently there is an inconsistency between text and binary
encodings in H.248v1. This contribution in one option proposes to fix
the problem by having both the text and binary to have a textual name.
The other option maintains what is in version 1.

[PB] OK, will have a closer look -- I think I may have 
misunderstood.  That would be option 1 right?  We should certainly 
tend to favour any option that reduces inconsistencies.  (Uhh ... 
but doesn't that imply the dreaded syntax change? ;-) 

[snip]

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Tue, 30 Oct 2001 16:25:11 -0500

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: October 30, 2001 12:02
To: Blatherwick, Peter
Cc: [email-masked]; 'Tom-PT Taylor'; Rosen, Brian
Subject: [Megaco] Re: Concerns re "H.248v2 Profile Handling", ITU
proposal AVD-2122

case.

[snip]