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

---

From: Christian Groves <[email-masked]>
Date: Wed, 31 Oct 2001 04:01:53 +1100

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)

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

> 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 appropriat…

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

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

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.

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.

> 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 pro…

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

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

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.

> 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 bi…

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 31 Oct 2001 04:01:53 +1100

G'Day Peter,

(On soapbox)

Regards, Christian