[Roll] Typo!! <was, Re: Comments for AODV-RPL protocol [Issue #184]>

[Charlie Perkins <[e-mail]>]

Hello folks,

Sorry about that...  below, where I had "Figure 15", I meant to say 
"Figure 14".

Regards,
Charlie P.


On 2/26/2018 2:04 PM, Charlie Perkins wrote:
>
> Hello Abdussalam,
>
> Thanks for your comments and suggestions.  Please find some follow-up 
> comments below.
>
>
> On 1/5/2018 12:04 PM, Abdussalam Baryun wrote:
>> Hi WG,
>>
>> The abstract needs to delete any indication that this is a routing 
>> protocol. IMHO, this is a route discovery for the RPL protocol.
>>
>
> To me AODV-RPL is a variation on RPL.  But I am curious to know more 
> about the distinction between a routing protocol and a route discovery 
> mechanism that uses routing protocol control messages.
>
>
>> The discovery of route is part of the routing protocol so we have a 
>> different routing which is AODV-RPL routing protocol. The draft needs 
>> to mention if this AODV-RPL can work with RPL or not in the same network.
>>
>
> Yes, AODV-RPL should interoperate quite well with RPL in the same 
> network.  If there is some case that presents difficulty please let us 
> know and we will analyze it further.
>
>> IMO, the draft needs to describe the neighbor discovery combined with 
>> AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 
>> 18.6 in rfc6550. Or the draft shows the difference from RFC6650 
>> discovery. Please refer to sections in RFC6550 RPL.
>>
>
> I don't really know what to make of this, until after I can better 
> understand the difference between a routing protocol and a route 
> discovery mechanism that uses routing protocol control messages.
>
>> AODV-RPL instance are another type of RPL-Instances, so why you write 
>> the AODV instance.
>>
>
>
>
>> Please note that this will conflict with MANET routing instances. 
>> Please delete AODV instance. This draft needs to have only RPL 
>> instances or this AODV-RPL instance defined as RPL instance.
>>
>
> I looked for the strings "AODV instance" and "AODV-RPL instance" but 
> did not find.  Could you point to the particular occurrence so that I 
> can understand the conflict?
>
>
>> Delete the writing words 'AODV routing' from the draft, and delete 
>> AODV reference as the IPv4-RFC mentioned (can be confusing). The AODV 
>> is already well known.
>>
>
> Thanks for acknowledging the work on AODV.  I am hoping AODVv2 
> completes Last Call soon.  However, I searched for "AODV routing" but 
> did not find.  Could you point to the particular occurrence so that I 
> can understand the confusion?
>
>
>> IMO the operation mode is not used correctly, we need to identify the 
>> protocol not by the MoP, we will use them all then, it should be 
>> reserved for network operations not for protocols.
>>
>
> I am O.K. with recasting the new messages so that they do not use 
> another MoP.  That is a very easy change to make.  I will await to see 
> if others agree.
>
>> IMHO, the Message format of dio is not correct needs to have type 
>> then the length format as shown in the dio format specification rfc6550.
>
> Looking at Figure 14 in RFC 6550, I do not see a length field. The DIO 
> shown in Figure 1 of the AODV-RPL draft strongly resembles Figure 15 
> of RFC 6550.   Did you have something else in mind about this?
>
>
>>
>> IMO, this protocol Sequence number is not different than the sequence 
>> number of destination mentioned in RFC6550. You must include the DTSN 
>> in this draft. If you thinks I am wrong please mention why here and 
>> then it should be clear what is the different than RPL in the draft?
>>
>
> I will get back to you on this point.
>
>
>> Security section needs to include rfc6552/rfc6553
>>
>
> RFC 6552 is about the Objective Function Zero, which isn't directly 
> related to security.  RFC 6553 is about putting RPL control 
> information in Data-Plane packets, which we do not use for AODV-RPL.  
> However that is an interesting idea worth discussion, albeit not 
> necessarily in the security section.  I would be very curious to find 
> out if RFC 6553 has attracted much implementation.
>
>
>> I suggest to delete future work section.
>>
>
> It's not normative, and fairly reflects some useful discussion that we 
> have had.  Do you think it is confusing for the rest of the document?
>
> Regards,
> Charlie P.
>