Subject: [Megaco] Issues discussion re Profiles handling

From: "Blatherwick, Peter" <[email-masked]>
Date: Thu, 1 Nov 2001 14:58:55 -0500

List: 

It sounds like there has been some progress at the SG-16 meetings on the topic of Profiles, specifically rules for what Profiles are allowed to define, and how they are defined, based on Christian Groves' proposal ("H.248v2 Profile Handling" AVD-2122) and comments on this list.  

Below is the relevant part of a thread that has been running as an aside between Christian and me on this topic, trying to resolve issues, and also containing Christian's summary of today's meeting.  As a great many of us cannot attend (myself included) we would like some feedback from the list.  

BTW, the proposal can be found at: ftp://standards.nortelnetworks.com/megaco/docs/Current/ITU-SG16/Dublin%20Contributions/AVD-2122.zip  See also the previous subject "Concerns re "H.248v2 Profile Handling", ITU proposal AVD-2122 ".

Peter Blatherwick 

-------------------------------------------------

...
The contribution was discussed in the meeting today and I did point out
that you had some misgivings with the contribution and these were taken
into account. So below is a bit of a summary how we handled the points. 

In breif we accepted several points 1-4 but these can be finessed with
clarifying text.

...
> Basically I don't want to extend the idea of profiles more than what has
> already been done. I do not think it is a worthwhile exercise to enhance
> the mechanism for subclassing etc. I'm interested in cleaning up what we
> have.
> 
> Thus I'd like to start getting some agreement with yourself on a few
> issues to progress the work.
> 
> 1) Update the binary version to also carry a name string - This is
> correcting an error to bring the text and binary in line. I hope you can
> agree on this.
> 
> [PB] Yup, seems like a thing to do, IG content.

[CHG] OK the SG16 meeting agreed to this.

> 
> 2) Addition of a section of IANA registration for Profile names to v2 so
> that we can avoid the problem of overlapping name space. This would
> cover what we have today. No protocol additions.
> 
> [PB] Definitely. The proposal looks pretty good there, but expect we need to settle other stuff to truly nail this.

[CHG] OK the SG16 meeting agreed to this. Obviously we can still make
updates.

> 
> 3) Addition of a section for some guidence of profile definition. Again
> this section only contains information from the various profiles we have
> today. If you compare this section in the contribution to what has been
> done in the MSF profiles and Q.1950 you'll see that they are very close.
> 
> [PB] Yes, though I don't think there's enough in your current proposal.  Specifically, it does not address whether subsets or supersets are allowed, how name conventions are to be defined, how to specify what packages go with what names, that a profile gives the MINIMUM requirements.  I will try to dig up some old stuff from "back in the day" prior to our dropping it at Washington.  Don't know if I still have it though, was done while at my former employer...

[CHG] Again the SG16 accepted this as a base. Tom indicated that he
wanted to add a couple of more heading ie. optional signalLists. It was
pointed out that this section only presented Profile Definition
framework for v1. It was agreed to that Profile Handling ie.
sub-classes, interactions between profiles was something for further
study. No deadline was placed on this.

> 
> 4) Add some text to 7.2.8 to better describe what happens with the
> returned profile. This text is highlighted in the contribution.
> 
> [PB] Again, yes, this need to be cleaned up.  However this needs to consider potential for larger scope.  I hope we can settle on the list whether we really want to allow for multiple simultaneous profiles in operation at one time.  Seems useful to me, but at the same time scares [deleted naughty word] out of me for interop reasons.  If we want to do this, we need to be exceedingly careful on definition process (which is where the layering would come in to my mind).  If we don't then I'm afraid I see greatly reduced value for doing multiple profile negotiation at all --- maybe useful for large MGs, but far less useful for residential/small office scaled ones which may be multiply capable (say analog + LS trunk).  As per my normal comment, I sure don't want to burden the small for the needs of the large.

[CHG] We removed the "s" from profiles and the text was accepted. So it
doesn't even smell of multiple profile support. The accepted text
doesn't lead us down a slippery slope.

> 
> Note: 1-4 cover exactly what we have today, no new functionality.
> Multiple profiles are not covered by this.
> 
> [PB] Don't really agree here.  Resolution of multiple profile is implied.  (Perhaps I am over-reading you here?  Do you really mean text to show how to handle a single profile ... which is somewhat there now, but not very tight.)
> 
> 5) A purely optional package that enables the MGC to find out what
> profiles the MG implements. As indicated the current servicechange
> procedures are used to agree on one profile.
> 
> [PB] Unhappy.  Packages can be made to work, certainly, and there is (by definition) no constraint to defining such a thing.  However I continue to feel this is not the right place, that we should be using the Profile parameter itself for this.  Amounts to the same thing (give or take parsing) but puts it in the right place.  (Of course, additional parsing would be required to support the special package anyway, just elsewhere.)  The problem I see with the package approach is it would create a linkage between a particular package interface and operation of the startup mechanism of the stack, which I see as quite undesirable.  Packages are for the applications to use, should not be tied to stack operation.
> 
> 6) Work towards a bigger new profile framework ie. subclassing etc for
> end
> 2002/start 2003. A new Megaco WG item for this. I'm not supportive of
> this work being done because I think it adds extra complexity but if we
> cover 1-4 and optionally 5 then i'd be prepared to be in the effort to
> further this work.
> 
> [PB] I think we are both actually saying this, but our time scales are calibrated differently.  I am concerned that the decisions we make now are going to mess us up in the future, so I'd rather tackle the problem space as a whole than in possibly disjoint nibbles.  If we truly need to get something done in very near term, I'd rather do the pragmatic steps 1-3 only.  If I read you correctly, I think step 4 is where the slippery slope begins.
> 
> [snip]

[CHG] I'll combine my response to 5 and 6. Others in the meeting
expressed their desire to support multiple profiles so the package was
accepted in principle. ie. read there needs to be quite a bit of work on
this before people agree. It would also need to done in conjunction with
the profile handling section. There is no scheduled completion date for
this. So this clears up the time frame issue.

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

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Wed, 7 Nov 2001 13:54:01 -0500

Could someone please summarize where the Profiles discussion ended at ITU SG-16 meetings last week?  

Have heard no feedback on below, good or bad, re proposed short term actions below towards Megaco v2, which if I understand correctly is basically a clean-up of what we have now including more precise wording of what is allowed, template for how to define it, and IANA process.  Avoids the complexities of multiple simultaneous profiles (or not) at least in near term work.  Therefore, I assume this is how we will proceed for now, with longer term thinking in parallel on the more complex stuff to be completed somewhat later (i.e. post ITU H.248v2).  

-- Peter

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: November 1, 2001 14:59
To: [email-masked]'
Cc: 'Christian Groves'; 'Tom-PT Taylor'
Subject: [Megaco] Issues discussion re Profiles handling

List: 

Peter Blatherwick 

...

...