Subject: [Megaco] Concerns re "H.248v2 Profile Handling", ITU proposal AVD-2122

From: "Blatherwick, Peter" <[email-masked]>
Date: Tue, 30 Oct 2001 10:30:38 -0500

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.  

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, a standardized method of documenting Profile definitions (along the lines of current Package definitions), and a clear IANA process to avoid name space clashes.  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.  

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.  

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.  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.  

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.  

I do apologize that this does not come a bit earlier.  However, like many I suspect, I have difficulty keeping track of and accessing ITU-specific documents such as this proposal.  

Lets hear those comments, counter-arguments, and flames!  

-- Peter Blatherwick

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