Subject: Re: Comments on MEGACO protocol

From: Selvam Rengasami <[email-masked]>
Date: Thu, 16 Mar 2000 09:41:23 -0500

Christian, John,

I think the issue that Keith is raising is an interesting one.  Q.2941.1 defines
a generic mechanism for transporting an identifier via the GIT in DSS2.  As
Keith points out, in general, the GIT length is not limited by Q.2941.1,
therefore 4 or even 6 octets is not enough, if we want to support the generic
mechanism.

Now, if we want to support the BNC-ID mechanism (e.g., for use in conjunction
with BICC), then Q.2941.3 defines how a BNC-ID is carried in the GIT.  Q.2941.3
constrains the GIT length for BNC-ID value to exactly four octets (no more, no
less).  Specifically, Q.2941.3 gives the coding for Octet 5 (which identifies
BICC [Q.1901]  and for Octet 6 indicates that the identifier is a BNC-ID.  In
addition, Octet 6.1 (the length of the identifier) is required to be coded to a
value of 4.  Finally octets 6.2 through 6.5 provide the four octet BNC-ID value.

If we want to allow for future variations in Q.2941.3 or even Q.2941.1, then we
may want to consider allowing more than four octets for the BIR in C.8.

I am basically interested in having the BNC-ID value (as defined by Q.2941.3)
signaled between the MGC and the MG.  Four octets would suffice for this
purpose.  I propose that we agree that the BIR for C.8 can only contain the
BNC-ID value as defined in Q.2941.3 (i.e., octets 6.2 through 6.5) which
requires no change to the document.

By the way, Q.2941.3 (along with the other BICC related standards) is scheduled
to be approved (decided) in the Special meeting of SG 11 on June 15.

Cheers,

-Selvam Rengasami

Telcordia Technologies

Tel:  +1 732 758 5260
E-mail:  [email-masked]

Christian Groves <[email-masked]> on 03/15/2000 06:58:59 PM

Please respond to Christian Groves <[email-masked]>

To:   [email-masked]
cc:    (bcc: Selvam Rengasami/Telcordia)
Subject:  Re: Comments on MEGACO protocol

G'Day John,

The property name is BIR.

Perhaps the following change might work?

BNCid   8000    6 OCTETS        GIT (Generic Identifier Transport)
                                BNCid (Octet 5a and above)
                                Ref.: Recommendation Q.2941.1 (09/97)

Cheers, Christian

John Segers wrote:
>
> Christian,
>
> I believe it makes sense when it is used for binding reference.  If we
> only use octet 5 and above, and only use the GIT parameter for this
> specific case, we should rethink the name of the parameter.  Using GIT
> with a reference to Q.2941.1 will undoubtedly lead to confusion.
>
> John
>
> Christian Groves wrote:
> >
> > G'Day Keith and John,
> >
> > Regarding 6 the intention was to use this as a binding reference
> > (BNCid). Annex C should refer to octet 5 and above. For the BNCid the
> > length as per the GIT would be 6 octets. Make sense?
> >
> > Cheers, Christian
> >
> > John Segers wrote:
> > >
> > > Keith,
> > >
> > > Most of the changes you request are ok.  There's a couple that I don't
> > > know about:
> > > - (Re. 3) I thought that references to ITU Rec. have to be specific
> > > (i.e., including a date).  I asked Glen, and he's not sure either.
> > > We'll check.
> > > - (Re. 5) What headers are missing according to you?  The current ASN.1
> > > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=".  I
> > > checked the syntax with the OSS tools and didn't find a problem.
> > > - (Re. 6) I believe this was brought in through MSF and I never
> > > checked.  Having looked up Q.2941.1 now, I agree that 4 octets is
> > > restrictive.
> > >
> > > John
> > >
> > > "Drage, Keith" wrote:
> > > >
> > > > Attached please find a number of editorial comments on the Geneva output
> > > > document, which we also understand is identical to the MEGACO last call
> > > > document. These points are not intended to be controversial. In the
event
> > > > that discussion is required to resolve such a comment, then we will
withdraw
> > > > the comment in order to allow the document to proceed.
> > > >
> > > > 1)      Abbreviations. "BRI" is never used and therefore should be
removed
> > > > from the list of abbreviations.
> > > >
> > > > 2)      References. Q.724 is never used and should be removed.
> > > >
> > > > 3)      References and annex C. Where a reference is only used in annex
C,
> > > > we believe in general in most cases these should be undated (i.e. the
latest
> > > > version of the referenced document applies). This in particular applies
to
> > > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing
> > > > codepoints to different values, but do reserve the right to add new
values.
> > > > Surely the whole ethos of annex C is that new values do get
automatically
> > > > incorporated.
> > > >
> > > > 4)      References (and annex C if comment 3 not accepted). Some of the
> > > > dates are incorrect. Q.761-4 have a date of December 1999 as that was
> > > > decided last year. Q.2931 should reflect the date of the latest
amendment
> > > > (4) which we believe is also December 1999.
> > > >
> > > > 5)      Annex A. We could not find the module header, or an exports
> > > > statement, for the ASN.1. The module header is mandatory parts of the
ASN.1,
> > > > and gives that module an object identifier, which is needed for inport
to
> > > > anything else.
> > > >
> > > > 6)      Annex C, C.8, generic identifier transport. We are not sure how
you
> > > > fit this into four octets. Is there some subset of the generic
identifier
> > > > transport information element that is being used? Various codings of
this
> > > > information element get very, very long.
> > > >
> > > > 7)      Annex C, C.9, ITC has a reference to a note 2, which is not in
the
> > > > table. Is this a spurious inport from the referenced standard? If so, we
> > > > believe it can be deleted.
> > > >
> > > > 8)      Annex C, C.9. References to Q.931 need to identify that the
> > > > references are to the encoding in the Bearer capability information
element,
> > > > and not to the Low layer information element. The latter has identical
> > > > fields with the same code values, but has a more extensive range of
values
> > > > assigned. This is because some values (particularly at layer 3) are only
> > > > defined for end user to addressed end user usage. I believe in H.248
only
> > > > the more restricted list in the Bearer capability information element
would
> > > > be valid.
> > > >
> > > > Keith Drage
> > > >
> > > > > ---------------------------------------------------------------
> > > > > Keith Drage ([email-masked])
> > > > > Siemens Communications Limited,
> > > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK
> > > > > Tel: +44 115 943 4991   Fax: +44 115 943 4992
> > > > > ---------------------------------------------------------------
> > > > > Internet communications are not secure and therefore Siemens
> > > > > Communications Limited does not accept legal responsibility for the
> > > > > contents of this message. Any views or opinions presented are solely
those
> > > > > of the author and do not necessarily represent those of Siemens
> > > > > Communications Limited unless otherwise specifically stated.
> > > > >
> > > > >
> > >
> > > --
> > > John Segers                                  email: [email-masked]
> > > Lucent Technologies                                        Room HE 306
> > > Dept. Forward Looking Work                      phone: +31 35 687 4724
> > > P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>
> --
> John Segers                                  email: [email-masked]
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Selvam Rengasami <[email-masked]>
Date: Thu, 16 Mar 2000 21:18:49 -0500

Hi Stephen,

Q.2941.3 is scheduled to be approved on June 15, 2000 - the same day that H.248
is scheduled to be approved.  June 15 is the one day where there will be
succession of short SG meetings for those Study Groups that need to approve
Recommendations.  SG 11 will be approving Q.2941.3 along with other documents
during that day.  That same day, there will be a brief SG 16 meeting to approve
H.248.  I understand that some other SGs will also have short meetings that day
as well.

Therefore, I do not believe that there would be any problem in referencing
Q.2941.3.

Cheers,

-Selvam

Stephen Terrill <[email-masked]> on 03/16/2000 05:26:11 PM

Please respond to Stephen Terrill <[email-masked]>

Hi,

The reason that this suggestion was not followed in the first place was for
reasons of the referencing rules.  A determined document is not allowed to
reference a not determined document (like an RFC reference and I-D).  I am not
sure of the timing of the SG-11 decision cf the SG-16 decision of H.248.  If it
allows for this, then it might be OK, otherwise other solutions should be
sought.

Selvam Rengasami wrote:

> Folks,
>
> One correction to my previous e-mail.
>
> If we accept my proposal, then we should consider changing the reference from
> Q.2941.1 to Q.2941.3 in C.8
>
> Cheers,
>
> -Selvam
>
> Selvam Rengasami <[email-masked]> on 03/16/2000 09:41:23 AM
>
> Please respond to Selvam Rengasami <[email-masked]>
>

---

From: "Drage, Keith" <[email-masked]>
Date: Mon, 20 Mar 2000 12:19:10 +0000

I have no real view on which way this should be documented.

We do have the potential for a major admin problem here.

The order of the SG meetings on 15th June is first Study Group 4, then Study
Group 16, then Study Group 11.

Q.2941.3 will be decided (we hope) at 14:30 on Thursday 15th June.

H.248 will be decided (we hope) at approx. 11:00 on Thursday 15th June.

These Study Groups are sequential rather than in parallel, and in any case
no editing will be allowed on the floor of the meeting.

One single administration could create total chaos and confusion by allowing
H.248 to be decided, and then objecting to Q.2941.3 later in the day. Note
that Q.2941.3 is dependent on the existence of Q.1900, so the objection
could be that far back.

Therefore I think the safest option is to allow all values of GIT. The
length becomes a maximum of 29 octets (33 octets as specified in Q.2941.1
clause 8.2.1 less 4 octets header) - the coding starts at octet 5 onwards (I
assume). The reference should then be to Q.2941.1 as extended by subsequent
recommendations in the Q.2941.x series.

Keith Drage

> those of the author and do not necessarily represent those of Siemens

> -----Original Message-----
> From: John Segers [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2000 3:11 PM
> > > > document. These points are not intended to be
> controversial. In the event
> > > > that discussion is required to resolve such a comment,
> then we will withdraw
> > > > 1)      Abbreviations. "BRI" is never used and
> therefore should be removed
> > > > 3)      References and annex C. Where a reference is
> only used in annex C,
> > > > we believe in general in most cases these should be
> undated (i.e. the latest
> > > > version of the referenced document applies). This in
> particular applies to
> > > > codepoints to different values, but do reserve the
> right to add new values.
> > > > Surely the whole ethos of annex C is that new values do
> get automatically
> > > > incorporated.
> > > >
> > > > decided last year. Q.2931 should reflect the date of
> the latest amendment
> > > > statement, for the ASN.1. The module header is
> mandatory parts of the ASN.1,
> > > > and gives that module an object identifier, which is
> needed for inport to
> > > > anything else.
> > > >
> > > > 6)      Annex C, C.8, generic identifier transport. We
> are not sure how you
> > > > fit this into four octets. Is there some subset of the
> generic identifier
> > > > transport information element that is being used?
> Various codings of this
> > > > 7)      Annex C, C.9, ITC has a reference to a note 2,
> which is not in the
> > > > references are to the encoding in the Bearer capability
> information element,
> > > > fields with the same code values, but has a more
> extensive range of values
> > > > defined for end user to addressed end user usage. I
> believe in H.248 only
> > > > the more restricted list in the Bearer capability
> information element would
> > > > be valid.
> > > >
> > > > Keith Drage
> > > >
> > > > >
> > > > > contents of this message. Any views or opinions
> presented are solely those

---

From: "Drage, Keith" <[email-masked]>
Date: Mon, 20 Mar 2000 12:21:06 +0000

See below:

Keith Drage

> Sent: Monday, March 13, 2000 7:44 AM

Recommendation A.3 keeps changing, but in the version I checked, while a
date is certainly allowed, none of the words told me it had to be there. (I
also found no words providing specifically for their omission.) We have
certainly used undated references in SG11 in the past. ISO and ETSI rules
(which the ITU-T rules have been brought closer to) certainly allow undated
references and specifically provide for them.

> checked the syntax with the OSS tools and didn't find a problem.

I have rechecked the header against the new ASN.1, and syntactically the
current stuff is OK. Semantically also, according to the new ASN.1
definition, I understand that omitting the keyword, it exports everything,
which I had not understood before. All therefore OK here.

The header is however missing an optional assigned object identifier
(construct DefinitiveIdentifier) and I believe this is essential when trying
to import material to other ASN.1 moduled. I believe that it would be useful
to add an object identifier to the header. The question is, which module
identifier. For H.248 a suitable object identifier would be:

        itu-t recommendation h 248 media-gateway-control(0)

Would this also be acceptable for the IETF version?

> checked.  Having looked up Q.2941.1 now, I agree that 4 octets is

See comments on a separate email.

> > that discussion is required to resolve such a comment, then
> we will withdraw
> > 1)      Abbreviations. "BRI" is never used and therefore
> should be removed
> > 3)      References and annex C. Where a reference is only
> used in annex C,
> > we believe in general in most cases these should be undated
> (i.e. the latest
> > codepoints to different values, but do reserve the right to
> add new values.
> > decided last year. Q.2931 should reflect the date of the
> latest amendment
> > statement, for the ASN.1. The module header is mandatory
> parts of the ASN.1,
> > and gives that module an object identifier, which is needed
> for inport to
> > anything else.
> >
> > 6)      Annex C, C.8, generic identifier transport. We are
> not sure how you
> > transport information element that is being used? Various
> codings of this
> > fields with the same code values, but has a more extensive
> range of values
> > defined for end user to addressed end user usage. I believe
> in H.248 only
> > > contents of this message. Any views or opinions presented
> are solely those

> contents of this message. Any views or opinions presented are solely those