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 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
