[aodvv2-discuss] Re: Trying to close issues that have been resolved...
- From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Tue, 24 Mar 2015 13:26:41 +0000
Hi Charlie,
Here's my attempt:
Simple changes
19 Use of square brackets
... every instance checked
20 Idle routes must be marked as active after re-use
... done
22 Multiple terms for same concept
... fixed
25 Meaning of "suppose"
... term no longer appears
27 Processing AckReq
... Description clarified
29 Choice of IP address
... Text clarified; natural IP address as used by application
30 Use of word "node"
... Expanded use of IP address instead
31 Suitability for implementation on commodity OS
... Text added as discussed - see issue 46 also - features of IP
needed by AODVv2 - Appendix G
39 Route.Broken flag redundant
... Fixed
40 AckReq vs RREP_ACK
... Clarified that RREP_Ack is the response to AckReq
41 AckReq vs RREP_ACK
... Duplication
42 What happens if Active routes exceed RERR packet size?
... Specified need for multiple RERR messages
49 Locating pseudocode in appendix (submitted for Chris Dearlove)
... pseudocode no longer deals with RFC 5444 fields
50 Weak gateway support (submitted for Chris Dearlove)
... full support is out of scope for this document
56 Issue concerning RREQ redundancy check methodology and order
... Revisions made for best efficiency
57 Need to further restrict "LoopFree" condition
... Done
58 Definitions of OrigNode and TargNode (Submitted for Justin Dean)
... Added
59 Use of the term "invalid" (Submitted for Justin Dean)
... Resolution related to issue #61
60 Should OrigNode be included in the message header? (... Justin Dean)
... fixed
61 Difference between "broken" and "expired" (Submitted for Justin Dean)
... States coalesced, renamed to be "invalid"
62 Inconsistency surrounding the "timed" state (Submitted for Justin
Dean)
... fixed
63 {Orig,Targ}.Tail should be {Orig,Targ}.Mid
... fixed
Bigger changes (i.e the "is it good enough now?" list)
21 Document hard to read
... many parts rewritten
23 Format of processing algorithms
... Made much more regular, added sections
24 Ordering of processing instructions
... Collected together
26 Specification of optional features (specifically text on
bidirectionality)
... Collected together, RREP_Ack mandated
28 Routers with multiple interfaces [* issue refers to multi-homing text]
... Text modified to make clear it is supported [* "multi-homing is
not supported" - Appendix H]
32 Multicast transmission
... Clarified role od RFC6621
33 RFC 5444 processing constraint
... Written to show Data Elements --> RFC 5444 blocks, etc.
35 A constant is constant
... Text on result of variations added as requested
36 Security Considerations: Reactive protocol concept
... Text added to applicability statement
37 Security Considerations: what needs to be implemented?
... Similar approach as DLEP
38 difficulty to do security, in case messages are mutable
... Similar approach as DLEP
43 Reliance on bidirectional paths (submitted for Chris Dearlove)
... Clarified
44 Hop count (submitted for Chris Dearlove)
... Other metrics out of scope for base specification
45 RFC 5498 non-compliance (submitted for Chris Dearlove)
... Is now compliant
46 What is needed from IP and ICMP (submitted for Chris Dearlove)
... Text added, related to issue #31
47 Security approach unacceptable (submitted for Chris Dearlove)
... Similar approach as DLEP
48 Single address per interface per router (submitted for Chris Dearlove)
... Clarified that restriction does not apply
Regards,
Vicky.
On Tue, Mar 24, 2015 at 12:45 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
> Hello Victoria,
>
> I would appreciate it if you would make a proposal for the two lists. I
> have been
> staring at these for too long, and am not sure where to make the dividing
> line.
>
> Regards,
> Charlie P.
>
>
>
> On 3/24/2015 1:15 AM, Victoria Mercieca wrote:
>
> Hi Charlie,
>
> Is it worth separating these into a list of the small things that were
> simple changes, and a list of the bigger things we would like a bit of
> feedback on to ensure everyone agrees the issue has been resolved? Up to
> you!
>
> Regards,
> Vicky.
>
>
>
> On Tue, Mar 24, 2015 at 5:40 AM, Charlie Perkins <
> charles.perkins@xxxxxxxxxxxxx> wrote:
>
>> Hello folks,
>>
>> Most of the issues have been resolved. Some are suggested to be resolved
>> "like DLEP".
>> Other than that, only issue #34 needs more explanation, and I have
>> something written
>> up for that. For some of these issues, the additional text has been put
>> in the issue
>> tracker.
>>
>> Here's what I would like to put on the mailing list. Please help and let
>> me know if
>> you have suggestions for improvement/persuasion/other comments. It would
>> be
>> nice to put it out before tomorrow's meeting...
>>
>> Issues that could be closed, and resolutions:
>>
>> 19 Use of square brackets
>> ... every instance checked
>> 20 Idle routes must be marked as active after re-use
>> ... done
>> 21 Document hard to read
>> ... many parts rewritten
>> 22 Multiple terms for same concept
>> ... fixed
>> 23 Format of processing algorithms
>> ... Made much more regular, added sections
>> 24 Ordering of processing instructions
>> ... Collected together
>> 25 Meaning of "suppose"
>> ... term no longer appears
>> 26 Specification of optional features
>> ... Collected together, RREP_Ack mandated
>> 27 Processing AckReq
>> ... Description clarified
>> 28 Routers with multiple interfaces
>> ... Text modified to make clear it is supported
>> 29 Choice of IP address
>> ... Text clarified; natural IP address as used by application
>> 30 Use of word "node"
>> ... Expanded use of IP address instead
>> 31 Suitability for implementation on commodity OS
>> ... Text added as discussed
>> 32 Multicast transmission
>> ... Clarified role od RFC6621
>> 33 RFC 5444 processing constraint
>> ... Written to show Data Elements --> RFC 5444 blocks, etc.
>> 35 A constant is constant
>> ... Text on result of variations added as requested
>> 36 Security Considerations: Reactive protocol concept
>> ... Text added to applicability statement
>> 37 Security Considerations: what needs to be implemented?
>> ... Similar approach as DLEP
>> 38 difficulty to do security, in case messages are mutable
>> ... Similar approach as DLEP
>> 39 Route.Broken flag redundant
>> ... Fixed
>> 40 AckReq vs RREP_ACK
>> ... Clarified that RREP_Ack is the response to AckReq
>> 41 AckReq vs RREP_ACK
>> ... Duplication
>> 42 What happens if Active routes exceed RERR packet size?
>> ... Specified need for multiple RERR messages
>> 43 Reliance on bidirectional paths (submitted for Chris Dearlove)
>> ... Clarified
>> 44 Hop count (submitted for Chris Dearlove)
>> ... Other metrics out of scope for base specification
>> 45 RFC 5498 non-compliance (submitted for Chris Dearlove)
>> ... Is now compliant
>> 46 What is needed from IP and ICMP (submitted for Chris Dearlove)
>> ... Text added, related to issue #31
>> 47 Security approach unacceptable (submitted for Chris Dearlove)
>> ... Similar approach as DLEP
>> 48 Single address per interface per router (submitted for Chris
>> Dearlove)
>> ... Clarified that restriction does not apply
>> 49 Locating pseudocode in appendix (submitted for Chris Dearlove)
>> ... pseudocode no longer deals with RFC 5444 fields
>> 50 Weak gateway support (submitted for Chris Dearlove)
>> ... full support is out of scope for this document
>> 56 Issue concerning RREQ redundancy check methodology and order
>> ... Revisions made for best efficiency
>> 57 Need to further restrict "LoopFree" condition
>> ... Done
>> 58 Definitions of OrigNode and TargNode (Submitted for Justin Dean)
>> ... Added
>> 59 Use of the term "invalid" (Submitted for Justin Dean)
>> ... Resolution related to issue #61
>> 60 Should OrigNode be included in the message header? (... Justin Dean)
>> ... fixed
>> 61 Difference between "broken" and "expired" (Submitted for Justin
>> Dean)
>> ... States coalesced, renamed to be "invalid"
>> 62 Inconsistency surrounding the "timed" state (Submitted for Justin
>> Dean)
>> ... fixed
>> 63 {Orig,Targ}.Tail should be {Orig,Targ}.Mid
>> ... fixed
>>
>>
>>
>
>
Other related posts:
