Errors / ambiguities / problems found in specs at last week's interop

[Rosen, Brian]

I put this idiot out of his misery  (fed him the welcome
message with the list management info).

Brian

> -----Original Message-----
> From: Sherlock, Stuart [mailto:stuart.sherlock at intel.com]
> Sent: Tuesday, March 14, 2000 9:38 AM
> To: ITU-SG16 at mailbag.cps.intel.com
> Subject: Re: Errors / ambiguities / problems found in specs at last
> week's interop
>
>
> How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I
> unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I
> unsubscribe?How do I unsubscribe?
>
> Get the question NOW?
>
> Thanks
> Stuart
> -----Original Message-----
> From: Sherlock, Stuart [mailto:stuart.sherlock at INTEL.COM]
> Sent: Monday, March 13, 2000 8:52 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Errors / ambiguities / problems found in specs at last
> week's interop
>
>
> How do I unsubscribe?
>
> Thanks
> Stuart
>
> -----Original Message-----
> From: Gene Schroeder [mailto:erschroeder at LUCENT.COM]
> Sent: Monday, March 13, 2000 8:41 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Errors / ambiguities / problems found in specs at last
> week'sinterop
>
>
> One common reason the gatekeeper might want to increase the
> registration TTL
> is to control the rate of incoming keep-alive RRQs.  If a
> gatekeeper has
> many endpoints registered, and these endpoints select a very
> low TTL (say a
> few seconds), then the gatekeeper will be forced into
> processing a high rate
> of keep-alive RRQs.  If the gatekeeper does not require nor
> need such timely
> information on endpoint status, then IMHO it should be able
> to specify a
> higher TTL in the RCF.  And it seems the endpoint should
> honor this request,
> just as if it would honor a lower TTL.
>
> Regards
> Gene Schroeder
> elemedia
>
> > -----Original Message-----
> > From: Mailing list for parties associated with ITU-T Study Group 16
> > [mailto:ITU-SG16 at mailbag.cps.intel.com]On Behalf Of Chris
> Wayman Purvis
> > Sent: Monday, March 13, 2000 9:02 AM
> > To: ITU-SG16 at mailbag.cps.intel.com
> > Subject: Re: Errors / ambiguities / problems found in specs at last
> > week'sinterop
> >
> >
> > Comments inline:
> >
> > "Johan Gerhardsson (ETX)" wrote:
> > >
> > > Hi folks,
> > >
> > > To clarify things:
> > >
> > > It seems that my writing was a bit sloppy when I wrote the
> > problems about TTL and SEQUENCE OF... on the interop. I intended
> > to describe two different problems:
> > >
> > > 1) GK cannot increase TTL in RCF.
> >
> > This is true.
> >
> > > 2) Mandatory parameters of type SEQUENCE OF ... can have
> empty list.
> >
> > This is also true.
> >
> > > 1)
> > > h323v2, 7.2.2:
> > > "The Gatekeeper may respond with an RCF containing the same
> > timeToLive or a shorter timeToLive.".
> > > As I see it, according to this, a GK is not allowed to increase
> > the timeToLive value proposed by the endpoint in RRQ, regardless
> > if the endpoint makes a full registration or a keep-alive
> registration.
> > >
> > > I think it should be possible for the gk to do it.
> >
> > I disagree.  As the endpoint is permitted to renew its
> > registration any time up
> > to the assigned time to live, allowing the GK to increase time to
> > live would
> > have no effect whatsoever (the endpoint would send
> keepalives at whatever
> > frequency it always wanted to).  There would be no effect, so
> > there's no reason
> > to change.
> >
> > As for your second point about SEQUENCE OF being permitted to
> > have an empty
> > list, this has always been the case.  Is there a specific problem
> > with this?
> > It looks more like a (true) observation than a problem to me!  I
> > doubt you'll
> > get ASN.1 changed in existing stuff to make things SEQUENCE
> > [1..something] OF
> > rather than SEQUENCE OF (even if such a structure is
> permitted - any ASN.1
> > experts wish to comment?).
> >
> > Chris
> > --
> > Dr Chris Purvis -- Development Manager
> > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
> > Phone: +44 1344 899 007
> > Fax:   +44 1344 899 001
> >
>