Temporary Document No.6 (Sunriver)
                                              8 September 1997

Source: Rapporteurs for Q.12/16 (Sakae OKUBO)
Title:	Advice of the SG16 management team regarding a possible H.310 cahnge

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

This document records the correspondence between Rapporteur and SG16 managment team members regarding the possible change of H.320/H.321 interoperation mode in H.310 RAST-5 specifications.

 ------------< 1. Problem description by Sakae Okubo 97/07/02 >------------

Dear SG16 Management Team,

This is to seek your advice regarding the procedures for (possibly)
replacing a part of the existing specifications.

At the Hertzlia (Israel) meeting of Q12-14 last month, we discussed
how to handle the difference between the following two stacks:

 - H.320/H.321 interoperation mode of the H.310 RAST-5 terminal
   (approved in November 1996 after the ballot)
 - New Annex B to H.321 (determined last March)

     -----------     -----------     -----------
      H.262 etc.      H.261 etc.      H.261 etc.
     -----------     -----------     -----------
       H.222.0         H.222.0          H.221
     -----------     -----------     -----------
       H.222.1         H.222.1           NAL
     -----------     -----------     -----------
        AAL5             AAL5            AAL5
     -----------     -----------     -----------
        ATM              ATM             ATM
     -----------     -----------     -----------

        Native      Interoperation    Annex B to
        mode of         mode of          H.321
     H.310 RAST-5    H.310 RAST-5

     NAL:  Network Adaptation Layer
     RAST: Receive And Send Terminal

These two are both using AAL5 and intended for use in customer
premises ATM networks.  If these two are going to intercommunicate, we
need a gateway for converting between H.221 and H.222.0 multimedia
multiplexing and other network adaptation even if the two terminals
are accommodated in the same customer premises network.  This is
obviously undesirable.

You may ask why Annex B to H.321 does not use the same stack as the
H.310 RAST-5.  This is because Annex B to H.321 is intended to
intercommunicate with the existing H.320 terminal on N-ISDN which has
the stack of H.261 etc. on top of H.221.  The choice for the
H.320/H.321 interoperation mode stack came from the stack of H.310
native mode which is MPEG-2 based, hence has a stack of H.262 on top
of H.222.0.  Probably we made a bad choice in the H.310 RAST-5
interoperation mode.

One of the possible solutions to this problem is to replace the H.310
RAST-5 interoperation mode stack with the one in Annex B to H.321.
This is in line with the configuration of H.310 RAST-1 and Annex A to
H.321 both of which are based on AAL1.  Of course, this change of the
existing specifications is significant to the ITU-T reputation.
Fortunately or unfortunately, however, H.310 implementation is slow in
the market.  If it is found that any party is not inconvenient with
the change, this may be the chance to correct the situation.

There are other solutions including definition of the desired stack
(namely the stack of Annex B to H.321) as an option.  The problem and
possible solutions were exposed at the Hertzlia meeting and position
papers are being solicited towards the Sunriver meeting next September.

In the meantime, may I ask you whether the above mentioned replacement
is ever possible, and if possible what would be the right procedures.
Perhaps the first thing would be to informally collect information if
any party feels inconvenient with the replacement.  The procedures for
corrigendum may be applicable?

I am looking forward to receiving your advice towards the Sunriver
meeting.

Best regards,

Sakae OKUBO (Mr.)

 ------------< 2. Advice by Mr. Istvan Sevestyen 97/08/06 >------------

Dear Mr. Okubo,

.....

The Interoperation mode of H.310 RAST-5 looks really strange. I
personally think that your suggested change is much better, and we
should take the chance - provided that it is not too hurting for
possible existing implementations, should any exist. This - within
Siemens - I will check, and if it hurts anybody, then I will let it
know by the SEpt. Rapp. Meeting.

The mechanics of the change itself I think is now simple. There is new
provision in the new REs. No. 1 how to handle correctly "defects":

"8.7    Correction of defects

8.7.1   When a Study Group identifies the need for implementors to be
made aware of defects (e.g. typographical errors, editorial errors,
ambiguities, omissions or inconsistencies and technical errors) in a
Recommendation, one mechanism that may be employed is an Implementors'
Guide.  This Guide is an historical document recording all identified
defects and their status of correction, from their identification to
final resolution, and would be issued in the Study Group's COM Series
of documents.

8.7.2   Defects identified since the approval of the latest issue of
the Implementors' Guide (par. 8.7.1) and their proposed corrections
are referenced in the Director's invitation to the next Study Group
meeting so the Study Group can address them. The Chairman shall be
accountable for a fair decision about the nature of the proposed
corrections, in the spirit which is expressed in par. 8.5.2 above.
After approval by the Study Group (see par. 8.5.3 to par. 8.5.6), the
Director shall announce the corrections in a Circular-letter and the
Study Group will update the Implementors' Guide accordingly."

Then at the best next occasion, the change in the H.310 would also be
made.

Kind regards,

Istvan Sebestyen
Siemens

 ------------< 3. Advice by Mr. Simao Campos Neto 97/08/06 >------------

Dear Mr.Okubo,

.....

My 2 cents on the issue.

As you have put the problem, there are two issues:
1. Whether to change
2. How to change

For item 1, as you mention, an informal consultation can be made (and
as Mr. Sebestyen is proposing to help you), but formal consultation
could *also* be made, perhaps through a TSB circular letter to the ITU
membership. Although the Recommendation approval process is already a
formal consultation process to the ITU state members, it would come
only after a lot of effort is put to create a new text.

Regarding non-backward-compatible changes to recommendations, one
should not forget the Red Book G.721 ADPCM and its replacement in the
Blue Book. Several companies went on implementing the Red Book G.721
when the fault in the algorithm was discovered. The recommendation had
to be changed, and it was an incompatible change. The result was a
long delay in the deployment of the algorithm (to circumvent market
suspiction). Sometimes you don't have the option (as in that case),
and you have to "bite the bullet", so to speak. Sometimes it is not so
necessary, but convenient, both from the deployment level aspect and
from the future evolution aspect. This, as you are aware, you have to
gauge from the industry.

For item two, Mr. Sebestyen proposal is a more immediate one: an
implementor's guide on the issue could be approved in
January. However, due to the nature of the change, I would prefer a
formal update of the recommendation. I am not yet sure that
implementor's guides already have sufficient visibility from
non-frequent ITU participants, and many segments of the industry
(unfortunatelly) fall in this category.

For a formal change, you have two chances:
a. seek determination in September and decision in January (if you can
   get the new text in such a short notice)
b. seek determination in January and decision in September

NOTE: regarding corrigenda, they follow the same formal approval
      process as a revised recommendation. Whether you issue a revised
      rec. or a corrigendum to a Rec. depends only on the extent of
      the changes. Of course, corrigenda are less expensive for the
      ITU to produce than a revised Rec.

Of course one could think of publishing an implementor's guide in
January AND determine the modification text in January. However, the
implementor's guide would be published only later in 1998, more or
less at the same time that the revised text would be circulated for
ballot. Hence, I don't think this would be a good approach.

In summary, (not being an expert on the issue), if you can have the
text for determination in September, and your informal consultations
indicate this is the right way to go, I would go for it. The balloting
would then work as the formal consultaion process, and in the summary
you should ponder the impact of the proposed changes. With that, the
text would be approved in January and published in a very transparent
way soon thereafter. If you can't have the text for September 97, then
you are stuck with determining the text in January, and even in this
case I wouldn't go after an implementor's guide.

Again, these are my 2 cents on the issue. Maybe others in the
management team will have other views.

Best regards,
Simao Campos-Neto

 ------------< 4. Advice by Mr. Federico Tosco 97/08/06 >------------

        Dear Mr. Okubo,
.....

I agree with you that the suggested change of the existing
specifications is not good for the ITU-T reputation. However, if there
is an agreement that this is the only solution, or the preferred
solution, I think that we should proceed as rapidly as possible, in
order to make the change when the implementation of H.310 is not yet so
advanced. At the same time we should be sure to carefully examine the
new text, in order to avoid the need of further changes in the future.

Finally, I agree with Simao Campos Neto that such a change should not be
put into an Implementors Guide but should bring to a formal update of
the recommendation, either in the form of a corrigendum or of a revised
recommendation.

.....

Best regards.

Federico Tosco


 ------------< 5. Advice by Mr. Fabio Bigi 97/08/14 >------------

Dear Mr. Okubo,

.....

Concerning the message on H.320/H.321 interoperation mode of H.310 RAST-5 it will be better to have a clearly agreed text and see really if the recently adopted one is misleading. More we burden a given text with defects, corrigenda, implementors guides,  etc., less people not attending the "Rapporteurs Group" will understand the standard. Hoping that this can assist your further deliberations, we can discuss the matter at Sunriver meeting.

Regards.

F. Bigi
TSB, Senior Counsellor