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.
