Subject: Re: [issue77] Comments from Furquan

From: Weiming Wang <[email-masked]>
Date: Sun, 5 Feb 2006 21:54:52 +0800

Avri and all,

To summarize the issue solution,

For comment #1,  although theres no text change related, some explanation has
been given for the question.

For comment #2, the 'byte'  mentioned has been changed to 'octet' by Avri in 06
draft.

For comment #3,  because we now have a quite large reserved ID space and we
currently don't see the very clear use of reserved 00 ID usage, it may be not
very important to do this currently.  Whereas for clearity, I do suppose to
change the list on the ID in Page 27 to a table.

For comment #4 and #5 things have been fixed by Avri already.

I suppose this issue can be closed.

Thanks to Furquan very much.

Weiming

Subject: [issue77] Comments from Furquan

Hi All,
    Just thought of adding some comments on the draft - before the last
call is done....

1) 3.3.4.1 Batching.... It's unclear from the text about how batching
should be achieved. Is there
any indication from the PL layer to the TML layer that there will be
more PDUs to come and
the TML should wait so that it can batch things up? Otherwise, TML would
simply ship out
the PDU as soon as it is received. Batching would introduce a bufferring
requirement in the
TML and if so, there may need to be an explicit indication from the PL
layer that a set of PL
PDUs are to be batched.

2) There are about 6 references to the word "byte" - As has been done
with a lot of other
RFCs, I think it would be completely unambigous only if we mean "octet"
rather than "byte".
(Byte is computer vendor dependent definition - though 8bits in 99%
cases - still
octet is unambigous). I would like to see the refences to byte be
replaced with octets.

3) ID assignment: For all the ID range assignments, I think it would
make sense to
start from +1 rather than 0 of that range. By this I mean, we really
don't want
0x00000000 to actually mean that it is an FEID. This could actually be
the unassigned
value for that device which has to be configured with some value. We
should start
from 0x00000001 - 0x3FFFFFFF for the FEID range
similarly, if the TS switch is actually only meant to do type selection,
it would be the
same case with CEID and multicast ID - i.e. by first just looking at the
TS bits, I
have figured that it is FE,CE or multicast, and the remaining bits would
start the
range from x0000000

4) Sec 5.2 and 5.3 - TLV and ILV "L" length part does not explicitly
specify
what is the size of each unit (is it octets, words, Dwords like in main
header etc.)
(obviously, I would imagine it would be in octets - but let's clarify it)

5) Could we replace "combo" with "combination" throughtout the text?
It's more
formal that way.

6) ....

Sorry, I have to run and haven't had the chance to go though the rest of
the
document. I will try to do so.

Thanks,

--
Furquan Ansari
Bell Labs Research Ph : 732-949-5249
Holmdel, NJ Fax: 732-949-4556

----------
category: Editorial
draft: draft-ietf-forces-protocol
messages: 384
nosy: weiming
priority: May fix
status: Pending
title: Comments from Furquan

___________________________________________________
Forces issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/forces/issue77>
___________________________________________________