The initial registration command must be *encoded* as version 1 -- this is to ensure that the MG will not confuse a MGC that is on an earlier version of the protocol. But once the protocol is negotiated, then all subsequent messaging can be in whatever the negotiated version happens to be.
Kevin
________________________________
From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Yangbo Lin Sent: Tuesday, June 26, 2007 4:06 AM To: Schwarz Albrecht; Christian.Groves@nteczone.com Cc: Jerker Zetterlund (TN/EAB; itu-sg16@lists.packetizer.com; Juergen.Stoetzer-Bradler@alcatel-lucent.de; CWaitzmann@alcatel-lucent.de Subject: Re: [itu-sg16] C-277: H.248.1 Compatibility
Hello Albrecht,
I have a question about one sentence in the added text proposed by you -- "Any MG registration is starting with protocol version 1", why is only version 1 instead of 2 or 3? In my understanding, it depends on the highest version implemented by MG.
Regards, Yangbo
----- Original Message ----- From: Schwarz Albrecht mailto:Albrecht.Schwarz@alcatel-lucent.de To: Christian.Groves@nteczone.com mailto:Christian.Groves@nteczone.com Cc: itu-sg16@lists.packetizer.com mailto:itu-sg16@lists.packetizer.com ; linyangbo@huawei.com mailto:linyangbo@huawei.com ; CWaitzmann@alcatel-lucent.de mailto:CWaitzmann@alcatel-lucent.de ; Juergen.Stoetzer-Bradler@alcatel-lucent.de mailto:Juergen.Stoetzer-Bradler@alcatel-lucent.de ; Jerker Zetterlund (TN/EAB mailto:jerker.zetterlund@ericsson.com Sent: Monday, June 25, 2007 7:43 PM Subject: C-277: H.248.1 Compatibility
Hello Christian, all,
like the proposal concerning forward & backward compatibility rules. Did add some text with regards to the compatibilty mechanism(s), which are specific to H.248 (and thus worth to be mentioned).
Best regards, Albrecht
<<T05-SG16-C-0277r1 H.248 Compatibility.doc>> ####
Hello Albrecht, Keith,
Thanks for the reference to Q.1400. I think it was these fundamentals of compatibility for ISUP and DSS that lead to the original definition of the version negotiation and protocol enhancement rules in H.248.1. At the time of writing H.248.1v1 there was involvement from a number of people involved in the work of SG11.
I think the general principles of Q.1400 are in-line with what is being used in H.248.1 so at this level it can be used. I agree some of the specific examples aren't relevant for H.248.1. I'll try to propose some clarifying text for the Q.3/16 meeting. I don't intend to write a thesis on the matter, I intend to stick making simple rules applicable for protocol, packages and profiles.
Regards, Christian
Albrecht Schwarz wrote: > [Like to open a separate thread on compatibility rules for H.248, think > this is a more general topic in comparison to the Ia specific IP realm > indication mechanism.] > > Keith, thanks for the pointer to Q.1400, believe that the clause about > compatibility rules is a good baseline for correspondent definitions for > H.248. > I think additional explicit text about compatibility rules in H.248.1, e.g. > in clause 12, would be beneficial. > > We may not directly reuse Q.1400 for H.248 (in my understanding) because > a) Q.1400 is for ASN.1 defined protocols (and H.248 has also ANBF defined > grammar for text encoding mode), > b) Q.1400 focus is SS7 and DSS1, or > c) H.248 integrated version/profile mechanisms. > > Christian, think that your proposal is a good baseline. Could you submit it > as input to next Q.3/16 meeting? > > Albrecht > > > >
> "Drage, Keith
> (Keith)" To: "Schwarz, Albrecht (Albrecht)" albrecht.schwarz@alcatel-lucent.de,
> <drage@alcatel-l TISPAN_WG3@LIST.ETSI.ORG
> ucent.com> cc:
> Subject: RE: H.248 Ia Profile Version 2
> 24.04.2007 12:07
>
> > > > > The compatibility definitions in ITU-T are all in Q.1400. > > Regards > > Keith > > >> -----Original Message----- >> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE ] >> Sent: Tuesday, April 24, 2007 1:08 AM >> To: TISPAN_WG3@LIST.ETSI.ORG >> Subject: Re: H.248 Ia Profile Version 2 >> >> Bruno >> >> >>> My understanding is that backward compatibility in the work item >>> >> description was intended to refer to the ability >> >>> for version n+1 to understand version n without requiring version >>> >> negotiation to occur before. This is usually what >> >>> is meant in other ITU-T and ETSI standards dealing with signalling. >>> >> Couldn't find any appropriate definition for "backward >> compatibility" in ITU-T & ETSI (like the one for codecs from H.262). >> >> There are signalling protocols with and without a version >> negotiation mechanism. The understanding of "backward >> compatibility" might be slightly different for both >> categories. Guess the protocols without a version negotiation >> method are the majority like the capability set based ITU-T >> protocols like e.g. INAP, BICC or Q.2630.x. >> H.248 belongs to the category with an >> a) integral mechanism for protocol version negotiation and in >> addition a >> b) mechanism for profile negotiation >> and also >> c) a multi profile mode capability (H.248.18). >> >> The used protocol capabilities are related to the lifetime of >> the H.248 Control Association (CA), starting the negotiation >> at CA establishment. >> Capability upgrade procedures may lead to a re-new or >> re-establishment of the CA. >> >> A definition for "backward compatibility" for H.248 CAs might >> therefore different to other protocols without such mechanisms. >> >> We got four WIs for H.248 Profiles, - a MG registration with >> the correspondent ProfileID is part of a profile specification. >> Saying that, the meaning of backward compatibility in the WI >> description means that the MG registers with Ia/2 in my opinion. >> In case of a fallback requirement to Ia/1, then current draft >> my be extended for H.248.18 support (but this requires a >> contribution). >> >> Albrecht >> >> >> >> >> >> >> >> Christian Groves >> >> >> <Christian.Groves@NT To: >> TISPAN_WG3@LIST.ETSI.ORG >> >> ECZONE.COM> cc: >> >> >> Subject: >> Re: H.248 Ia Profile Version 2 >> >> 23.04.2007 09:55 >> >> >> Please respond to >> >> >> Christian Groves >> >> >> >> >> >> >> >> >> >> Hello Bruno, >> >> What does "ability for version n+1 to understand version n" >> mean? Even in the scenario we are talking about a MG with a >> version n+1 control association will understand the version n >> message because the encoding has not changed (thus backwards >> compatible by the definition below) but it will reject it >> because of new required functionality. Likewise it seems that >> "before version negotiation" has been prompted by the email >> discussion. For some, such mechanisms are integral for >> compatibility mechanisms. >> >> Do you have a reference to a general description of "backwards >> compatibility"? The term is used alot but I don't know any >> description >> other than that in H.248.1. For example H.248.1 section 11.3 >> Negotiation of Protocol Version offers rules for new versions. ie. >> >> /When extending the protocol with new versions, the >> following rules >> should be followed:/ >> /1) Existing protocol elements, i.e., procedures, parameters, >> descriptor, property, values, should/ >> /not be changed unless a protocol error needs to be >> corrected or it >> becomes necessary to/ >> /change the operation of the service that is being >> supported by the >> protocol./ >> /2) The semantics of a command, a parameter, a descriptor, a >> property, or a value should not be/ >> /changed./ >> /3) Established rules for formatting and encoding messages and >> parameters should not be/ >> /modified./ >> /4) When information elements are found to be obsolete they can be >> marked as not used./ >> /However, the identifier for that information element >> will be marked >> as reserved. In that way/ >> /it cannot be used in future versions./ >> >> These rules were adopted to ensure backwards compatibility. I >> think these rules are equally applicable to the case of >> profiles. When the MGC and MG agree on the use of a control >> association they agree on the >> H.248.1 version and the profile (including version). >> >> Regards, Christian >> >> CHATRAS Bruno RD-CORE-ISS wrote: >> >>> Hello Chirstian, >>> >>> My understanding is that backward compatibility in the work item >>> >> description was intended to refer to the ability for version >> n+1 to understand version n without requiring version >> negotiation to occur before. >> This is usually what is meant in other ITU-T and ETSI >> standards dealing with signalling. >> >>> Best Regards, >>> Bruno >>> >>> -----Message d'origine----- >>> De : Christian Groves [mailto:Christian.Groves@NTECZONE.COM mailto:Christian.Groves@NTECZONE.COM ] >>> Envoyé : lundi 23 avril 2007 02:58 >>> À : TISPAN_WG3@LIST.ETSI.ORG >>> Objet : Re: H.248 Ia Profile Version 2 >>> >>> Hello Bruno, >>> >>> What was the definition of "backward compatibility" that >>> >> the work item >> description assumed? It seems that people have different >> interpretations. >> >>> Regards, Christian >>> >>> CHATRAS Bruno RD-CORE-ISS wrote: >>> >>> >>>> This is version negotiation, not backward compatibility.... Both >>>> >> approaches are valid protocol design approaches and have >> their pros and cons. However, the Work Item description >> assumed "backward compatibility between version 1 and 2... >> >>>> -----Message d'origine----- >>>> De : Neal ZhuNing [mailto:zhuning@HUAWEI.COM mailto:zhuning@HUAWEI.COM ] Envoyé : vendredi 20 >>>> avril 2007 04:09 À : TISPAN_WG3@LIST.ETSI.ORG Objet : Re: H.248 Ia >>>> Profile Version 2 >>>> >>>> Agree Albrecht's state. >>>> When a BGF registers with a ProfileID "ETSI_BGF/1" 0r >>>> "ETSI_BGF/2", >>>> >> corresponding ia profile(ia/2 or ia/1) should be applied. >> >>>> I think the Profile-based backward compatibility >>>> >> between ia/2 and >> ia/1 is based on their functions. Ia/2 can realize all the >> functions of Ia/1, but new better methods can be used, even >> it is mandatory. >> >>>> BR >>>> Neal >>>> >>>> -----Original Message----- >>>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE ] >>>> Sent: Thursday, April 19, 2007 6:50 PM >>>> To: TISPAN_WG3@LIST.ETSI.ORG >>>> Subject: Re: H.248 Ia Profile Version 2 >>>> >>>> [Sorry for using your initials as abbreviation BC for backward >>>> compatibility :-)] >>>> >>>> I do agree to your statement. >>>> >>>> Important here is the "scope of the protocol" in my understanding. >>>> There would be a compatibility issue when the SPDF & BGF would >>>> operate >>>> >> Ia interface in the "NoProfile" mode, i.e. the BGF would not >> include the ServiceChangeProfile parameter for registration. >> >>>> But the protocol scope is limited when registering with a >>>> >> ProfileID >> >>>> (as >>>> >> in case of ES 283 018). There are then only "ETSI_BGF/1" or >> "ETSI_BGF/2" >> >>>> H.248 Messages between a single SPDF-BGF tandem. >>>> >>>> I think that this is the crucial point concerning "protcol >>>> >> scope" for >> >>>> H.248 >>>> interface: "Profile-less" vs "Profile-based" operated H.248 Control >>>> >> Associations. >> >>>> Albrecht >>>> >>>> >>>> >>>> >>>> >>>> "CHATRAS Bruno >>>> >>>> RD-CORE-ISS" To: >>>> >> "Neal >> >>>> ZhuNing" zhuning@huawei.com, Albrecht.Schwarz@ALCATEL-LUCENT.DE >>>> <bruno.chatras@orange-f cc: >>>> TISPAN_WG3@LIST.ETSI.ORG >>>> >>>> tgroup.com> >>>> >> Subject: RE: H.248 >> Ia >> >>>> Profile Version 2 >>>> >>>> >>>> 19.04.2007 12:28 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Adding a mandatory parameter to version n+1 of a protocol >>>> >> means that >> >>>> a >>>> >> message conforming to the version n of this protocol is not a >> valid message for an implementation conforming to version n+1 >> of this protocol. Is not this a compatobility issue? >> >>>> BC >>>> >>>> -----Message d'origine----- >>>> De : Neal ZhuNing [mailto:zhuning@huawei.com mailto:zhuning@huawei.com ] Envoyé : >>>> >> jeudi 19 avril >> >>>> 2007 11:55 À : Albrecht.Schwarz@ALCATEL-LUCENT.DE; CHATRAS Bruno >>>> RD-CORE-ISS Cc : TISPAN_WG3@LIST.ETSI.ORG Objet : RE: H.248 Ia >>>> Profile Version 2 >>>> >>>> Hi Albrecht, Bruno, >>>> In Ia/1, the hierarchical termination name does not specifically >>>> >> mention that it is used to identify the IP domain that a >> termination is connected to, nor does it give an example of >> the syntax associated with the "interface". So maybe there is >> no backward compatibility on this issue. >> >>>> In Ia/2, the hierarchical termination name may still be used to >>>> >> specify which physical or logical interface a termination >> should be associated with in the MG. >> >>>> So, the hierarchical termination name mechanism is same in Ia/1 and >>>> >> Ia/2, there is no backward compatibility problem. >> >>>> BR >>>> Neal >>>> >>>> -----Original Message----- >>>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE ] >>>> Sent: Thursday, April 19, 2007 5:21 PM >>>> To: TISPAN_WG3@LIST.ETSI.ORG >>>> Subject: Re: H.248 Ia Profile Version 2 >>>> >>>> Bruno, >>>> when we discussed this, we couldn't see a violation of the backward >>>> >> compatibility (BC) principle. >> >>>> The MG is registering either with Ia/1 or Ia/2, but not with both >>>> >> profile versions (like in a multiple profile mode), the used >> IP realm/domain indication mechanism is unambiguous. >> >>>> The profile principle is thus supporting BC targets. >>>> A single H.248 Control Association is either operated with >>>> >> Ia/1 or Ia/2. >> >>>> Do I overlook sth? >>>> >>>> Albrecht >>>> >>>> PS >>>> Above principle is/may also used for other "capability upgrades", >>>> like H.248.10 replacement by H.248.11 in a next profile >>>> >> version, etc >> >>>> etc >>>> >>>> >>>> >>>> >>>> >>>> CHATRAS Bruno >>>> >>>> RD-CORE-ISS To: >>>> TISPAN_WG3@LIST.ETSI.ORG >>>> >>>> <bruno.chatras@ORANGE-F cc: >>>> >>>> TGROUP.COM> >>>> >> Subject: H.248 Ia >> >>>> Profile Version 2 >>>> >>>> >>>> 19.04.2007 11:12 >>>> >>>> Please respond to >>>> >>>> CHATRAS Bruno >>>> >>>> RD-CORE-ISS >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Ray, Wayne, >>>> >>>> I just had a look to the Latest Draft of WI03098 (Ia >>>> >> profile Release >> >>>> 2) >>>> >> and saw that support of the new IPDC package is mandatory >> rather than optional. >> >>>> This contradicts the Work Item description which says >>>> >> explictly that >> "The Ia profile version 2 shall maintain backwards >> compatibility with version 1." The meeting reports says that >> adding the IPDC package was indeed agreed but does not say >> whether it should be mandatory or optional. >> I believe that we should either make this package optional or >> made an attempt to modify the Work Item description. I assume >> we can't approve a deliverable which explicitly contradicts a >> Work Item description. >> >>>> BTW, what is the procedure for TB approval of this modification. >>>> There >>>> >> does not seem to be any CR corresponding to this modification >> (just a contribution). >> >>>> Best regards >>>> Bruno >>>> >>>>
####
Christian Groves Christian.Groves@nteczone.com
08.05.2007 08:31
To: CHATRAS Bruno RD-CORE-ISS bruno.chatras@orange-ftgroup.com cc: "Wayne Cutler (CV/ETL)" wayne.cutler@ericsson.com, Neal ZhuNing zhuning@huawei.com, "Jerker Zetterlund (TN/EAB)" jerker.zetterlund@ericsson.com, seppo.kauntola@nsn.com, Albrecht.Schwarz@alcatel-lucent.de, CWaitzmann@alcatel-lucent.de, smaoui@nortel.com, Lin Yangbo linyangbo@huawei.com, Tommy Young tommy@huawei.com
Subject: Re: H.248 Ia Profile Version 2
Hello Bruno, all,
With regards to linking Tispan releases to profile versions I see that adding optional elements to the profiles is the same as adding then to packages, the version number is stepped. At least you then know the capabilities have changed and the new optional features are available to be used.
On the IPDC issues based on your response I've attached some proposed marked up changes to ES283 018 (13bTD108r3). For me at least the distinction is where the MGC knows the actual IPdomain its uses the IP realm identifier, where it doesn't its uses the terminationId and lets the MG decide.
Other suggestions welcome.
Regards, Christian
CHATRAS Bruno RD-CORE-ISS wrote: > Yes I want to contrinue using implicit IP domain signalling. I want to be able to use new optional features brought by TISPAN Release 2 while continuing to use the existing mechanism for IP domain signalling. Actually I'm wondering wheter it was not a mistake to assume from the beginning TISPAN Release x maps to Profile Version x. It would certarinly be more efficient to have several releases mapping to the same Profile version with additional optional capabilties added over the releases...
> > To answer your question, I think that the MGC does not need to know the IP Domain nor the IP address pool. It just needs to tell the MG on which "side" of the box the termination should be created. It is then up to the MG to derive the IP Domain and associated address pool to us.
> > Having said that, I still think that adding a mandatory element to version N+1 of a protocol/profile means that versnion N+1 is not backward compatible with version N.
> > Best Regards > Bruno > > > -----Message d'origine----- > De : Christian Groves [mailto:Christian.Groves@nteczone.com mailto:Christian.Groves@nteczone.com ] > Envoyé : lundi 30 avril 2007 07:33 > À : Wayne Cutler (CV/ETL); CHATRAS Bruno RD-CORE-ISS > Cc : Neal ZhuNing; Jerker Zetterlund (TN/EAB); seppo.kauntola@nsn.com; Albrecht.Schwarz@alcatel-lucent.de; CWaitzmann@alcatel-lucent.de; smaoui@nortel.com; Lin Yangbo; Tommy Young
> Objet : Re: H.248 Ia Profile Version 2 > > Hello all, > > I don't agree with the assertion that there is no need for compatibility between version of profiles. I guess I'm old fashioned, to me a version change is applied to a protocol whenever there is a change (as Wayne suggests). As I've posted before H.248.1 sect 11.3 outlines rules for up versioning the H.248 protocol. These rules have been/are applied to up-versioning of packages and I don't see why they are not applicable to
> H.248 profile specifications. If you want to make changes that aren't compatible then you can use a new profile name. As Albrecht has suggested I will contribute to the next Q.3/16 meeting on this. I also agree with Wayne's email I don't see this change is a break of compatibility.
> > I do think this backwards compatibility issue is distracting from the real issue however. > > It seems to me Bruno's real issue is that he wants to continue to use "implicit IP domain signalling" e.g. via the interface field in V2 without having to use H.248.41. Is this correct Bruno? If so then before I make a proposal along those lines I have a question about your comment:
> > /2/ If the IP realm identifier is received by the BGF, it shall take > precedence over any IP realm that may be derived from (or associated > to) the interface identifier./ > > In the case of Ia v1 where do you see this association between the interfaceID and IP realm being set? Does the MGC know which FQDN IP realm the termination will be connected to when it requests an interface ID?, or is the IP realm only known by the MG and may be assigned as a consequence of a request for a particular interface?
> > Regards, Christian > > PS: Just to be clear when I talk about IP realm I mean a FQDN. > > Wayne Cutler (CV/ETL) wrote: > >> Hi Bruno et al, >> >> I think that the fact that we are stepping the version of Ia from 1 to >> 2 means that something has changed - else we would not step the >> version. More specifically, I think that it means that some additional >> mandatory fucntions have been added >> - and this translates in H248 as the addition of extra mandatory >> packages. >> >> When a version is stepped, the key point IMO is that no functionality >> is lost (i.e the upissued box can't be less capable than its old >> version). It is OK to add new functionality and also be able to >> realise previous functionality in a different way. As long as this >> difference is clearly described and understood, then this is not a >> problem. In this particular case, Ia v2 has added the new ipdc package >> but also maintained the termination naming scheme from Ia v1. So, I >> don't think there's a practical problem. >> >> Finally, given the way in which H248 allows a profile negotiation as >> part of its SC procedures, I don't think there is a scenario where Ia >> v2 needs to "interwork" with Ia v1. >> >> Regards, Wayne >> >> ---------------------------------------------------------------------- >> -- >> *From:* CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@orange-ftgroup.com mailto:bruno.chatras@orange-ftgroup.com ] >> *Sent:* 25 April 2007 09:52 >> *To:* Neal ZhuNing; Jerker Zetterlund (TN/EAB) >> *Cc:* seppo.kauntola@nsn.com; Wayne Cutler (CV/ETL); >> Albrecht.Schwarz@alcatel-lucent.de; CWaitzmann@alcatel-lucent.de; >> smaoui@nortel.com; Christian Groves; Lin Yangbo; Tommy Young >> *Subject:* RE: H.248 Ia Profile Version 2 >> >> Interesting... It's the first time I read an explicit statement from >> an ETSI member that interoperability between versions of ETSI >> standards is unreasonable!!! >> >> ---------------------------------------------------------------------- >> -- *De :* Neal ZhuNing [mailto:zhuning@huawei.com mailto:zhuning@huawei.com ] *Envoyé :* mercredi >> 25 avril 2007 10:47 *À :* 'Jerker Zetterlund (TN/EAB)'; CHATRAS Bruno >> RD-CORE-ISS *Cc :* seppo.kauntola@nsn.com; 'Wayne Cutler (CV/ETL)'; >> Albrecht.Schwarz@alcatel-lucent.de; CWaitzmann@alcatel-lucent.de; >> smaoui@nortel.com; 'Christian Groves'; 'Lin Yangbo'; 'Tommy Young' >> *Objet :* RE: H.248 Ia Profile Version 2 >> >> Hello Jerker and all, >> >> I do agree with your viewpoint. Profile version negotiation can >> avoid backwards compatibility issue. Interoperability between Ia /1 >> and Ia/2 is unreasonable. >> >> >> >> >> >> BR >> >> Neal >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Jerker Zetterlund (TN/EAB) >> [mailto:jerker.zetterlund@ericsson.com mailto:jerker.zetterlund@ericsson.com ] >> *Sent:* Wednesday, April 25, 2007 4:25 PM >> *To:* Neal ZhuNing; CHATRAS Bruno RD-CORE-ISS >> *Cc:* seppo.kauntola@nsn.com; Wayne Cutler (CV/ETL); >> Albrecht.Schwarz@alcatel-lucent.de; CWaitzmann@alcatel-lucent.de; >> smaoui@nortel.com; Christian Groves; Lin Yangbo; Tommy Young >> *Subject:* RE: H.248 Ia Profile Version 2 >> >> >> >> Hello all, >> >> >> >> I think this discussion is based on different understandings of the >> meaning of profile version. In the drafting session of the March >> TISPAN meeting I think we assumed that there is no need for direct >> compatibility between v1 and v2 of the profie. If both SPDF and MG >> support Ia v2 then this should not be a problem. >> >> >> >> As I just wrote in the other email, my personal view is that there is >> no clear need for interoperability between Ia v1 and Ia v2. As >> profiles are intended to limit the functionality to be used on an >> H.248 control association, then it seems reasonable for the MG & MGC >> to be able to be as precise as possible in which set of functionality >> to be used. >> >> >> >> BR >> >> >> >> Jerker >> >> >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Neal ZhuNing [mailto:zhuning@huawei.com mailto:zhuning@huawei.com ] >> *Sent:* den 25 april 2007 09:21 >> *To:* 'CHATRAS Bruno RD-CORE-ISS' >> *Cc:* seppo.kauntola@nsn.com; Wayne Cutler (CV/ETL); >> Albrecht.Schwarz@alcatel-lucent.de; CWaitzmann@alcatel-lucent.de; >> Jerker Zetterlund (TN/EAB); smaoui@nortel.com; 'Christian Groves'; >> 'Lin Yangbo'; 'Tommy Young' >> *Subject:* RE: H.248 Ia Profile Version 2 >> >> Hi Bruno and all, >> >> Could we discuss it to reach an agreement before meeting? (Not in >> WG3 group) >> >> Your second principle is hard to be followed. when new ip >> termination is crreated, If the IP realm identifier indicates >> "IPDomain1",but the terminationID in add request indicates an >> "interface" belongs to "IPDomain2" ,such as "ip/9/9/$", How MG can do? >> Can MG change another interface identifier(such as "ip/8/8/8" which >> belongs to ip domain "IPDomain1")in reply message ? i think it is not >> allowed by H.248 protocol. so if there is conflict brtween IP realm >> identifier and interface identifier, MG should reply error . Is it >> correct? >> >> I agree that SPDF can choose interface identifier according to IP >> domain and send it to BGF. But , in most case ,It is enough for SPDF >> to only send the IP realm identifier when the SPDF wishes to indicate >> the IP domain/realm of the H.248 IP terminationin to BGF,such as in >> ADD request . do you agree this? >> >> so I provide a principles list below: >> >> 1)The IP realm identifier shall preferentially be used if the SPDF >> wishes to indicate the IP domain/realm of the H.248 IP termination. >> >> 2)If SPDF wishs to specify which physical or logical interface a >> termination should be associated with in the MG, SPDF may set >> "interface" field. "interface" field may be associated to IP realm. >> >> 3)If there is conflict between IP realm identifier and the ip domain >> the "interface" field associated to ,error code should be replied. >> >> >> >> BR >> >> Neal >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@ORANGE-FTGROUP.COM mailto:bruno.chatras@ORANGE-FTGROUP.COM ] >> >> Sent: Tuesday, April 24, 2007 8:42 PM >> >> To: TISPAN_WG3@LIST.ETSI.ORG >> >> Subject: Re: H.248 Ia Profile Version 2 >> >> >> >> OK then I disagree with 5.1.4.2.15.1 and will submit a CR against it. >> Let's talk about his at the meeting. Note that a "version 1" BGF is >> able to derive the IP domain (and tehrefore the address ppol from >> which the termination address shall be taken) from the "interface" >> field. Release 2 shall not disallow this behavior. Therefore I think >> that we should draft a text along the following principles: >> >> >> >> 1/ The IP realm identifier shall be sent to the BGF when the SPDF >> wishes to indicate explictly the IP domain/realm of the H.248 IP >> termination. >> >> >> >> 2/ If the IP realm identifier is received by the BGF, it shall take >> precedence over any IP realm that may be derived from (or associated >> to) the interface identifier. >> >> >> >> BC >> >> >> >> >> >> This behavior >> >> >> >> -----Message d'origine----- >> >> De : Neal ZhuNing [mailto:zhuning@huawei.com mailto:zhuning@huawei.com ] >> >> Envoyé : mardi 24 avril 2007 12:59 >> >> À : CHATRAS Bruno RD-CORE-ISS; TISPAN_WG3@LIST.ETSI.ORG >> >> Objet : RE: H.248 Ia Profile Version 2 >> >> >> >> Hi Bruno, >> >> In the latest draft, Session 5.14.2.15.1: >> >> "The ephemeral termination string layout >> ("ip/<group>/<interface>/<id>") may still be used to specify which >> physical or logical interface a termination should be associated with >> in the MG. but the "interface" field shall not be used for IP >> realm/domain indication ." >> >> >> >> The "interface" field shall not be used for IP realm/domain >> indication, so if SPDF wishes to indicate the IP domain/realm of the >> H.248 IP termination, only ipdc property can be used in ia/2. >> >> >> >> BR >> >> Neal >> >> >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@orange-ftgroup.com mailto:bruno.chatras@orange-ftgroup.com ] >> >> Sent: Tuesday, April 24, 2007 6:48 PM >> >> To: Neal ZhuNing; TISPAN_WG3@LIST.ETSI.ORG >> >> Subject: RE: H.248 Ia Profile Version 2 >> >> >> >> Based on operator's policy and BGF capabilities (e.g. if the IP domain >> can't be derived from the interface id by the BGF). >> >> >> >> -----Message d'origine----- >> >> De : Neal ZhuNing [mailto:zhuning@huawei.com mailto:zhuning@huawei.com ] Envoyé : mardi 24 avril >> 2007 12:44 À : CHATRAS Bruno RD-CORE-ISS; TISPAN_WG3@LIST.ETSI.ORG >> Objet : RE: H.248 Ia Profile Version 2 >> >> >> >> Hi Bruno, >> >> In which condition the SPDF wishes to indicate explictly the IP >> domain/realm of the H.248 IP termination?? >> >> >> >> BR >> >> Neal >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@orange-ftgroup.com mailto:bruno.chatras@orange-ftgroup.com ] >> >> Sent: Tuesday, April 24, 2007 6:40 PM >> >> To: Neal ZhuNing; TISPAN_WG3@LIST.ETSI.ORG >> >> Subject: RE: H.248 Ia Profile Version 2 >> >> >> >> I would prefer >> >> >> >> "The IP realm identifier shall be sent to the BGF when the SPDF >> wishes to indicate explictly the IP domain/realm of the H.248 IP >> termination." >> >> >> >> -----Message d'origine----- >> >> De : Neal ZhuNing [mailto:zhuning@HUAWEI.COM mailto:zhuning@HUAWEI.COM ] Envoyé : mardi 24 avril >> 2007 >> >> 12:37 À : TISPAN_WG3@LIST.ETSI.ORG Objet : Re: H.248 Ia Profile >> Version 2 >> >> >> >> Hi Bruno, >> >> >> >> What about: "The IP realm identifier shall be sent to the BGF in order >> to indicate the IP domain/realm of the H.248 IP termination." >> >> >> >> Your state "if explicit signalling of the IP domain/realm of the H.248 >> IP termination is required." is unclear. In which condition this >> explicit signaling is required? I think this condition is that SPDF >> wants to indicate the IP domain/realm of the H.248 IP termination. >> >> >> >> >> >> BR >> >> Neal >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@orange-ftgroup.com mailto:bruno.chatras@orange-ftgroup.com ] >> >> Sent: Tuesday, April 24, 2007 6:28 PM >> >> To: Neal ZhuNing; TISPAN_WG3@LIST.ETSI.ORG >> >> Subject: RE: H.248 Ia Profile Version 2 >> >> >> >> Use of "MUST" in ETSI documents is not recommended by the ETSI >> Drafting Rules anyway... (See Clause 23 of the ETSI Drafting Rules). >> >> >> >> What about: "The IP realm identifier shall be sent to the BGF if >> explicit signalling of the IP domain/realm of the H.248 IP termination >> is required." >> >> >> >> >> >> Bruno >> >> >> >> -----Message d'origine----- >> >> De : Neal ZhuNing [mailto:zhuning@huawei.com mailto:zhuning@huawei.com ] Envoyé : mardi 24 avril >> 2007 >> >> 12:04 À : CHATRAS Bruno RD-CORE-ISS; TISPAN_WG3@LIST.ETSI.ORG Objet : RE: >> >> H.248 Ia Profile Version 2 >> >> >> >> Hi Bruno, >> >> It should be "MUST", not "MAY". >> >> When SPDF wants to indicate the IP domain/realm of the H.248 IP >> termination, the ipdc property MUST be sent to the BGF. >> >> If there is no ipdc property in the message, it is still a valid >> message, but it can not indicate the IP domain/realm. BGF creates IP >> terminations on the special "interface "according to the (ALL or >> partial) wildcard terminationID. >> >> >> >> BR >> >> Neal >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@orange-ftgroup.com mailto:bruno.chatras@orange-ftgroup.com ] >> >> Sent: Tuesday, April 24, 2007 5:49 PM >> >> To: Neal ZhuNing; TISPAN_WG3@LIST.ETSI.ORG >> >> Subject: RE: H.248 Ia Profile Version 2 >> >> >> >> Yes I was referring to this text >> >> >> >> "The IP realm identifier must be sent to the BGF in order to indicate >> the IP domain/realm of the H.248 IP termination." >> >> >> >> Would you agree to replace "MUST" with "MAY"? >> >> >> >> Best Regards >> >> Bruno >> >> >> >> -----Message d'origine----- >> >> De : Neal ZhuNing [mailto:zhuning@huawei.com mailto:zhuning@huawei.com ] Envoyé : mardi 24 avril >> 2007 >> >> 11:27 À : CHATRAS Bruno RD-CORE-ISS; TISPAN_WG3@LIST.ETSI.ORG Objet : RE: >> >> H.248 Ia Profile Version 2 >> >> >> >> Hi Bruno, >> >> >>> I have seen that somewhere in the text of the Latest Draft it is >>> >>> stated >>> >> that >the MGC SHALL set the H.248.41 property. Unless there is an >> error in the text, >this seems to assume interpretation "b". >> >> >> >> I can not find your this state in the text of the latest draft, maybe >> what you refer to is Ia/2 session 5.14.2.15.1 ?? >> >> >> >> Best Regards, >> >> Neal >> >> >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@ORANGE-FTGROUP.COM mailto:bruno.chatras@ORANGE-FTGROUP.COM ] >> >> Sent: Tuesday, April 24, 2007 3:27 PM >> >> To: TISPAN_WG3@LIST.ETSI.ORG >> >> Subject: Re: H.248 Ia Profile Version 2 >> >> >> >> Carsten, >> >> >> >> I agree that there would not be any compatibility issue with >> interpretation "a". However, I have seen that somewhere in the text of >> the Latest Draft it is stated that the MGC SHALL set the H.248.41 >> property. Unless there is an error in the text, this seems to assume >> interpretation "b". >> >> >> >> Best Regards >> >> Bruno >> >> >> >> -----Message d'origine----- >> >> De : Carsten Waitzmann [mailto:cwaitzmann@ALCATEL-LUCENT.DE mailto:cwaitzmann@ALCATEL-LUCENT.DE ] >> >> Envoyé : mardi 24 avril 2007 09:21 >> >> À : TISPAN_WG3@LIST.ETSI.ORG >> >> Objet : Re: H.248 Ia Profile Version 2 >> >> >> >> Hello Bruno, >> >> >> >> Related to your understanding of backward compatibility: >> >> > My understanding is that backward compatibility in the work item > >> description was intended to refer to the ability for version n+1 to > >> understand version n without requiring version negotiation to occur > >> before. >> >> >> >> I'd like to ask the following question: >> >> What does "mandatory package" within a H.248 profile mean: >> >> a) it just means that a MG/MGC announcing compliance to this profile >> can expected to have implemented all these packages (and therefore all >> received >> >> H.248 messages using any property, signal, etc. of these packages is >> properly understood and processed). However it doesn't imply that the >> packages have to be always used whenever possible. >> >> b) same as a) but mandatory packages have to be always used whenever >> possible. >> >> >> >> If it is a), then I don't think that there is a backward compatibility >> issue. In the specific case of H.248.41, for example an MGC may still >> run v1 w/o .41 and the MG although running v2, may perfectly receive >> and process the message. v2 remains backward compatible, as the v1 >> capability to indicate a physical/logical interface within the IP >> termination string is still available. It wouldn't be backward >> compatible if the v2 profile would have changed the semantic of >> "interface" within the IP termination string. >> >> >> >> best regards >> >> Carsten >> >> >> >> Albrecht Schwarz wrote: >> >> >>> Bruno >>> >>>> My understanding is that backward compatibility in the work item >>>> >>> description was intended to refer to the ability >>> >>>> for version n+1 to understand version n without requiring version >>>> >>> negotiation to occur before. This is usually what >>> >>>> is meant in other ITU-T and ETSI standards dealing with signalling. >>>> >>> Couldn't find any appropriate definition for "backward compatibility" >>> >>> in ITU-T & ETSI (like the one for codecs from H.262). >>> >>> There are signalling protocols with and without a version >>> negotiation >>> >>> mechanism. The understanding of "backward compatibility" might be >>> >>> slightly different for both categories. Guess the protocols without >>> a >>> >>> version negotiation method are the majority like the capability set >>> >>> based ITU-T protocols like e.g. INAP, BICC or Q.2630.x. >>> >>> H.248 belongs to the category with an >>> >>> a) integral mechanism for protocol version negotiation and in >>> addition >>> >>> a >>> >>> b) mechanism for profile negotiation >>> >>> and also >>> >>> c) a multi profile mode capability (H.248.18). >>> >>> The used protocol capabilities are related to the lifetime of the >>> >>> H.248 Control Association (CA), starting the negotiation at CA >>> >> establishment. >> >> >>> Capability upgrade procedures may lead to a re-new or >>> re-establishment >>> >>> of the CA. >>> >>> A definition for "backward compatibility" for H.248 CAs might >>> >>> therefore different to other protocols without such mechanisms. >>> >>> We got four WIs for H.248 Profiles, - a MG registration with the >>> >>> correspondent ProfileID is part of a profile specification. >>> >>> Saying that, the meaning of backward compatibility in the WI >>> >>> description means that the MG registers with Ia/2 in my opinion. >>> >>> In case of a fallback requirement to Ia/1, then current draft my be >>> >>> extended for H.248.18 support (but this requires a contribution). >>> >>> Albrecht >>> >> >> >> >>> Christian Groves >>> >> >> >> >>> <Christian.Groves@NT To: >>> >> TISPAN_WG3@LIST.ETSI.ORG >> >> >> >> >>> ECZONE.COM> cc: >>> >> >> >> >>> Subject: Re: >>> H.248 >>> >>> Ia >>> >> Profile Version 2 >> >> >>> 23.04.2007 09:55 >>> >> >> >> >>> Please respond to >>> >> >> >> >>> Christian Groves >>> >> >> >> >> >> >> >>> Hello Bruno, >>> >>> What does "ability for version n+1 to understand version n" mean? >>> Even >>> >>> in the scenario we are talking about a MG with a version n+1 control >>> >>> association will understand the version n message because the >>> encoding >>> >>> has not changed (thus backwards compatible by the definition below) >>> >>> but it will reject it because of new required functionality. >>> Likewise >>> >>> it seems that "before version negotiation" has been prompted by the >>> >>> email discussion. For some, such mechanisms are integral for >>> >>> compatibility mechanisms. >>> >>> Do you have a reference to a general description of "backwards >>> >>> compatibility"? The term is used alot but I don't know any description >>> >>> other than that in H.248.1. For example H.248.1 section 11.3 >>> >>> Negotiation of Protocol Version offers rules for new versions. ie. >>> >>> /When extending the protocol with new versions, the following >>> rules >>> >>> should be followed:/ >>> >>> /1) Existing protocol elements, i.e., procedures, parameters, >>> >>> descriptor, property, values, should/ >>> >>> /not be changed unless a protocol error needs to be corrected or >>> it >>> >>> becomes necessary to/ >>> >>> /change the operation of the service that is being supported by >>> the >>> >>> protocol./ >>> >>> /2) The semantics of a command, a parameter, a descriptor, a >>> >>> property, or a value should not be/ >>> >>> /changed./ >>> >>> /3) Established rules for formatting and encoding messages and >>> >>> parameters should not be/ >>> >>> /modified./ >>> >>> /4) When information elements are found to be obsolete they can >>> be >>> >>> marked as not used./ >>> >>> /However, the identifier for that information element will be >>> marked >>> >>> as reserved. In that way/ >>> >>> /it cannot be used in future versions./ >>> >>> These rules were adopted to ensure backwards compatibility. I think >>> >>> these rules are equally applicable to the case of profiles. When the >>> >>> MGC and MG agree on the use of a control association they agree on >>> the >>> >>> H.248.1 version and the profile (including version). >>> >>> Regards, Christian >>> >>> CHATRAS Bruno RD-CORE-ISS wrote: >>> >>>> Hello Chirstian, >>>> >>>> My understanding is that backward compatibility in the work item >>>> >>> description was intended to refer to the ability for version n+1 to >>> >>> understand version n without requiring version negotiation to occur >>> >> before. >> >> >>> This is usually what is meant in other ITU-T and ETSI standards >>> >>> dealing with signalling. >>> >>>> Best Regards, >>>> >>>> Bruno >>>> >>>> -----Message d'origine----- >>>> >>>> De : Christian Groves [mailto:Christian.Groves@NTECZONE.COM mailto:Christian.Groves@NTECZONE.COM ] >>>> >>>> Envoyé : lundi 23 avril 2007 02:58 >>>> >>>> À : TISPAN_WG3@LIST.ETSI.ORG >>>> >>>> Objet : Re: H.248 Ia Profile Version 2 >>>> >>>> Hello Bruno, >>>> >>>> What was the definition of "backward compatibility" that the work >>>> >>>> item >>>> >>> description assumed? It seems that people have different interpretations. >>> >>>> Regards, Christian >>>> >>>> CHATRAS Bruno RD-CORE-ISS wrote: >>>> >>>>> This is version negotiation, not backward compatibility.... Both >>>>> >>> approaches are valid protocol design approaches and have their pros >>> >>> and cons. However, the Work Item description assumed "backward >>> >>> compatibility between version 1 and 2... >>> >>>>> -----Message d'origine----- >>>>> >>>>> De : Neal ZhuNing [mailto:zhuning@HUAWEI.COM mailto:zhuning@HUAWEI.COM ] Envoyé : vendredi 20 >>>>> >>>>> avril 2007 04:09 À : TISPAN_WG3@LIST.ETSI.ORG Objet : Re: H.248 Ia >>>>> >>>>> Profile Version 2 >>>>> >>>>> Agree Albrecht's state. >>>>> >>>>> When a BGF registers with a ProfileID "ETSI_BGF/1" 0r >>>>> >>>>> "ETSI_BGF/2", >>>>> >>> corresponding ia profile(ia/2 or ia/1) should be applied. >>> >>>>> I think the Profile-based backward compatibility between ia/2 >>>>> and >>>>> >>> ia/1 is based on their functions. Ia/2 can realize all the functions >>> >>> of Ia/1, but new better methods can be used, even it is mandatory. >>> >>>>> BR >>>>> >>>>> Neal >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE ] >>>>> >>>>> Sent: Thursday, April 19, 2007 6:50 PM >>>>> >>>>> To: TISPAN_WG3@LIST.ETSI.ORG >>>>> >>>>> Subject: Re: H.248 Ia Profile Version 2 >>>>> >>>>> [Sorry for using your initials as abbreviation BC for backward >>>>> >>>>> compatibility :-)] >>>>> >>>>> I do agree to your statement. >>>>> >>>>> Important here is the "scope of the protocol" in my understanding. >>>>> >>>>> There would be a compatibility issue when the SPDF & BGF would >>>>> >>>>> operate >>>>> >>> Ia interface in the "NoProfile" mode, i.e. the BGF would not include >>> >>> the ServiceChangeProfile parameter for registration. >>> >>>>> But the protocol scope is limited when registering with a >>>>> ProfileID >>>>> >>>>> (as >>>>> >>> in case of ES 283 018). There are then only "ETSI_BGF/1" or "ETSI_BGF/2" >>> >>>>> H.248 Messages between a single SPDF-BGF tandem. >>>>> >>>>> I think that this is the crucial point concerning "protcol scope" >>>>> >>>>> for >>>>> >>>>> H.248 >>>>> >>>>> interface: "Profile-less" vs "Profile-based" operated H.248 >>>>> Control >>>>> >>> Associations. >>> >>>>> Albrecht >>>>> >>>>> "CHATRAS Bruno >>>>> >>>>> RD-CORE-ISS" To: "Neal >>>>> >>>>> ZhuNing" zhuning@huawei.com, >>>>> Albrecht.Schwarz@ALCATEL-LUCENT.DE >>>>> >>>>> <bruno.chatras@orange-f cc: >>>>> >>>>> TISPAN_WG3@LIST.ETSI.ORG >>>>> >>>>> tgroup.com> Subject: RE: >>>>> >> H.248 >> >> >>> Ia >>> >>>>> Profile Version 2 >>>>> >>>>> 19.04.2007 12:28 >>>>> >>>>> Adding a mandatory parameter to version n+1 of a protocol means >>>>> that >>>>> >>>>> a >>>>> >>> message conforming to the version n of this protocol is not a valid >>> >>> message for an implementation conforming to version n+1 of this >>> >>> protocol. Is not this a compatobility issue? >>> >>>>> BC >>>>> >>>>> -----Message d'origine----- >>>>> >>>>> De : Neal ZhuNing [mailto:zhuning@huawei.com mailto:zhuning@huawei.com ] Envoyé : jeudi 19 >>>>> >>>>> avril >>>>> >>>>> 2007 11:55 À : Albrecht.Schwarz@ALCATEL-LUCENT.DE; CHATRAS Bruno >>>>> >>>>> RD-CORE-ISS Cc : TISPAN_WG3@LIST.ETSI.ORG Objet : RE: H.248 Ia >>>>> >>>>> Profile Version 2 >>>>> >>>>> Hi Albrecht, Bruno, >>>>> >>>>> In Ia/1, the hierarchical termination name does not >>>>> specifically >>>>> >>> mention that it is used to identify the IP domain that a termination >>> >>> is connected to, nor does it give an example of the syntax >>> associated >>> >>> with the "interface". So maybe there is no backward compatibility on >>> >>> this >>> >> issue. >> >> >>>>> In Ia/2, the hierarchical termination name may still be used to >>>>> >>> specify which physical or logical interface a termination should be >>> >>> associated with in the MG. >>> >>>>> So, the hierarchical termination name mechanism is same in Ia/1 >>>>> and >>>>> >>> Ia/2, there is no backward compatibility problem. >>> >>>>> BR >>>>> >>>>> Neal >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE ] >>>>> >>>>> Sent: Thursday, April 19, 2007 5:21 PM >>>>> >>>>> To: TISPAN_WG3@LIST.ETSI.ORG >>>>> >>>>> Subject: Re: H.248 Ia Profile Version 2 >>>>> >>>>> Bruno, >>>>> >>>>> when we discussed this, we couldn't see a violation of the >>>>> backward >>>>> >>> compatibility (BC) principle. >>> >>>>> The MG is registering either with Ia/1 or Ia/2, but not with both >>>>> >>> profile versions (like in a multiple profile mode), the used IP >>> >>> realm/domain indication mechanism is unambiguous. >>> >>>>> The profile principle is thus supporting BC targets. >>>>> >>>>> A single H.248 Control Association is either operated with Ia/1 or >>>>> >> Ia/2. >> >> >>>>> Do I overlook sth? >>>>> >>>>> Albrecht >>>>> >>>>> PS >>>>> >>>>> Above principle is/may also used for other "capability upgrades", >>>>> >>>>> like H.248.10 replacement by H.248.11 in a next profile version, >>>>> etc >>>>> >>>>> etc >>>>> >>>>> CHATRAS Bruno >>>>> >>>>> RD-CORE-ISS To: >>>>> >>>>> TISPAN_WG3@LIST.ETSI.ORG >>>>> >>>>> <bruno.chatras@ORANGE-F cc: >>>>> >>>>> TGROUP.COM> Subject: H.248 Ia >>>>> >>>>> Profile Version 2 >>>>> >>>>> 19.04.2007 11:12 >>>>> >>>>> Please respond to >>>>> >>>>> CHATRAS Bruno >>>>> >>>>> RD-CORE-ISS >>>>> >>>>> Ray, Wayne, >>>>> >>>>> I just had a look to the Latest Draft of WI03098 (Ia profile >>>>> Release >>>>> >>>>> 2) >>>>> >>> and saw that support of the new IPDC package is mandatory rather >>> than >>> >>> optional. >>> >>>>> This contradicts the Work Item description which says explictly >>>>> that >>>>> >>> "The Ia profile version 2 shall maintain backwards compatibility >>> with >>> >>> version 1." The meeting reports says that adding the IPDC package >>> was >>> >>> indeed agreed but does not say whether it should be mandatory or >>> >> optional. >> >> >>> I believe that we should either make this package optional or made >>> an >>> >>> attempt to modify the Work Item description. I assume we can't >>> approve >>> >>> a deliverable which explicitly contradicts a Work Item description. >>> >>>>> BTW, what is the procedure for TB approval of this modification. >>>>> >>>>> There >>>>> >>> does not seem to be any CR corresponding to this modification (just >>> a >>> >>> contribution). >>> >>>>> Best regards >>>>> >>>>> Bruno >>>>> >>>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>>> >>>>> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>>> >>>>> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>>> >>>>> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>>> >>>>> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>>> >>>>> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>> ------------------------------------------------------------------- >>>> >>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>> >>>> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >>>> >>>> ------------------------------------------------------------------- >>>> >>> ------------------------------------------------------------------- >>> >>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>> >>> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >>> >>> ------------------------------------------------------------------- >>> >>> ------------------------------------------------------------------- >>> >>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>> >>> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >>> >>> ------------------------------------------------------------------- >>> >> >> >> >> >> -- >> >> Alcatel-Lucent Deutschland AG >> >> Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026 >> Vorsitzender des Aufsichtsrats: Michael Oppenhoff >> >> Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen >> Poesinger, Alf Henryk Wulf >> >> >> >> ------------------------------------------------------------------- >> >> Mail archive for TISPAN_WG3 can be browsed at the following url : >> >> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >> >> ------------------------------------------------------------------- >> >> >> >> ------------------------------------------------------------------- >> >> Mail archive for TISPAN_WG3 can be browsed at the following url : >> >> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >> >> ------------------------------------------------------------------- >> >> >> >> ------------------------------------------------------------------- >> >> Mail archive for TISPAN_WG3 can be browsed at the following url : >> >> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >> >> ------------------------------------------------------------------- >> >> >> >> ------------------------------------------------------------------- >> >> Mail archive for TISPAN_WG3 can be browsed at the following url : >> >> http://list.etsi.org/TISPAN_WG3.html http://list.etsi.org/TISPAN_WG3.html >> >> ------------------------------------------------------------------- >> >> > > >
[attachment "iprealm_update.doc" deleted by Albrecht SCHWARZ/DE/ALCATEL]