Hello Vicky,
Follow up below...
On 2/28/2015 8:04 AM, Victoria Mercieca wrote:
Thanks for all the hard work you put in last night!
Thanks -- and likewise for these comments!
6.4 - I noticed a space has gone missing in "DSDV[Perkins94]" -
was that intentional?
6.5 - we should change "OrigNode Sequence Number" to OrigSeqNum,
and "TargNode Sequence Number" to TargSeqNum... because later
when we talk about checking for redundancy (8.6) we look at
seqnum for orig*addr*/targ*addr* rather than seqnum for the node.
9.1.1 - 2nd paragraph - TargSeqNum, ValidityTime, MetricType and
PrefixLengthList should be optional, using same structure as in
9.2.1
9.1.1 - step 4 - "Address List" to "AddressList"
9.1.1 - step 6 - should probably say:
"For the sequence numbers:
* Increment the SeqNum as specified in Section 6.4.
* Set OrigSeqNum to the new value of SeqNum.
* If an Invalid route exists matching TargAddr using
longest prefix matching, include TargSeqNum and set it to the
sequence number on the Invalid route. Otherwise omit TargSeqNum."
9.1.3 - step 4 - change VALIDITY_TIME to ValidityTime
9.2 - in the diagram, the PrefixLengthList line is missing the "}"
9.2.1 - change TargSeqNumber List to TargSeqNum
9.2.1 - step 5 - "Address List" to "AddressList"
9.2.1 - step 7 should say:
"For the TargSeqNum:
* RREP_Gen increments its SeqNum as specified in Section
6.4.
* Set TargSeqNum to the new value of SeqNum."
9.2.3 - step 6 - change VALIDITY_TIME to ValidityTime
9.3.1 - paragraph 4 - change "Address List" to "AddressList" and
"Metric List" to "MetricList"
9.3.1 - step 6 - "SeqNum List" to "SeqNumList" (twice)
All fixed.
Section 10 - where it says "see section 14.2" and "see section
14.3" - is it more correct to remove AODVv2 in these sentences?
the message TLVs and address block TLVs are owned by rfc5444.
Here I am not sure. The TLVs are owned by RFC 5444 but specified
by AODVv2.
Section 10 - the paragraph before the table needs the first
sentence rewording, maybe to "The following table shows how
AODVv2 data elements are represented in RFC 5444 messages."
Done.
Questions:
I wondered if the references to TLVs should be removed from
everywhere except section 10 and appendices. If so,
6.2 - "AckReq Message TLV" should be "AckReq data element"
(occurs twice in 6.2)
7 - "MetricType TLV" to "MetricType data element"
9.1.1 - step 3 - "MetricType TLV" to "MetricType data element"
9.1.1 - step 8 - "ValidityTime Address Block TLV" to
"ValidityTime data element"
9.1.2 - step 4 - "MetricType TLV" to "MetricType data element"
9.2.1 - step 3 - "AckReq TLV" to "AckReq data element"
9.2.1 - step 4 - "MetricType TLV" to "MetricType data element"
9.2.2 - step 3 - "MetricType TLV" to "MetricType data element"
9.2.2 - step 6 - "AckReq TLV" to "AckReq data element"
9.2.3 - step 5 - "AckReq TLV" to "AckReq data element"
9.3.1 - step 2 - "PktSource TLV" to "PktSource data element"
9.3.1 - step 3 - "MetricType TLV" to "MetricType data element"
and remove "in the TLV" from the end of the sentence.
9.3.2 - step 2 - "MetricType TLV" to "MetricType data element"
9.3.3 - step 2 - "PktSource TLV" to "PktSource data element"
9.3.3 - step 3 - "MetricType TLV" to "MetricType data element"
9.3.3 - paragraph after step 6 - "PktSource TLV" to "PktSource
data element"
9.4.1 - "AckReq message TLV" to "AckReq data element"
A.5.1 - "AckReq TLV" to "AckReq data element"
All done.
We could change from ValidityTimeList to ValidityTime
throughout? I think the current way is OK, but it seems like
ValidityTime is more similar to OrigSeqNum than to MetricList
and should be handled without a list. (It's my fault its in
there as ValidityTimeList so I'll find all the bits to adjust if
you think this is worth doing)
I'm not sure about this. Notably, in the specification right
now, only one
address ever has an associated ValidityTime in any AODVv2 message.
I'll send another email shortly with more discussion.
Do we need UnreachableAddressList? Can we just use AddressList
and put one or more UnreachableAddresses in it? Again, not a
pressing issue
I really like this idea. But I encountered a logistical problem
in Table 3.
I created "RteMsg AddressList" and "RERR AddressList" for the
purpose.
Now, the section of that table looks as follows:
| RteMsg AddressList | RFC 5444 Address Block |
| - OrigAddr | |
| - TargAddr | |
| - PrefixLengthList | |
| RERR AddressList | RFC 5444 Address Block |
| - UnreachableAddress | |
| - PrefixLengthList | |
Do we need to add OrigSeqNum, OrigAddrMetric, TargAddrMetric and
TargSeqNum in the terminology section? They are in section 3 but
someone might expect them to be in with all the other
terminology too. AckReq, PktSource too?
As far as Terminology goes, the more definitions the merrier, as
long as they are used
in the document. Another possibility would be to enlarge some of
the definitions in the
Terminology section to indicate which of the terms are "official"
AODVv2 data elements.
I think you have enough text in there already to understand the
RFC5444 multi-value address block TLVs - I just hadn't read it
properly. However, it is in section 10, so the reader could get
confused by section 9 before getting to it. Since Section 3 and
Section 10 have so many similarities, is it worth relocating
section 10 to immediately after section 3?
Section 10 seems to be a "late-document" kind of section. Maybe
it should be moved right after section 13?
Suggested text in relation to recent emails:
In section 2
SeqNumList
The list of Sequence Numbers associated with addresses in an
AddressList. Used in RERR messages.
In Section 3
SeqNumList
A list of SeqNums, included in RERR messages.
Done.
Apologies for the length of the email again, I hope this is all
useful and I'm not just being a GIANT pain in the ass!
This is super useful, and since I have in the past met
people who really are a giant pain in the ass I can state
with confidence that you bear no resemblance.
Regards,
Charlie P.
