RE: AD review of draft-ietf-ccamp-lmp-07.txt

["Jonathan Lang" <Jonathan.Lang@RinconNetworks.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Bert,
  Thanks for the review of this and the other 2 LMP-related documents.
We will do a quick rev to address your comments so that you can request
an IETF Last Call.

Thanks,
Jonathan

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf
> Of Wijnen, Bert (Bert)
> Sent: Thursday, March 13, 2003 1:16 PM
> To: Ccamp-wg (E-mail)
> Subject: AD review of draft-ietf-ccamp-lmp-07.txt
> 
> Since I do not intend to request IETF Last Call before the
> IETF meeting in SF is over, maybe the authors can do a quick
> rev to try and address the following points.
> 
> Here are my review comments
> 
> - More or less serious:
> - scenario at end of sect 3.2.2
>   WOuld it not be wise to include the "waiting for interval
>   to expire" before a resend is done? Otherwise, if people
>   forget, I can see congestion being created.
> - IANA considerations
>   - I wonder if you want "IETF Consensus" based assignments.
>     There was quite some debate as to what that means recently.
>     Maybe you mean or want "standards action" instead?
>   - I also wonder... values 0-127 are allocated by expert review,
>     while the values in this doc (and a few other lmp related
>     docs on my plate) are in that space and are on stds track,
>     so they would be "standards action" based.
>   - So pls make sure that you have documented what you want/intend
> - sect 12.1 as example (this occurs several times). It says:
>    Msg Type: 8 bits.  The following values are defined.  All other
>              values are reserved and should be sent as zero and
ignored
>              on receipt.
>   But the values seem to be integer values and not bits. So I do not
>   understand the "All other values are reserved and should be sent as
> zero.."
>   especially the "should be sent as zero" seems strange in this case.
> 
> Nits:
> - sect 1. Expand acronyms when used for first time
>   examples are DWDM, TDm, WDM. There may be others
> - When I read (2nd para pge 9)
>     LMP adjacency.  The value of the Message_Id is monotonically
>     increasing and only decreases when the value wraps.
>   Then I think I would change
>     and only decreases when the value wraps.
>   into
>     and wraps when teh max value is reached
> - 2nd para sect 3.1
>   I guess that Node-Id of two nodes can never be equal.
>   But if such happens (by error) who is then the winning node,
>   or what should the behaviour be?
> - sect 3.2.1 2nd and 3rd para
>   Is for example a 1 millisecond interval valid?
>   WOuld it possibly cause congestion (rfc2914) ??
> - sect 3.2.2 (3rd para) explains when difference can be more
>   than 1. I think that in the case of UDP packet loss, the
>   diff can slo be more then 1, no?
> - at a few places I see msoft (non-ASCII) characters
>   p48, p57, maybe other places too.
> - I see at various places 16-bit flags (or other) fields and then
>   values are shown as:
>     0x01
>     0x02
>   This may not be 100% clear as to which bits are then used.
>   Do you mean
>     0x0001
>     0x0002
>   An example is page 53
> - Last sentence of sect 18 ?? DId that sonet test stuff not go to
>   a separate document ??
> 
> Thanks,
> Bert