Re: [manet] Call for WG adoption of draft-rogge-manet-dlep-radio-band

A few comments since you asked so nicely.  This isn't my direct area of
expertise so take them with a grain of salt.

An optional "width" field would add to usefulness.  Although if included it
should specify some known threshold like 20 or 50% of max usage.  (not my
area so whatever is most useful to those who do know).  Optionally if we
all don't know then have a field which includes what that width indicates
in terms of max power.

The introduction is a bit light.  I would like it to contain a little bit
about what the problem/issue is that this draft attempts to address.  Some
of that information is contained in the "Radio Band Data Item" section.
The draft is short and to the point (as much as an RFC can be) but is
lacking a bit on details for my liking, specifically there are a few too
many "can" and "usually" without explanations of "how" and "if otherwise".

Just going to include the "Radio Band Data Item" section and comment inline
below.

Radio Band Data Item contains information which radio frequency
   resources are being used.  These values are usually interface
   specific and static during the DLEP session.

JWD: this deserves to be separated out and explained upon a little bit.

What happens if they are not static or not interface specific?

Can these cases be handled by this extension or not?

If yes then how? If not then it needs to be said. (and possibly
discussed in the WG)

   The Radio Band Data Item can be used multiple times to represent
   multiple radio bands.

JWD: Is there a limit?  (assuming no) What happens if the information
contained is "similar"

(off by one Hz for example) but not the same frequency.  Should that
be disallowed? If changes do occur does

an update suffice or does a new dlep session need to happen?

   The Item can be used in a neighbor specific message if the radio use
   dedicated subcarriers to talk to neighbors.

JWD: Assuming this is only regarding outgoing messages to the neighbor
in question and not any freq

that may be used in the reverse direction.

   The information in this Item gives the router an easy way to
   calculate the spectral efficiency of a radio link, how much bandwidth
   is used for the current data-rate reported by DLEP.  This can be
   integrated into the routing metric to focus traffic on links that use
   the spectrum efficiently.

JWD: Not my area of expertise, I'd find a simple example to be informative.

   The Item can also be used as an interface to a cognitive radio
   controller on the router, analyzing the correlation of transmission
   disruptions with the frequency bands and could (together with the
   Request Link Characteristics message) be used to change the frequency
   of the radio in a standardized way.

JWD: How would the change of frequency work with the assumption that
it's static over a dlep session?

If my assumption is wrong then clarity of static or not would be appropriate.

On Wed, Mar 16, 2022 at 4:28 AM Henning Rogge <hrogge@gmail.com> wrote:

> I would really like to hear about ANY opinion on the "frequency
> hopping" matter... Does an optional additional "frequency range" value
> resolve this for most people?
>
> If the group thinks "yes", I can create and upload an additional
> revision of my draft.
>
> Henning
>
> On Fri, Mar 11, 2022 at 10:12 AM Velt, R. (Ronald) in 't
> <Ronald.intVelt=40tno.nl@dmarc.ietf.org> wrote:
> >
> > MANET WG participants,
> >
> >
> >
> > This is the announcement of a WG adoption call for
> draft-rogge-manet-dlep-radio-band, starting today and running for two
> weeks, i.e. until the end of IETF-113. Please express your support for or
> objections to the adoption of this draft as a WG document by means of a
> post to the MANET WG mailing list. (Please do not remain silent). Comments
> and questions are of course very welcome.
> >
> >
> >
> > Thanks,
> >
> > Don & Ron(ald)
> >
> >
> >
> > This message may contain information that is not intended for you. If
> you are not the addressee or if this message was sent to you by mistake,
> you are requested to inform the sender and delete the message. TNO accepts
> no liability for the content of this e-mail, for the manner in which you
> use it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
> >
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>