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

[satish anamalamudi <[e-mail]>]

Hello Charlie,

Yes, the AODV-RPL draft is mainly proposed to support asymmetric link in
constrained LLN network. Implementation of asymmetric links is crucial in
constrained network resources.

Regards,
Satish

On Wed, Mar 31, 2021 at 10:03 AM Charlie Perkins <
[e-mail]> wrote:

> 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]> 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., *
>
>
> --











*With Regards,*

*Dr. Satish Anamalamudi, PhD.,*