Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-roll-aodv-rpl-09

[Charlie Perkins <[e-mail]>]

Hello Satish,

How about "Supporting Asymmetric Links in Low Power Networks: AODV-RPL"?

It still fits on one line, and seems to resolve your request as well as 
Tero's request.

Naturally Yours,
Charlie P.


On 3/30/2021 5:33 PM, satish anamalamudi wrote:
> Dear all,
>
> In my opinion, it is good to include AODV-RPL acronym within the title 
> of the draft.
>
> Regards,
> Satish
>
> On Tue, Mar 30, 2021 at 12:03 AM S.V.R.Anand <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hello,
>
>     I prefer to retain AODV-RPL in the title. AODV-RPL acronym has already
>     been referred by research community in their publications, and roll
>     community uses this acronym to refer to this draft. Also, I feel AODV
>     and RPL acronyms are familiar to the wireless and low power and lossy
>     networks world.
>
>     How about "AODV-RPL Extensions for Asymmetric Links in Low Power
>     Networks", or "AODV-RPL Support for Asymmetric Links in LLNs" ?
>
>     Regards
>     Anand
>
>
>     On 21-03-28 10:39:53, Charlie Perkins wrote:
>     >
>     >
>     > Hello Tero,
>     >
>     > Thanks for your comments, useful as always.  Please see a bit of
>     > follow-up below.
>     >
>     >
>     > On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote:
>     > >The title of the draft has some acronyms which are not expanded
>     (AODV, P2P) and
>     > >if you expand them the title comes way too long. I would
>     propose a usable
>     > >title, which might not need to use all possible acronyms, but
>     would better
>     > >explain what this document is trying to do.
>     >
>     > How about "Supporting Asymmetric Links in Low Power Networks"?
>     Replacing
>     > "LLNs" by "Low Power Networks" is probably O.K. because lossy is
>     almost
>     > implicit given low power (or, often, reality).
>     >
>     >
>     > >
>     > >Nits:
>     > >
>     > >In section 1 the text "RPL [RFC6550] (Routing Protocol for
>     Low-Power and Lossy
>     > >Networks)" defines acronyms differently than what is used
>     everywhere else. In
>     > >all other cases the document uses format where the acronym is
>     in parenthesis
>     > >after the full text, i.e. "Routing Protocol for Low-Power and
>     Lossy Networks
>     > >(RPL) [RFC6550]" format. I would propose using the same format
>     also for here.
>     > Done.
>     >
>     > >
>     > >In section 1 there is acronym DAG which is not expanded, expand
>     it on first
>     > >use.
>     > I think that sentence reads better just omitting DAG.
>     >
>     >
>     > >  Also there are unexpanded acronyms DAO, P2MP, which are not
>     used anywhere
>     > >else, perhaps just expand them here. In same paragraph there is
>     also acronym
>     > >MOP which is not expanded here on its first use, but it is
>     expanded later.
>     > >Expand it here on its first use.
>     >
>     > Done, except that I thought it would be better to exhibit the
>     acronym
>     > DAO since it is well known to readers familiar with RPL.
>     >
>     >
>     > >
>     > >What is the difference between different reserve bits X and r
>     in sections
>     > >4.1/4.2 and 4.3?
>     > I made them all to be reserved bits 'X'.
>     >
>     > >
>     > >Period missing from the end of sentence of the Option Length
>     description in
>     > >Section 4.3.
>     > Done.
>     >
>     > >
>     > >In the IANA considerations section I propose add a note to RFC
>     editor saying
>     > >that the sentences saying " The parenthesized numbers are only
>     suggestions."
>     > >needs to be removed prior publication.
>     > >
>     > >
>     >
>     > Done!
>     >
>     > Naturally Yours,
>     > Charlie P.
>     >
>
> -- 
>
>
>
>
>
>
> *
> *
> *
> *
> *
> *
> *
> *
> *
> *
> *With Regards,*
> *Dr. Satish Anamalamudi, PhD.,
> *
> *
> *