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 <mailto: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 ifyou have suggestions for improvement/persuasion/other comments. It would benice 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