RE: FCIP: v0.7 editorial suggestion

[Sudhir Srinivasan <SudhirS@trebia.com>]

Ralph,

If the bit positions are going to be changed, I still 
think it would be better to simply swap the positions 
of the Ch and SF bits in the pFlags bit. This has both 
benefits -- it allows for the "growth" of the SF bit 
as you outline below AND it makes the table consistent 
with the bit field definition and hence makes it easier 
to read/verify Figure 9. 

Regards,
Sudhir

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Trebia Networks, Inc.    Sudhir.Srinivasan@trebia.com
978-929-0830 x139        www.trebia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> Sent: Wednesday, November 28, 2001 6:24 PM
> To: Sudhir Srinivasan
> Cc: Murali Rajagopal
> Subject: Re: FCIP: v0.7 editorial suggestion
> 
> 
> Sudhir,
> 
> The FCIP authors have agreed to move the Ch bit from
> bit 25 to bit 31. This change has the additional
> advantage that the SF bit can grow to the 'frame type'
> field if a compelling need arises.
> 
> The new figure will look like this.
> 
>        |----------------Bit--------------------|
>        |                                       |
>        | 31   30   29   28   27   26   25   24 |
>        +----+-----------------------------+----+
>        | Ch |          Reserved           | SF |
>        +----+-----------------------------+----+
> 
>        Fig. 8  pFlags Field Bits
> 
> I don't know if this will fully lay to rest the
> confusion you experienced, but it should help.
> 
> Thanks.
> 
> Ralph...
> 
> Sudhir Srinivasan wrote:
> 
> >
> > Ralph,
> >
> > Deleting the table is not advisable, IMO. The table
> > is a handy quick reference and is very useful, much
> > preferable to searching through a bunch of text. It's
> > precisely for this reason that it is somewhat important
> > that the table matches the actual bit pattern. Most (all?)
> > standards that I've read do it that way.
> >
> > It's a suggestion only to improve the readability of
> > the standard. No big deal if you want to leave it the
> > way it is.
> >
> > -S
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Trebia Networks, Inc.    Sudhir.Srinivasan@trebia.com
> > 978-929-0830 x139        www.trebia.com
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > > -----Original Message-----
> > > From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> > > Sent: Sunday, November 25, 2001 4:21 PM
> > > To: Sudhir Srinivasan
> > > Cc: Murali Rajagopal
> > > Subject: Re: FCIP: v0.7 editorial suggestion
> > >
> > >
> > > Sudhir,
> > >
> > > Since the entire contents of table 1 duplicates
> > > specifications written out somewhere in the text,
> > > I would be happy to delete the table.
> > >
> > > Ralph...
> > >
> > > Sudhir Srinivasan wrote:
> > >
> > > >
> > > > OK, let me spell it out:
> > > >
> > > > In figure 9 (that's nine, not eight), the pFlags
> > > > value is correctly shown as 0x01. The normal tendency
> > > > is to look up the two LSB combination (0 and 1) in
> > > > Table 1, which is the 2nd row, which is the
> > > > "Always Illegal" combination! So the intelligent
> > > > reader (one capable of understanding NAPTs) figures
> > > > something's wrong and has to go through the exercise
> > > > of matching bit-for-bit and soon determines that
> > > > 0 and 1 in the example means 1 and 0 in the table.
> > > >
> > > > So, for the sake of readability and cleanliness,
> > > > I recommend either swapping the table columns or
> > > > swapping the bit positions in the pFlags field.
> > > > Since by your own admission the bit positions in
> > > > the pFlags field is fairly arbitrary, the latter
> > > > option should be palatable?
> > > >
> > > > Regards,
> > > > -Sudhir
> > > >
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > Trebia Networks, Inc.    Sudhir.Srinivasan@trebia.com
> > > > 978-929-0830 x139        www.trebia.com
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >
> > > > > -----Original Message-----
> > > > > From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> > > > > Sent: Sunday, November 25, 2001 7:42 AM
> > > > > To: IPS Reflector
> > > > > Cc: Sudhir Srinivasan
> > > > > Subject: Re: FCIP: v0.7 editorial suggestion
> > > > >
> > > > >
> > > > > I believe that the logic and conceptual structure of
> > > > > Table 1 will be less clear if the columns are swapped.
> > > > > For better or for worse, the positions of the bits in
> > > > > Figure 8 represents the order in which they were
> > > > > defined not the logic and purpose of the bits.
> > > > > So the figure and the table are disjoint, as would
> > > > > be the case for any design that evolved over time.
> > > > >
> > > > > Finally, I find it impossible to believe that anyone
> > > > > capable of understanding NAPTs could become confused
> > > > > by Figure 8 and Table 1.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Ralph...
> > > > >
> > > > > Sudhir Srinivasan wrote:
> > > > >
> > > > > > Ralph,
> > > > > >
> > > > > > An editorial suggestion:
> > > > > >
> > > > > > The pFlags definition is:
> > > > > >        |----------------Bit--------------------|
> > > > > >        |                                       |
> > > > > >        | 31   30   29   28   27   26   25   24 |
> > > > > >        +-----------------------------+----+----+
> > > > > >        |             Reserved        | Ch | SF |
> > > > > >        +-----------------------------+----+----+
> > > > > >         Fig. 8  pFlags Field Bits
> > > > > >
> > > > > > with the "Ch" bit to the left of the "SF" bit.
> > > > > >
> > > > > > I suggest the first two columns in Table 1 be swapped
> > > > > > to reflect this. When looking at Figure 9, it was
> > > > > > slightly confusing at first to map the pFlags value
> > > > > > shown in the Short Frame header back to Table 1.
> > > > > >
> > > > > > Regards,
> > > > > > Sudhir
> > > > >
> > >
> 
>