[manet] Re: Rtgdir early review of draft-ietf-manet-dlep-cha nnel-utilization-01

Abdussalam Baryun <[email protected]>
Newsgroups gmane.ietf.manet
Message-ID <CADnDZ8950kh8dsyqhuB3X7gxr=f52sPd7QPeLQVkamWD7EaRSQ@mail.gmail.com>
Hi Russ,

Thanks for your email, is this review only requesting the author to reply,
or we could reply with our part comments for WG.

Best Regards,
AB

On Sat, Apr 26, 2025 at 11:18 PM Russ White via Datatracker <
[email protected]> wrote:

> Document: draft-ietf-manet-dlep-channel-utilization
> Title: DLEP Radio Channel Utilization Extension
> Reviewer: Russ White
> Review result: Has Nits
>
> ==
> They are never reseted and will just increase monotonic.
>
> Maybe:
>
> These four data items monotonically increase for entire duration of the
> connection; they are never reset.
>
> ==
> The first Data Item (Radio Channel Active) announces ...
>
> I think (?) this would be better as a bulleted list or some such, rather
> than
> paragraph text.
>
> ==
> ... the channels livetime of the radio channel ..
>
> I think this means something like:
>
> ... the total time this channel has been used by the radio for any purpose
> (i.e., the total amount of time the radio has transmitted on this channel)
> ...
>
> ==
> A radio that doesn't track the time for receiving and transmitting data
> explicitly can just add all times the radio channel is not free into the
> Radio
> Channel Busy Data Item
>
> I think this might be clearer something like:
>
> If a radio does not track its send or receive times explicitly, it SHOULD
> still
> calculate and advertise the Radio Channel Busy Time data item.
>
> ==
> The router can calculate statistics on the channel usage ...
>
> Maybe:
>
> The router can calculate channel usage statistics ...
>
> ==
> Is there a potential need for these calculations to apply to either spread
> spectrum or beam forming systems? I suppose these calculations could be
> "per
> reachable neighbor" in that case, but the document doesn't say anything
> about
> these situations, so I thought I'd ask.
>
> ==
> Radio Channel Active Item contains information how long the radio channel
> has
> been active.
>
> The diagram is a little confusing (?) ... it seems to imply there could be
> multiple "active time" sections in the TLV. Maybe something like:
>
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Data Item Type                | Length                        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                          Active Time                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                          ...........                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ...and then explain the "active time" is one field?
>
> ==
> Same thing for the busy and rx data item, etc. fields.
>
> ==
> Active Time: Time in nanoseconds since the channel has been active.
>
> This could be read two different ways:
>
> - How long has it been since the last transmission on this channel
> - The total amount of time this channel has been in use
>
> >From the text, the latter is what's wanted, but the text above allows for
> either. Maybe:
>
> Active Time: Time in nanoseconds this channel has been in use.
>
> ==
> ... Time in nanoseconds the local radio was receiving data ...
>
> Maybe:
>
> ... Time in nanoseconds the local radio has received data ...
>
>
> _______________________________________________
> manet mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.