June 1998 - sg16-avd - lists.packetizer.com

subscribing to H.323 mailing list
by Viswanath Math 01 Feb '99

01 Feb '99

Hi I would like to suscribe to your mailing list for discussions on H.323. Thanks Viswanath

3 2

Re: ASN.1 accross revisions
by Pete Cordell 30 Jun '98

30 Jun '98

Dear All, I admit that I am only just hanging in there with this debate, but I think I have a possible solution 5 to throw in as a contender. Looking at the problem a bit laterally, we have RasMessage in UDP packets that we want to sign, and H323-UserInformation in the UUIE that we want to sign. Currently these are the only chunks of ASN.1 in these fields. We could add a second piece of ASN.1 into these fields (UDP packet and UUIE) that contains the signatures, such as: H323Extra ::= CHOICE { icv ICV, ... } This would be a separate ASN.1 tree. Therefore in a RAS UDP packet you would get: RasMessage chunk of ASN.1 H323Extra chunk of ASN.1 typically containing signature Similarly in the UUIE, you would have H323-UserInformation chunk of ASN.1 H323Extra chunk of ASN.1 Note that all the key ids and time stamps etc., would remain in the RasMessage and H323-UserInformation parts (so they get signed). I agree this is not beautiful, but it does not require multiple ASN.1 encodings, and doesn't radically change the format of the message depending on whether you want to sign it or not (as solution 4 seems to). I hope this sounds vaguely as though I know what I'm talking about!!! Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Bancroft Scott[SMTP:baos@OSS.COM] >Sent: 28 June 1998 17:35 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: ASN.1 accross revisions > >On Wed, 24 Jun 1998, Pekka Pessi wrote: > >> The current H.225.0 algorithm for calculating the ICV does not work well >> with the PER extension mechanism. > >Agreed. > >> The above algorithm (AFAIK I have understood it correctly) assumes that >> the sender and receiver can encode the PDU exactly in the same way. >>It is >> a reasonable assumption, as PER produces only one possible (canonical) >> encoding for given PDU. > >PER is not inherently canonical. To get canonical behavior you have to >either do as this set of standards have been doing and stay away from >types REAL and SET OF, or you have to use Canonical PER Aligned or >Canonical PER Unaligned. > >> However, there is a serious problem: the >> canonical representation changes if the ASN.1 SEQUENCE type is extended >> later. > >Correct. > >> When encoding this, the length of extension bitfield is 2. However, >> recipient B is using extended version of Foo like this: >> >> Foo ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL >> } > >A lot of research has gone into how to most effectively create ICV's >by the designers of the Secure Electronic Payment protocol (SET), >e-check protocol and others. That's why in SET you see the likes of: > > UnsignedCertificate ::= SEQUENCE { > version [0] CertificateVersion, > serialNumber CertificateSerialNumber, > signature AlgorithmIdentifier >{{SignatureAlgorithms}}, > issuer Name, > validity Validity, > subject Name, > subjectPublicKeyInfo >SubjectPublicKeyInfo{{SupportedAlgorithms}}, > issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, > subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, > extensions [3] Extensions -- Required for SET >usage > } > > -- Compute the encrypted hash of this value if issuing a >certificate, > -- or recompute the issuer's signature on this value if validating >a > -- certificate. > -- > EncodedCertificate ::= TYPE-IDENTIFIER.&Type (UnsignedCertificate) > > Certificate::= SIGNED { > EncodedCertificate > } ( CONSTRAINED BY { -- Verify Or Sign Certificate -- } ) > > SIGNED { ToBeSigned } ::= SEQUENCE { > toBeSigned ToBeSigned, > algorithm AlgorithmIdentifier {{SignatureAlgorithms}}, > signature BIT STRING > } > >The key thing to notice is that they DO NOT attempt to sign the >unencoded >certificate (i.e., UnsignedCertficate). The actual signing occurs on >an >open type which has been constrained to carry the value of the >particular >type that is to be signed (TYPE-IDENTIFIER.&Type >(UnsignedCertificate)). >In so doing, a) they clearly identify that the type should be encoded >independently of the ICV, b) they avoid having to do a re-encode of the >data after the CRV has been calculated, c) the type to which the ICV is >to >be applied can be extended with no problem, and d) they prepared >themselves for the possible use of PER by utilizing an open type to >carry >the value to be signed - something that is *crucial* to signing >PER-encoded data. > >> Problems with Non-OPTIONAL Extensions >> >> Another problem with some ASN.1 compilers is inclusion of non-OPTIONAL >> extensions. Let us assume that software C uses following ASN.1 >>definition >> for Foo: >> >> Foo ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL, >> criticalExtension OtherType >> } >> >> There are two kinds of problems with an extension like >>criticalExtension. >> First, the encoder may try to ensure that all encoded PDUs conform >>to the >> specification and signal an error when a PDU without >>criticalExtension is >> encoded. > >That's the correct behavior only if you are originating a message. >Encoders should not complain about criticalExtension being absent >if they are not originating the message. > >> Another problem is that the intermediate representation produced >> by the ASN.1 compiler may not provide means for application to express >> that criticalExtension is not present. (In other words, the produced >> structure usually contains a flag telling whether an optional field is >> present or not. Such flags are not included when the field is not >> optional.) > >It is an error for encoders not to encode extension additions that are >mandatory but missing if such extension additions do not occur within >an >extension addition group and if no other extension addition values >follow >the missing but mandatory extension. (I don't believe H.225 employs >extension addition groups (i.e., the "[[" and "]]" notation.)) This is >indicated in X.680:1997 clause 7.1 (X.680:1994 Amd.1 clause 6.1) which >unconditionally mandates that it be possible for decoded components >that >are defined to both the sender and receiver be re-encodable by the >receiver. > >> The presense or absence of the OPTIONAL flag in an extension does not >> change the PER encoding of the SEQUENCE. In order to avoid previously >> mentioned problems, application may use a version of ASN.1 notation that >> has extra OPTIONAL keyword after each extension. > >Neat! A nice and simple solution for use with such compilers. > >> Solution 1: Clarification to the PER Encoding Process >> >> The text in PER document (X.691, 1994) is somewhat ambiguous how many >> bits should be included in the extension present bitfield of >>SEQUENCE. To >> quote verbatim: "Let the number of extension additions in the type being > >Note that it says the *type* being encoded, not the value. That's >distinct from the value. > >> encoded be "n", then a bit-field with "n" bits shall be produced for >> addition to the field-list." (Is the "type being encoded" the abstract >> syntax or an actual value like { bar 1, baz 2 }?) However, the 0 >>bits at >> the end of extension present bitfield can be left out without changing >> the resulting semantics: the corresponding extensions are not present. > >It is true that they can be left out without changing the semantics, >but >this is not what PER mandates (It should have mandated what you >suggest, >but hindsight is 20-20.) Unless everyone encodes according to PER its >canonical nature will be lost. > >> As a result, the PER encoding does not change after a new extension >> is added to the ASN.1 specification. >> This solution, while leaving H.225.0 v2 protocol as it is, requires >> however changes to some existing ASN.1 compilers, and in a pessimal >>case, >> to the X.691 standard text, too. > >Yes, this would work, but as you point out, it requires that PER be >changed. > >> Solution 2: Hack >> >> The receiving application does not decode and the re-encode the PDU, but >> rather removes the ICV from the encoded PDU. In practice, this >>requires that >> application can identify PER-encoded fields within the PDU and it can >> regenerate them, i.e. it has effectively the same functionality as >>a PER >> encoder/decoder. >> >> Solution 3: Calculating ICV Differently >> >> The following algorithm for generating and checking the ICV makes it >> possible to avoid all the previously mentioned problems. The >>problems are >> avoided by breaking the protocol layering, the application changes >>directly >> the PER-encoded PDU: >> >> integrityCheckValue - provides improved message integrity/message >> authentication of the RAS messages. The cryptographically based >> integrity check value is computed by the sender applying a >> negotiated integrity algorithm and the secret key upon the entire >> message. Prior to integrityCheckValue computation an ICV with a >> previously agreed magic value (or key when using MDC) will be >> inserted to this field. The magic value will contain same >> algorithmOID and exactly as many bits in the icv BIT STRING as the >> computed value. After computation, the sender replaces the magic >> value with the computed integrity check value and transmits >> message. The receiver decodes message, replaces the received >> integrity value with the magic value, calculates the ICV and >> compares it with the received value. >> >> NOTE: The sender or receiver can encode the ICV separately and replace >> it directly within the encoded PDU, when the magic ICV and computed >> ICV have exactly the same length. When replacing ICV value within >> an encoded PDU, re-encoding the whole PDU can be avoided. > >I don't like this too much because of the possibility, though low, >of the data containing the magic ICV value. Still I prefer it to >solutions 1 and 2. > >> Solution 4: >> >> Fourth alternative is to treat encoded RasMessage as octet string. IVC >> can be calculated over that octet string and appended to the PDU on >> separate layer. E.g., RAS PDU could be defined as follows: >> >> RasMessage ::= CHOICE { >> -- all previous RasMessage CHOICEs are here >> authenticatedRasMessage SEQUENCE { >> plainRasMessage OCTET STRING, >> ivc IVC, >> ... >> } >> } > >This is effectively what is done in SET and other security-conscious >protocols, though they typically use open type instead of octet string. > >Alternate Solution 1: > >To do exactly as is done in SET, you would define RasMessage without an >ICV, and define a container, AuthenticatedRasMessage, say, that carries >the encoded RasMessage as an open type value (i.e., octet-aligned, and >padded with 0-bits at the end to ensure that it is an integral multiple >of >8 bits) followed by the ICV value. In other words: > > AuthenticatedRasMessage ::= SEQUENCE { > plainRasMessage TYPE-IDENTIFIER.&Type (RasMessage), > ivc IVC > } > >Using this approach, the RasMessage (which would be defined without an >ICV) would be encoded, then the ICV would be calculated using the >encoded >RasMessage, then AuthenticatedRasMessage would be encoded. This >approach >is efficient because RasMessage does not have to be encoded without >the ICV value then re-encoded with it, nor does it require that the >encoded value be tinkered with in any way. > >This technique is good only if backward compatibility is not an issue >(i.e., if you don't already have a deployed version of H.225), for the >open type carries a length component than an ordinary encoded >RasMessage >does not have. > >Alternate Solution 2: > >If backward compatibility is an issue then Solution 4 above is a better >alternative, though I would change it to: > > RasMessage ::= CHOICE { > -- all previous RasMessage CHOICEs are here > authenticatedRasMessage AuthenticatedRasMessage > } > >Open type and octet string produce identical encodings, but I have a >preference for the open type notation because it allows you to clearly >identify what the value is - in this case an encoded RasMessage, and >because it can simplify implementations that may not have a need to >authenticate the RasMessage upon decoding (e.g., line monitors.) > >I am not intimate with H.225, so I don't know for sure of Solution 4 >or this minor variation is backward compatible. It is if the ICV was >just introduced, else I don't think it is. > >------------------------------------------------------------------------ >-- >Bancroft Scott Toll Free >:1-888-OSS-ASN1 >Open Systems Solutions, Inc. >International:1-609-987-9073 >baos(a)oss.com Tech Support >:1-732-249-5107 >http://www.oss.com Fax >:1-732-249-4636 >

2 1

Re: Report of the Cannes meeting
by Roy, Radhika R, ALTEC 30 Jun '98

30 Jun '98

Dear Mr. Toga: Yes, I agreed to bring more concrete proposals along the line that I stated. A good amount of work is needed in this area. Sincerely, Radhika R. Roy AT&T > ---------- > From: Jim Toga[SMTP:jim.toga@INTEL.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Monday, June 29, 1998 3:51 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Report of the Cannes meeting > > Dear Mr Roy, > > Although I was unable to attend the meeting in Cannes, I have read all the > previous reports and have spoken to a number of people that attended. > There were many discussions during the meeting, which are summarized in > the meeting report without re-hashing every detail. My understanding is > that there were no objections from _anyone_ else at the meeting to > progressing the work that has been started in APC-1422. The intent will > be > to have both telephone and email exchanges to further develop this work. > I would look forward to having your constructive input as we move forward. > In the spirit of this, I would like to elicit your input here. > > I would like to point out a couple of misconceptions you might have based > upon the text below and ask you for some concrete proposals in areas where > you feel they're needed... > > Best Regards, > jimt. > > > [SNIP] > > > > >Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) > > > >APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" > > > >Mr. Roy also pointed out the following: > > If these points were raised in the APC document and covered during the > meeting why do they need to be called out explicitly in the meeting > report? > The list of contributed documents is part of the meeting. > > > > > * H.323 signaling schemes that were developed for > >H.323v1 in view of the LAN-based single GK model > > Both v1 and v2 have never limited GK deployment to one entity (on the LAN > or any other topology) The defined signalling for address resolution > allows for N gatekeepers. > > >(signaling schemes in > >H.323v2 also remain almost the same so far the inter-GK communication is > >concerned) may not be good enough to satisfy all needs when it is applied > in > >the context of multiple gatekeeper environment with different inter-GK > >architectures: Distributive, Centralized, and Hybrid (Distributive + > >Centralized). > > (I think you mean 'Distributed' above) In any case, these different > modes > of operation define models with respect to _media_ distribution, not > control. In this case they would (and do) affect the operation of an MCU. > (this is not to say that the MCU can't be co-located with the GK). > > V1 and V2 (and certainly the intent with V3) allow for many different GK > topologies with hierarchical being one of the more general ones. Flat > peer-peer models may be accomplished by having a degenerative 'hiearchy' > with a depth of 1. > > > * Each inter-GK architecture may need different > >signaling schemes in order to optimize the use of communication resources > >especially in the context large networks for both connectionless and > >connection oriented networks. > > Can you eloborate on this? Are you simply saying that we need to allow > both UDP and TCP signalling (which is in fact specified in section 4 of > APC-1422). > > > > > >APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper > >Communications" > > > >During the discussion of Intel's contribution, Mr. Roy also pointed out > that > >this proposal appears to have the following limitations: > > > > * The relationship between the zone (or internal) > and > >the border (or domain) gatekeeper is not defined: is it hierarchical or > >what? > > As described in section 2 of APC-1422 the only difference (in terms of > protocol interactions) between a GK acting as 'border GK' and an > 'internal' GK is that fact that the border GKs may communicate with border > GKs from other administrative domains. There are no specific models of > deployment within an admistrative domain. Some organizaitons will choose > to develop a hierachical model, others may choose to have a star topology, > or perhaps a flat domain. It makes no difference to the signalling > between > administrative domains and the current signalling can facilitate all of > these models. Can you offer any specific topologies that you believe > will > not work and cannot exploit this signalling? > > > * Does it mandates the use of proprietary protocols > >between the zone (or internal) and domain (or border) gatekeeper? > > It certainly does not _disallow_ proprietary protocols, but the intent > would be to support standard messages internal to an adminstrative domain > (which may be made up of a number of zones BTW...) as well as using these > standard messages between administrative domains. > > > > * The relationship between the multiple domain > >gatekeepers has not been defined: how communications occur in view of the > >multiple domain gatekeepers? > > The definition of 'relationship' is multi-faceted. Many of the aspects of > a 'relationship' may in fact be business related, and outside this realm. > One of the points of annex G is to provide some signalling which will > allow > administrative domains (again an organizational term, not a formal H.323 > topology term) to exchange information so that they can define the > "relationship between the multiple domain..." > > > > > * As if it mandates a specific implementation > scheme > >that may limit its scalability once one starts to use the gatekeeper > >discovery, address translation, admission control, and/or bandwidth/QOS > >control signaling messages for this particular architecture while a large > >network that may use highly distributive, centralized, and hybrid > inter-GK > >architecture. > > I'm really not sure what you asking/saying here...can you clarify this? > > > > >Therefore, Mr. Roy has the following view: > > > > * It requires a fundamental understanding of the > >logical relationships for inter-GK communications in view of the > >distributive, centralized, and hybrid inter-GK architecture that might be > >scaleable in view of large networks for both connectionless and > connection > >oriented networking environment. > > I think you mixing a number of things here (some of which have no > relevance). Can you break this up unto a number simple points - so that a > simple person such as I can understand? :-) > > > > * AT&T's contribution (APC-1382) has been the first > >step in that direction. > > You may note that a number of the definitions and clarificaitons from > Yokuska to Cannes were a direct result of APC-1382 - thank you. > > > > >------------------------------------------------------------------------- > --- > >------------------------------------------------------------------------- > --- > >--- > > > >I would appreciate a prompt action from your end. > > > >Sincerely, > > > >Radhika R. Roy > >AT&T > >Room 1K-330 > >101 Crawfords Corner Road > >Holmdel, NJ 07733 > >Tel: +1 732 949 8657 > >Fax: + 1 732 949 8569 > >e-mail: rrroy(a)att.com > > > > > >> ---------- > >> From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] > >> Reply To: Mailing list for parties associated with ITU-T Study > Group > >> 16 > >> Sent: Thursday, June 25, 1998 11:49 PM > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Report of the Cannes meeting > >> > >> Dear Q.12-14/16 experts, > >> > >> I have uploaded draft report of the Cannes meeting (APC-1425) at the > >> /Incoming directory. > >> > >> ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip > >> /APC-1425_w95.zip > >> > >> w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) > >> with Word 97. w95 is a version converted into Word 6/95; there are > >> obvious errors in section numbering and figures. > >> > >> Please review it in a week time, and give me any comments. I will then > >> complete it, uploade it at /9806_Can directory and send its copies to > >> the SG16 management. > >> > >> Best regards, > >> > >> Sakae OKUBO (Mr.) > >> *********************************************************** > >> Waseda Research Center > >> Telecommunications Advancement Organization of Japan (TAO) > >> 5th Floor, Nishi-Waseda Bldg. > >> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > >> 169-0051 Japan > >> Tel: +81 3 5286 3830 > >> Fax: +81 3 5287 7287 > >> e-mail: okubo(a)giti.or.jp > >> *********************************************************** > >> > > > > > > ***************************************************** > *** +1-503-264-8816(voice) Intel - Hillsboro, OR. > *** > *** mailto:jim.toga@intel.com mailto:james.toga@itu.ch > *** > *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** > ***************************************************** >

1 0

Re: Report of the Cannes meeting
by Roy, Radhika R, ALTEC 29 Jun '98

29 Jun '98

Dear Mr. OKUBO: With respect to the report (APC-1425) of the Cannes meeting, I would appreciate if you would add the following for the completeness of the report: ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------- Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" Mr. Roy also pointed out the following: * H.323 signaling schemes that were developed for H.323v1 in view of the LAN-based single GK model (signaling schemes in H.323v2 also remain almost the same so far the inter-GK communication is concerned) may not be good enough to satisfy all needs when it is applied in the context of multiple gatekeeper environment with different inter-GK architectures: Distributive, Centralized, and Hybrid (Distributive + Centralized). * Each inter-GK architecture may need different signaling schemes in order to optimize the use of communication resources especially in the context large networks for both connectionless and connection oriented networks. APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper Communications" During the discussion of Intel's contribution, Mr. Roy also pointed out that this proposal appears to have the following limitations: * The relationship between the zone (or internal) and the border (or domain) gatekeeper is not defined: is it hierarchical or what? * Does it mandates the use of proprietary protocols between the zone (or internal) and domain (or border) gatekeeper? * The relationship between the multiple domain gatekeepers has not been defined: how communications occur in view of the multiple domain gatekeepers? * As if it mandates a specific implementation scheme that may limit its scalability once one starts to use the gatekeeper discovery, address translation, admission control, and/or bandwidth/QOS control signaling messages for this particular architecture while a large network that may use highly distributive, centralized, and hybrid inter-GK architecture. Therefore, Mr. Roy has the following view: * It requires a fundamental understanding of the logical relationships for inter-GK communications in view of the distributive, centralized, and hybrid inter-GK architecture that might be scaleable in view of large networks for both connectionless and connection oriented networking environment. * AT&T's contribution (APC-1382) has been the first step in that direction. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- --- I would appreciate a prompt action from your end. Sincerely, Radhika R. Roy AT&T Room 1K-330 101 Crawfords Corner Road Holmdel, NJ 07733 Tel: +1 732 949 8657 Fax: + 1 732 949 8569 e-mail: rrroy(a)att.com > ---------- > From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Thursday, June 25, 1998 11:49 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Report of the Cannes meeting > > Dear Q.12-14/16 experts, > > I have uploaded draft report of the Cannes meeting (APC-1425) at the > /Incoming directory. > > ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip > /APC-1425_w95.zip > > w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) > with Word 97. w95 is a version converted into Word 6/95; there are > obvious errors in section numbering and figures. > > Please review it in a week time, and give me any comments. I will then > complete it, uploade it at /9806_Can directory and send its copies to > the SG16 management. > > Best regards, > > Sakae OKUBO (Mr.) > *********************************************************** > Waseda Research Center > Telecommunications Advancement Organization of Japan (TAO) > 5th Floor, Nishi-Waseda Bldg. > 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > 169-0051 Japan > Tel: +81 3 5286 3830 > Fax: +81 3 5287 7287 > e-mail: okubo(a)giti.or.jp > *********************************************************** >

2 1

Re: Report of the Cannes meeting
by Jim Toga 29 Jun '98

29 Jun '98

Dear Mr Roy, Although I was unable to attend the meeting in Cannes, I have read all the previous reports and have spoken to a number of people that attended. There were many discussions during the meeting, which are summarized in the meeting report without re-hashing every detail. My understanding is that there were no objections from _anyone_ else at the meeting to progressing the work that has been started in APC-1422. The intent will be to have both telephone and email exchanges to further develop this work. I would look forward to having your constructive input as we move forward. In the spirit of this, I would like to elicit your input here. I would like to point out a couple of misconceptions you might have based upon the text below and ask you for some concrete proposals in areas where you feel they're needed... Best Regards, jimt. [SNIP] > >Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) > >APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" > >Mr. Roy also pointed out the following: If these points were raised in the APC document and covered during the meeting why do they need to be called out explicitly in the meeting report? The list of contributed documents is part of the meeting. > > * H.323 signaling schemes that were developed for >H.323v1 in view of the LAN-based single GK model Both v1 and v2 have never limited GK deployment to one entity (on the LAN or any other topology) The defined signalling for address resolution allows for N gatekeepers. >(signaling schemes in >H.323v2 also remain almost the same so far the inter-GK communication is >concerned) may not be good enough to satisfy all needs when it is applied in >the context of multiple gatekeeper environment with different inter-GK >architectures: Distributive, Centralized, and Hybrid (Distributive + >Centralized). (I think you mean 'Distributed' above) In any case, these different modes of operation define models with respect to _media_ distribution, not control. In this case they would (and do) affect the operation of an MCU. (this is not to say that the MCU can't be co-located with the GK). V1 and V2 (and certainly the intent with V3) allow for many different GK topologies with hierarchical being one of the more general ones. Flat peer-peer models may be accomplished by having a degenerative 'hiearchy' with a depth of 1. > * Each inter-GK architecture may need different >signaling schemes in order to optimize the use of communication resources >especially in the context large networks for both connectionless and >connection oriented networks. Can you eloborate on this? Are you simply saying that we need to allow both UDP and TCP signalling (which is in fact specified in section 4 of APC-1422). > >APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper >Communications" > >During the discussion of Intel's contribution, Mr. Roy also pointed out that >this proposal appears to have the following limitations: > > * The relationship between the zone (or internal) and >the border (or domain) gatekeeper is not defined: is it hierarchical or >what? As described in section 2 of APC-1422 the only difference (in terms of protocol interactions) between a GK acting as 'border GK' and an 'internal' GK is that fact that the border GKs may communicate with border GKs from other administrative domains. There are no specific models of deployment within an admistrative domain. Some organizaitons will choose to develop a hierachical model, others may choose to have a star topology, or perhaps a flat domain. It makes no difference to the signalling between administrative domains and the current signalling can facilitate all of these models. Can you offer any specific topologies that you believe will not work and cannot exploit this signalling? > * Does it mandates the use of proprietary protocols >between the zone (or internal) and domain (or border) gatekeeper? It certainly does not _disallow_ proprietary protocols, but the intent would be to support standard messages internal to an adminstrative domain (which may be made up of a number of zones BTW...) as well as using these standard messages between administrative domains. > * The relationship between the multiple domain >gatekeepers has not been defined: how communications occur in view of the >multiple domain gatekeepers? The definition of 'relationship' is multi-faceted. Many of the aspects of a 'relationship' may in fact be business related, and outside this realm. One of the points of annex G is to provide some signalling which will allow administrative domains (again an organizational term, not a formal H.323 topology term) to exchange information so that they can define the "relationship between the multiple domain..." > * As if it mandates a specific implementation scheme >that may limit its scalability once one starts to use the gatekeeper >discovery, address translation, admission control, and/or bandwidth/QOS >control signaling messages for this particular architecture while a large >network that may use highly distributive, centralized, and hybrid inter-GK >architecture. I'm really not sure what you asking/saying here...can you clarify this? > >Therefore, Mr. Roy has the following view: > > * It requires a fundamental understanding of the >logical relationships for inter-GK communications in view of the >distributive, centralized, and hybrid inter-GK architecture that might be >scaleable in view of large networks for both connectionless and connection >oriented networking environment. I think you mixing a number of things here (some of which have no relevance). Can you break this up unto a number simple points - so that a simple person such as I can understand? :-) > * AT&T's contribution (APC-1382) has been the first >step in that direction. You may note that a number of the definitions and clarificaitons from Yokuska to Cannes were a direct result of APC-1382 - thank you. > >---------------------------------------------------------------------------- >---------------------------------------------------------------------------- >--- > >I would appreciate a prompt action from your end. > >Sincerely, > >Radhika R. Roy >AT&T >Room 1K-330 >101 Crawfords Corner Road >Holmdel, NJ 07733 >Tel: +1 732 949 8657 >Fax: + 1 732 949 8569 >e-mail: rrroy(a)att.com > > >> ---------- >> From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] >> Reply To: Mailing list for parties associated with ITU-T Study Group >> 16 >> Sent: Thursday, June 25, 1998 11:49 PM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Report of the Cannes meeting >> >> Dear Q.12-14/16 experts, >> >> I have uploaded draft report of the Cannes meeting (APC-1425) at the >> /Incoming directory. >> >> ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip >> /APC-1425_w95.zip >> >> w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) >> with Word 97. w95 is a version converted into Word 6/95; there are >> obvious errors in section numbering and figures. >> >> Please review it in a week time, and give me any comments. I will then >> complete it, uploade it at /9806_Can directory and send its copies to >> the SG16 management. >> >> Best regards, >> >> Sakae OKUBO (Mr.) >> *********************************************************** >> Waseda Research Center >> Telecommunications Advancement Organization of Japan (TAO) >> 5th Floor, Nishi-Waseda Bldg. >> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo >> 169-0051 Japan >> Tel: +81 3 5286 3830 >> Fax: +81 3 5287 7287 >> e-mail: okubo(a)giti.or.jp >> *********************************************************** >> > > ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@itu.ch *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************

1 0

Re: ASN.1 across revisions
by Paul Long 29 Jun '98

29 Jun '98

>From: Bancroft Scott[SMTP:baos@OSS.COM] >On Sun, 28 Jun 1998, Paul Long wrote: >> So, Bancroft, are you saying that it would be an error if FooGone, >> below, were encoded where Foo was called for? >> Foo ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL, >> criticalExtension OtherType >> } >> FooGone ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL >> } >X.691:1997 clause 24.14 (X.691:1994 Amd.1 clause "11 >Changes to SEQUENCE") stipulates that if you are originating an encoding >(i.e., not relaying it) you are required to encode criticalExtension. Right, that's what I meant. I should have said, "Are you saying that--if originating the encoding--it would be an error if FooGone were encoded where Foo was called for?" With this qualification, your answer would apparently be, "Yes, it would be an error." > >> Likewise, are you saying that it would be an error if FooOpt, below, >> were encoded, without the value of criticalExtension present, in place >> of Foo, because the extension addition is mandatory in Foo? >> FooOpt ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL, >> criticalExtension OtherType OPTIONAL >> } >This change to the type is transparent to the communicating peer. Indeed, >unless you go out of your to indicate to the encoder whether you are >originating and encoding it is impossible in ASN.1:1994 for an encoder to >know whether the absence of criticalExtension is an error. Hey, I just realized something. When you say, "encoder," you are referring strictly to the ASN.1 encoder, right? I often think of the encoder as the larger, "encoding entity," such as an H.323 endpoint, which usually knows more than the encoder. I think you call this the "sender." So if the encoder, using your definition, is presented with FooOpt, above, and a value is not provided to the encoder for criticalExtension, the encoder does not, of course, know that this is an error. What I'm saying is that if the sender, or encoding entity, uses FooOpt in place of Foo, and the value for criticalExtension is not present, the encoder is not at fault for producing an encoding, but the sender is at fault, because it is not using the prescribed definition of Foo for the version of the Recommendation of which it is an implementaion and which is identified in the protocolIdentifier field(s). To look at it from the other direction, the receiver, or decoding entity, doesn't care whether the encoder or the sender is at fault--it just knows that the sender is producing an incorrect encoding. >it is impossible in ASN.1:1994 for an encoder to >know whether the absence of criticalExtension is an error. In ASN.1:1997 >this imprecision is resolved by the use of version brackets. For example, >if you wrote: > > Foo ::= SEQUENCE > { > bar INTEGER (0..127), > ..., > [[, > baz INTEGER (0..255) OPTIONAL, > integrityCheckValue ICV OPTIONAL, > importantExtension SomeType OPTIONAL, > criticalExtension OtherType, > ]] > } > >it would be clear that baz - criticalExtension were all added in the same >version, so if any of the optional items are present then criticalExtension >must also be present. Can't the same thing be done in ASN.1:1994 by encapsulating the extension additions of a particular version within a SEQUENCE like this? FooEncap2 ::= SEQUENCE { bar INTEGER (0..127), ..., SEQUENCE { baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, criticalExtension OtherType } } and this? FooEncap3 ::= SEQUENCE { bar INTEGER (0..127), ..., SEQUENCE { baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL }, SEQUENCE { importantExtension SomeType OPTIONAL, criticalExtension OtherType } } Seems like this would allow one to produce the same encoding with ASN.1:1994 as what would be produced by the version brackets in ASN.1:1997, or am I missing something? Perhaps this is how we should extend ASN.1 types in the future. > >> So are you saying that if an ASN.1 type in a Recommendation contains an >> extension addition, such as criticalExtension in Foo, above, an >> implementation of that Recommendation _must_ represent that extension >> addition in all encodings of that type? >It is in error only if you are originating the encoding in which >criticalExtension is defined. Okay, yes, I meant that one is originating the encoding. That's really the only way I think about encoding. Again, with this qualification, your answer would be, "Yes, it would be an error." >ASN.1:1994 does not have syntax that makes >it possible for an encoder to determine whether criticalExtension is >unconditionally mandatory (it would be if all four extension additions >were added in the same version), or if it were added after the other >extension additions (in which case it would be mandatory only if the >sender is originating the message.) I'm saying that all four are defined in the same version of ASN.1 syntax and that the sender is originating the message. > >> If so, I assume this would be because, technically, >> another type was being encoded, not the one defined in the >> Recommendation, as in "Let the number of extension additions in _the >> type being encoded_ be 'n'..." >I don't follow what you mean here. Sorry. I meant that this citation from 18.7/X.691:1994 indicates to me that, for an originator, all extension additions defined for a type must be represented--one cannot simply leave off one or more trailing extension additions from a type that is defined in the version of the Recommendation that the sender has implemented, as would be the case if FooGone were used in place of Foo, for example. Likewise, for an originator, Foo is "the type being encoded," and an invalid encoding would be produced if FooOpt was used in place of Foo, and a value was not provided for criticalExtension. Paul Long

1 0

Re: ASN.1 accross revisions
by Bancroft Scott 29 Jun '98

29 Jun '98

On Wed, 24 Jun 1998, Pekka Pessi wrote: > The current H.225.0 algorithm for calculating the ICV does not work well > with the PER extension mechanism. Agreed. > The above algorithm (AFAIK I have understood it correctly) assumes that > the sender and receiver can encode the PDU exactly in the same way. It is > a reasonable assumption, as PER produces only one possible (canonical) > encoding for given PDU. PER is not inherently canonical. To get canonical behavior you have to either do as this set of standards have been doing and stay away from types REAL and SET OF, or you have to use Canonical PER Aligned or Canonical PER Unaligned. > However, there is a serious problem: the > canonical representation changes if the ASN.1 SEQUENCE type is extended > later. Correct. > When encoding this, the length of extension bitfield is 2. However, > recipient B is using extended version of Foo like this: > > Foo ::= SEQUENCE > { > bar INTEGER (0..127), > ..., > baz INTEGER (0..255) OPTIONAL, > integrityCheckValue ICV OPTIONAL, > importantExtension SomeType OPTIONAL > } A lot of research has gone into how to most effectively create ICV's by the designers of the Secure Electronic Payment protocol (SET), e-check protocol and others. That's why in SET you see the likes of: UnsignedCertificate ::= SEQUENCE { version [0] CertificateVersion, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier {{SignatureAlgorithms}}, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo{{SupportedAlgorithms}}, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] Extensions -- Required for SET usage } -- Compute the encrypted hash of this value if issuing a certificate, -- or recompute the issuer's signature on this value if validating a -- certificate. -- EncodedCertificate ::= TYPE-IDENTIFIER.&Type (UnsignedCertificate) Certificate::= SIGNED { EncodedCertificate } ( CONSTRAINED BY { -- Verify Or Sign Certificate -- } ) SIGNED { ToBeSigned } ::= SEQUENCE { toBeSigned ToBeSigned, algorithm AlgorithmIdentifier {{SignatureAlgorithms}}, signature BIT STRING } The key thing to notice is that they DO NOT attempt to sign the unencoded certificate (i.e., UnsignedCertficate). The actual signing occurs on an open type which has been constrained to carry the value of the particular type that is to be signed (TYPE-IDENTIFIER.&Type (UnsignedCertificate)). In so doing, a) they clearly identify that the type should be encoded independently of the ICV, b) they avoid having to do a re-encode of the data after the CRV has been calculated, c) the type to which the ICV is to be applied can be extended with no problem, and d) they prepared themselves for the possible use of PER by utilizing an open type to carry the value to be signed - something that is *crucial* to signing PER-encoded data. > Problems with Non-OPTIONAL Extensions > > Another problem with some ASN.1 compilers is inclusion of non-OPTIONAL > extensions. Let us assume that software C uses following ASN.1 definition > for Foo: > > Foo ::= SEQUENCE > { > bar INTEGER (0..127), > ..., > baz INTEGER (0..255) OPTIONAL, > integrityCheckValue ICV OPTIONAL, > importantExtension SomeType OPTIONAL, > criticalExtension OtherType > } > > There are two kinds of problems with an extension like criticalExtension. > First, the encoder may try to ensure that all encoded PDUs conform to the > specification and signal an error when a PDU without criticalExtension is > encoded. That's the correct behavior only if you are originating a message. Encoders should not complain about criticalExtension being absent if they are not originating the message. > Another problem is that the intermediate representation produced > by the ASN.1 compiler may not provide means for application to express > that criticalExtension is not present. (In other words, the produced > structure usually contains a flag telling whether an optional field is > present or not. Such flags are not included when the field is not > optional.) It is an error for encoders not to encode extension additions that are mandatory but missing if such extension additions do not occur within an extension addition group and if no other extension addition values follow the missing but mandatory extension. (I don't believe H.225 employs extension addition groups (i.e., the "[[" and "]]" notation.)) This is indicated in X.680:1997 clause 7.1 (X.680:1994 Amd.1 clause 6.1) which unconditionally mandates that it be possible for decoded components that are defined to both the sender and receiver be re-encodable by the receiver. > The presense or absence of the OPTIONAL flag in an extension does not > change the PER encoding of the SEQUENCE. In order to avoid previously > mentioned problems, application may use a version of ASN.1 notation that > has extra OPTIONAL keyword after each extension. Neat! A nice and simple solution for use with such compilers. > Solution 1: Clarification to the PER Encoding Process > > The text in PER document (X.691, 1994) is somewhat ambiguous how many > bits should be included in the extension present bitfield of SEQUENCE. To > quote verbatim: "Let the number of extension additions in the type being Note that it says the *type* being encoded, not the value. That's distinct from the value. > encoded be "n", then a bit-field with "n" bits shall be produced for > addition to the field-list." (Is the "type being encoded" the abstract > syntax or an actual value like { bar 1, baz 2 }?) However, the 0 bits at > the end of extension present bitfield can be left out without changing > the resulting semantics: the corresponding extensions are not present. It is true that they can be left out without changing the semantics, but this is not what PER mandates (It should have mandated what you suggest, but hindsight is 20-20.) Unless everyone encodes according to PER its canonical nature will be lost. > As a result, the PER encoding does not change after a new extension > is added to the ASN.1 specification. > This solution, while leaving H.225.0 v2 protocol as it is, requires > however changes to some existing ASN.1 compilers, and in a pessimal case, > to the X.691 standard text, too. Yes, this would work, but as you point out, it requires that PER be changed. > Solution 2: Hack > > The receiving application does not decode and the re-encode the PDU, but > rather removes the ICV from the encoded PDU. In practice, this requires that > application can identify PER-encoded fields within the PDU and it can > regenerate them, i.e. it has effectively the same functionality as a PER > encoder/decoder. > > Solution 3: Calculating ICV Differently > > The following algorithm for generating and checking the ICV makes it > possible to avoid all the previously mentioned problems. The problems are > avoided by breaking the protocol layering, the application changes directly > the PER-encoded PDU: > > integrityCheckValue - provides improved message integrity/message > authentication of the RAS messages. The cryptographically based > integrity check value is computed by the sender applying a > negotiated integrity algorithm and the secret key upon the entire > message. Prior to integrityCheckValue computation an ICV with a > previously agreed magic value (or key when using MDC) will be > inserted to this field. The magic value will contain same > algorithmOID and exactly as many bits in the icv BIT STRING as the > computed value. After computation, the sender replaces the magic > value with the computed integrity check value and transmits > message. The receiver decodes message, replaces the received > integrity value with the magic value, calculates the ICV and > compares it with the received value. > > NOTE: The sender or receiver can encode the ICV separately and replace > it directly within the encoded PDU, when the magic ICV and computed > ICV have exactly the same length. When replacing ICV value within > an encoded PDU, re-encoding the whole PDU can be avoided. I don't like this too much because of the possibility, though low, of the data containing the magic ICV value. Still I prefer it to solutions 1 and 2. > Solution 4: > > Fourth alternative is to treat encoded RasMessage as octet string. IVC > can be calculated over that octet string and appended to the PDU on > separate layer. E.g., RAS PDU could be defined as follows: > > RasMessage ::= CHOICE { > -- all previous RasMessage CHOICEs are here > authenticatedRasMessage SEQUENCE { > plainRasMessage OCTET STRING, > ivc IVC, > ... > } > } This is effectively what is done in SET and other security-conscious protocols, though they typically use open type instead of octet string. Alternate Solution 1: To do exactly as is done in SET, you would define RasMessage without an ICV, and define a container, AuthenticatedRasMessage, say, that carries the encoded RasMessage as an open type value (i.e., octet-aligned, and padded with 0-bits at the end to ensure that it is an integral multiple of 8 bits) followed by the ICV value. In other words: AuthenticatedRasMessage ::= SEQUENCE { plainRasMessage TYPE-IDENTIFIER.&Type (RasMessage), ivc IVC } Using this approach, the RasMessage (which would be defined without an ICV) would be encoded, then the ICV would be calculated using the encoded RasMessage, then AuthenticatedRasMessage would be encoded. This approach is efficient because RasMessage does not have to be encoded without the ICV value then re-encoded with it, nor does it require that the encoded value be tinkered with in any way. This technique is good only if backward compatibility is not an issue (i.e., if you don't already have a deployed version of H.225), for the open type carries a length component than an ordinary encoded RasMessage does not have. Alternate Solution 2: If backward compatibility is an issue then Solution 4 above is a better alternative, though I would change it to: RasMessage ::= CHOICE { -- all previous RasMessage CHOICEs are here authenticatedRasMessage AuthenticatedRasMessage } Open type and octet string produce identical encodings, but I have a preference for the open type notation because it allows you to clearly identify what the value is - in this case an encoded RasMessage, and because it can simplify implementations that may not have a need to authenticate the RasMessage upon decoding (e.g., line monitors.) I am not intimate with H.225, so I don't know for sure of Solution 4 or this minor variation is backward compatible. It is if the ICV was just introduced, else I don't think it is. -------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 Open Systems Solutions, Inc. International:1-609-987-9073 baos(a)oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636

2 1

Re: ASN.1 across revisions
by Paul Long 28 Jun '98

28 Jun '98

>From: Bancroft Scott[SMTP:baos@OSS.COM] >It is an error for encoders not to encode extension additions that are >mandatory but missing if such extension additions do not occur within an >extension addition group and if no other extension addition values follow >the missing but mandatory extension. (I don't believe H.225 employs >extension addition groups (i.e., the "[[" and "]]" notation.)) This is >indicated in X.680:1997 clause 7.1 (X.680:1994 Amd.1 clause 6.1) which >unconditionally mandates that it be possible for decoded components that >are defined to both the sender and receiver be re-encodable by the >receiver. So, Bancroft, are you saying that it would be an error if FooGone, below, were encoded where Foo was called for? Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL, criticalExtension OtherType } FooGone ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL } Likewise, are you saying that it would be an error if FooOpt, below, were encoded, without the value of criticalExtension present, in place of Foo, because the extension addition is mandatory in Foo? FooOpt ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL, criticalExtension OtherType OPTIONAL } > >> Solution 1: Clarification to the PER Encoding Process >> >> The text in PER document (X.691, 1994) is somewhat ambiguous how many >> bits should be included in the extension present bitfield of SEQUENCE. >>To >> quote verbatim: "Let the number of extension additions in the type being > >Note that it says the *type* being encoded, not the value. That's >distinct from the value. > >> encoded be "n", then a bit-field with "n" bits shall be produced for >> addition to the field-list." (Is the "type being encoded" the abstract >> syntax or an actual value like { bar 1, baz 2 }?) However, the 0 bits >>at >> the end of extension present bitfield can be left out without changing >> the resulting semantics: the corresponding extensions are not present. > >It is true that they can be left out without changing the semantics, but >this is not what PER mandates (It should have mandated what you suggest, >but hindsight is 20-20.) Unless everyone encodes according to PER its >canonical nature will be lost. So are you saying that if an ASN.1 type in a Recommendation contains an extension addition, such as criticalExtension in Foo, above, an implementation of that Recommendation _must_ represent that extension addition in all encodings of that type? IOW, although it may be "easy" to encode the type without that extension addition (the extension-addition bit-map does not contain a corresponding bit for that extension addition, the bit-map length value reflects this shortening, and the open type containing the value is not encoded), the encoding would be in error? If so, I assume this would be because, technically, another type was being encoded, not the one defined in the Recommendation, as in "Let the number of extension additions in _the type being encoded_ be 'n'..." > Paul Long

2 1

Files at the ftp site
by Sakae OKUBO 28 Jun '98

28 Jun '98

Dear Jean-Pierre, I have sorted out the files at the /Incoming directory of Q.12-14/16 ftp site. There are three gif files: TD-97, TD-98, TD-99. TD-99 has zero byte, and the remaining two appear irrelevant to the meeting. Do you have any ideas? I cannot find your TD-19 "Exhibition of a H.323 decentralized conference" anywhere. Could you please upload it? Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Minutes from Multimedia MIB audio call o
by George Kajos 26 Jun '98

26 Jun '98

SQ16 Q14 Multimedia Management Information Base Audio Call 6/24 Minutes Agenda 1. IETF submission/coordination 2. APC 1380 GW, MC, MP Annexes 3. Cannes summary The call started late because George gave out incorrect bridge numbers and it took the first 15 minutes of the call to try to get people onto the bridge. As a result a number of people couldn't get into the conference. Actual participants: Attendees Mike Thatcher, Cisco Zvi Mizrahy, Pnina Vortman, IBM Haifa Orit Levin, RadVision Joon Maeng, VTEL Bill Strahm, Mark Baugher, Intel Picturetel Ghislaine Griswold, Lucent Don Dewar, George Kajos, David Reich, Irina Suconick, VideoServer People unable to attend because of the phone number problem: Nicole Gallant, Nortel David Walker, Ashok Ganesan, and Annette Lanteigne, Mitel I apologize for the mistake. IETF It was agreed at the Cannes meeting to obtain IETF input to the Multimedia MIB. The procedure appears to be for George to send email to the Operations and Maintenance Area Directors requesting a working group, stating the interest of the number of companies involved and the existing body of work. George will volunteer to co-chair the working group. It was discussed whether the IETF would find a qualified co-chair, but we will wait until we get a response to the email request. George will put together a strawman charter and send this request by 6/26/98. A poll was taken as to whether there would be adequate representation at the August meeting and it was clear that there would be a number of companies in attendance. A recurring issue is whether the work is going to be performed at the IETF or the ITU-T. The model discussed is the details of content are clearly ITU charter work, while SNMP and MIB format and organization are inputs we expect to be likely from the IETF. The Multimedia MIB document APC-1380 is organized as a main document and a series of Annexes representing individual pieces. Yet some of the attendees though it might be more appropriate to separate the Annexes into possibly 3 MIB submissions; H323, H320, H245. This caused some confusion as to where the GW MIB would go. It was decided to finish the Annexes of the Multimedia MIB document before concluding the format of the submission to the IETF. GW, MC, MP The GW, MC, and MP Annexes did not get submitted to the meeting at Cannes for the June ITU meeting. Zvi Mizrahy and Prina Vortman of IBM Haifa indicated they would send the gateway Annex APC1393 to the mailing list. One of the questions which was discussed was how to place the gateway in the overall hierarchy. It could probably be brought up to the main level rather than under H.323. The decision was deferred until the next meeting after the group had a chance to understand the proposal. One other element of the proposal was that there would be a set of definitions which would likely be moved up into the textual conventions and registration file. George also placed it in the avc-site\incoming directory on the Picturetel FTP site. VideoServer reiterated their intent to develop an MC and MP contribution of the next 2-3 weeks. Cannes review A brief summary of the Cannes meeting was discussed. First APC 1380 was presented which outlined the hierarchy and MIB organization. RTP was shown as Annex 1 in the document, but it is still an issue as to where it should appear. George, Irina and Joon discussed individual proposals. The RAS MIB and indexing issues reappeared. There was more discussion about correlation between admission and call signalling tables, but there's no conclusion. Gary Thom did not get feedback from his liaison to ITU SG4 on management. Thus, the whole effort is still on a dual path. Many present expressed a need to keep this work moving as rapidly as possible. Next Meeting: Wednesday, July 8, 1998 11:00 - 1:00 PM EST. Current Action Items: 1. George Kajos - Publish meeting minutes (this report) and schedule next conference. 2. George Kajos - Confer with ISO and IETF network management experts regarding placement of H.Multimedia MIB - generate request to O&M Area Director 3. Group - Admission table indices - Issue of index uniqueness waiting for example of a problem. 4. Group - Admission and CallSignalling Tables index correlation. 5. Group - review APC1393 (GW) from Zvi Mizrahy and Prina Vortman 6. VideoServer - Gernerate MC and MP proposal George Kajos VideoServer, Inc 63 Third Avenue Burlington, MA 01803 781-505-2193 (phone) 781-505-2101 (fax)

1 0