Subject: RE: [SUA issues 3,6,7] text

From: [email-masked]
Date: Tue, 4 Sep 2001 08:46:22 +0300

Brian,

> In some of these parameters you refer to excess bits as "unused" and
> in others you refer to them as "spare".  Is there any difference
> between "spare" and "unused"?

You got me on that.  I will normalize this, making sure that SUA
is consistant with other UAs.
 
> There is no description on any restrictions of how "spare", "unused"
> and excess field bits are to be coded.  For example, can they be coded
> to random values?

I shall make sure this is cleanly covered.
 
> Please see comments below...

> > Bit 8 indicates the use of the return on error procedure.
> > 
> > 		Value	Description 
> >       	 0x0		No special options
> >       	 0x1		Return message on error
> > 
> > 		Bits 3-7 are spare and should be coded zero.
> > 
> > Mandatory in CR, CC, IT, UDT, XUDT, LUDT
> 
> Should read:
> 
>   Mandatory in CORE, COAK, COIT, CLDT

Got it.
 
> > Optional in CODT
> 
> Why is this optional in CODT?  Connections cannot change protocol
> classes mid connection...  Also, it has been clearly laid out that
> protocol class can be derived from the presence or absence of the
> sequence parameter in CODT messages.
> 
> Strike the Optional.

Does that mean you want it MANDATORY or remove support for it in CODT?
 
> ==============================================================
> ==========
> > 
> > 3.10.e Sequence Control
> > 
> >    0                   1                   2                   3
> >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |         Tag = 0x010e         |             Length = 8         |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |                                               | Seq  
> Control  |  
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Sequence Control (1.1.2/Q.714)
> > 
> > The field is coded with the value of the sequence control parameter
> > associated with a group of messages and are chosen so as to 
> > ensure  proper loadsharing of message groups over SLS values while 
> > ensuring that sequence control values within message groups have the 
> > sequence control value coded with the same value as the initial message 
> > of the message group.
> > 
> > 
> > Mandatory in CLDT, CORE, COAK, COIT.
> 
> For decoupled operation, sequence control needs to be
> 
>   Optional in all other CL and CO messages.

So, it should be optional in CLDA, COREF, RELRE, RELCO, RESCO, RESRE,
COAT, CODA, COERR?  That seems a bit much ...

Should a be added stating that 'This parameter is needed for decoupled 
operation.'

It would be helpful if you would provide a good definition for 'Decoupled
Operation.'

> To support non-final GTT, sequence control must be provided in a all
> CL and CO messages which do not terminate at the peer.

John

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]