Hi Charlie,
I've made the two changes you suggested.
Vicky.
On Thu, Aug 20, 2015 at 6:47 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Vicky,
Two minor revisions to your suggested text below:
On 8/20/2015 1:27 AM, Victoria Mercieca wrote:
"To reduce congestion in a network, repeated
Section 6.4 page 23 para 4 using [RFC 3561] in this way as a SHOULD makes
it a normative reference, which is a downref, and it’s buried somewhere in
that reference without an indication. Should be pulled out and included in
this document.
We will reword to avoid the apparent downref. Do you have a suggestion
for this?
It now says this:
attempts at route discovery for a particular target address SHOULD
utilize the binary exponential backoff used in [RFC3561]. If the
requested route is not learned within RREQ_WAIT_TIME of sending the
first RREQ, RREQ_Gen sends a new RREQ. The wait time for the RREP
corresponding to the second RREQ is 2 * RREQ_WAIT_TIME. If the
requested route is not learned within this time period, another RREQ
MAY be sent, up to a total of DISCOVERY_ATTEMPTS_MAX. For each
additional attempt, the waiting time for the RREP is multiplied by 2,
so that the time conforms to a binary exponential backoff."
Perhaps slightly better to move the citation to the end of the paragraph,
maintaining the same information:
"To reduce congestion in a network, repeated
attempts at route discovery for a particular target address SHOULD
utilize the binary exponential backoff as follows. If the
requested route is not learned within RREQ_WAIT_TIME of sending the
first RREQ, RREQ_Gen sends a new RREQ. The wait time for the RREP
corresponding to the second RREQ is 2 * RREQ_WAIT_TIME. If the
requested route is not learned within this time period, another RREQ
MAY be sent, up to a total of DISCOVERY_ATTEMPTS_MAX. For each
additional attempt, the waiting time for the RREP is multiplied by 2,
so that the time conforms to a binary exponential backoff. This is the
same backoff as used in [RFC3561]"
actually it says:
"remains Active until its expiration time, after which it MUST become
Invalid. "
This is true. Then, when it's invalid, it MAY be expunged...the memory
constraint bit is in a lower paragraph now, not to confuse things.
This is O.K.
Under Invalid:
"If Route.State is Invalid, the route MUST be maintained until
MAX_SEQNUM_LIFETIME after Route.LastSeqNumUpdate, after which it MUST be
expunged. Route.SeqNum is used to classify future information about
Route.Address as stale or fresh."
Keeping the separation, hopefully making it very clear.
This does not allow Invalid routes to be expunged. I think the first MUST
has to be changed to a SHOULD.
I am sending the email to the list with this second part omitted. We can
send it later if you agree with my suggestion to use SHOULD. I don't think
Chris will mind if we add more follow-up a little later.
Regards,
Charlie P.
