Liaison statements from SG15

OKUBO Sakae okubo at MXZ.MESH.NE.JP
Sat May 18 11:29:53 EDT 2002


G'Day,

If we have a H.460.1 Annex A that lists the current values can't the TSB be
responsible for maintaining and assigning values without having to go through
the full SG16 stamping procedure? They administer and assign other values. I
don't know that IANA would be supportive of registering values that are not
related to IETF standards.

Regards, Christian

Terry L Anderson wrote:
>
> The facts that GEF might be used outside the H.460.x series (would we
> even allow a non-ITU standard to define the use of one?) and additions
> might occur more often than are usually permitted for normative ITU
> recommendations might suggest using IANA.  This mechanism is used more
> commonly in IETF standards, but H.248 uses IANA to register package and
> property identifiers (of course our cooperation with MEGACO on this
> standard made this more natural).  IANA is a registry that is easily
> accessible to all and can be updated when needed without waiting to
> ballot a document.
>
> "Paul E. Jones" wrote:
>
> > Ernst, I do agree that we need a single place to list these.  In the
> > past, the thinking was to list such things in the Implementers Guide,
> > but I'm more inclined to argue that H.460.1, perhaps Annex A
> > (non-existent) would be the right place. Paul
> >
> >      ----- Original Message -----
> >      From: Horvath Ernst
> >      To: ITU-SG16 at echo.jf.INTEL.COM
> >      Sent: Wednesday, May 08, 2002 8:08 AM
> >      Subject: Rec. H.501 and "GEF" parameter repository
> >       Dear experts,
> >
> >      my H.501 final draft contained  a placeholder "annex B" for
> >      collecting "generic data" (i.e. standardized GEF identifier
> >      values). Upon advice by TSB, this annex will be removed in
> >      the published version 1 of H.501 since it contained no
> >      useful text.
> >
> >      The initial idea was to include here material from H.225.0
> >      annex G as soon as version 2 of annex G is finished. But now
> >      I have some doubts whether H.501 is the right place for such
> >      a data register. A repository of generic data should at
> >      least include also values assigned in GEF standards
> >      (H.460.x). Wouldn't the H.460 series be a better place for
> >      this?
> >
> >      At the top level we have assigned so far:
> >      - feature ID "0" for H.225.0 Annex G profiles
> >      - feature IDs "n" for H.460.n
> >      (is this the complete list?)
> >
> >      Each top-level feature ID opens a local name space for
> >      EnumeratedParameter-IDs specified for that specific feature.
> >      Since these are defined locally there is no danger of
> >      collisions.
> >
> >      At least the top-level IDs should be maintained at a central
> >      place to avoid collisions, especially if such IDs can be
> >      assigned outside H.460.n standards as well (is this
> >      generally the case, or is H.225.0 annex G the only
> >      exception?). Of course such a repository could also list the
> >      locally assigned EnumeratedParameter-IDs for each registered
> >      feature, to provide a quick reference.
> >
> >      So the question is, do people see the need for a
> >      generic-data register, and if yes, in which form? H.460.x?
> >      Or in an IG? H.501 does not seem to be the proper place.
> >
> >      Regards,
> >      Ernst Horvath
> >      Siemens AG
> >
> --
> -------------------------------------------------------
> Terry L Anderson, DMTS                   tla at lucent.com
> Lucent Technologies /INS/ Voice over IP Access Networks
> Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> Voice:908 582-7013  FAX:908 582-6226   Org:18E75000000
> http://its.lucent.com/~tla  (Lucent internal)
> http://www.gti.net/tla
> -------------------------------------------------------



More information about the sg16-avd mailing list