Subject: v12 7.1.10 SignalsDescriptors reviewed

From: Nancy-M Greene <[email-masked]>
Date: Mon, 1 Nov 1999 16:25:44 -0600

Brian, John,
We've had a chance now to review the new signalsDescriptor text in v12, and
have a few questions/comments....

- add sentence after first sentence in second paragraph- "signalID is the
itemID part of pkgdName in a signalsDescriptor."

- what happened to the signal type CN, for continue? see section 12.1.4

- what is duration for OO signals? in 12.1.4 it implies that OO signals can
have a duration. If they can, what is the difference between TO and OO
signals?

signalList questions:
- what does duration mean in signalList? the max duration of the entire
signalList?

- How is duration set in the signalList when there are signals of type TO?

- how does the signalList duration interact with the signal duration? does
it override it? For example, if the signalList duration expires in the
middle of the list, what happens?

- is the sigType & duration correct in the table below?

sigList            SigType Duration
BR, BR, BR, ... OO  OO     duration invalid here?
BR,TO,BR,TO,... OO  OO     duration invalid ?
TO, TO, TO  ... TO  TO     max duration for signalList
BR, BR, BR, ... BR  BR     max duration for signalList
BR,BR,TO,BR,... TO  TO/BR? max duration for signalList
TO,BR,TO,BR,... BR  BR/TO? max duration for signalList

- what difference does it make whether the signalList sigType is TO or BR?
How do you decide to set it to one or the other?

- why is signal identifier only one digit? It should be of type UINT16.

- how do you recycle signal identifiers? Does a used signal identifier
remain unused for a specific amount of time?

- how do you clear a signal identifier?

- second last bullet - remove stream identifier - it is not one of the
signalList parameters

- second last bullet - add duration to the list of things to be ignored? or
is duration the one thing you can change when you send a replacement
descriptor with the same signal identifier?

- second last bullet - if all parameters to signalList are to be ignored,
then why not say that in a replacement descriptor, if a signalList uses the
same signal identifier as the replaced one, then any parameter that follows
should not be there (since it shall be ignored anyway).

Abdallah Rayhan & Nancy Greene

--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

---

From: John Segers <[email-masked]>
Date: Thu, 4 Nov 1999 10:28:35 +0100

Nancy, Abdallah,

Thank you for your detailed comments on the signals descriptors.  Some
responses below.

John

> Nancy-M Greene wrote:
>
> Brian, John,
> We've had a chance now to review the new signalsDescriptor text in
> v12, and have a few questions/comments....
>
> - add sentence after first sentence in second paragraph- "signalID is
> the itemID part of pkgdName in a signalsDescriptor."

Seems reasonable, but not urgent.

> - what happened to the signal type CN, for continue? see section

Hmm.  Lack of communication between authors of packages on the one hand
and Brian and myself on the other, it seems.  CN has to be removed.

> - what is duration for OO signals? in 12.1.4 it implies that OO
> signals can have a duration. If they can, what is the difference
> between TO and OO signals?

Good question.  We can do two things: add text to say that an on/off
signal may not contain the optional duration parameter, or add text to
say that if duration is specified with an on/off signal it has to be
ignored.  I have a preference for the latter.

> signalList questions:
> - what does duration mean in signalList? the max duration of the
> entire signalList?

Yes, but as the following questions show, this is not a very useful
idea.  The duration of a signal list is implied by the durations of the
signals it contains, whether these are specified explicitly or not.  I
propose that we leave it at that, and remove the override option.

> - how does the signalList duration interact with the signal duration?
> does it override it? For example, if the signalList duration expires
> in the middle of the list, what happens?
>

In view of this table I propose that we add a sentence to say that only
a signal list containing BR signals and no other signal types can have
type BR.

>
> - what difference does it make whether the signalList sigType is TO or
> BR? How do you decide to set it to one or the other?

This question is not restricted to signalLists.  The same can be asked
about signals of type TO and BR.  I don't know the answer, so I didn't
make a change to what was in the document already for signals, and
treated signalLists the same.  This is a topic for discussion in
Washington, I would say.

> - why is signal identifier only one digit? It should be of type

Sure.  I planned to make this change but forgot.

> - how do you clear a signal identifier?

I don't think we have to specify this.  The signalList identifier is
used to indicate that a signalList has to remain active when a new
signalsDescriptor is sent.  Once the signalList has finished, the
identifier can be reused.  The scope of the identifiers is restricted to
the termination on which the signalList is active, so there isn't any
need to specify rules for recycling them.

> - second last bullet - remove stream identifier - it is not one of the

Noted.

> - second last bullet - add duration to the list of things to be
> ignored? or is duration the one thing you can change when you send a
> replacement descriptor with the same signal identifier?

If we agree that signalLists do not have a duration, no change is
required here.

> - second last bullet - if all parameters to signalList are to be
> ignored, then why not say that in a replacement descriptor, if a
> signalList uses the same signal identifier as the replaced one, then
> any parameter that follows should not be there (since it shall be
> ignored anyway).

Not including the parameters to be ignored reduces the message size as
well.  But if you want to put them in the message, for instance because
the new signalsdescriptor is created by adding one signal to the old
one, I would say that should be allowed.

--
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