Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 1 Jan 2013 09:49:06 +0100

Thanks. Regarding message-names, I was not happy with the names
OrigRtr, and RteMsg, because still remember the msg-names of RFC3561,
but never objected because not necessary, however, I agree/like the
amendment :)

AB

On 12/30/12, Charles E. Perkins <[email-masked]> wrote:
> Hello Henning,
>
> I have been thinking a lot about the readability issues.
>
> Here are notational devices used in the current specification:
>
>       |   Route[DestAddr]   |   A route table entry towards DestAddr  |
>       | Route[Addr].{field} |      A field in a route table entry     |
>
> I am assuming these are O.K.
>
>       |          --         | --                   |
>       |   <msg-hop-count>   | RFC 5444 Message Header <msg-hop-count> |
>       |   <msg-hop-limit>   | RFC 5444 Message Header <msg-hop-limit> |
>       |       AddrBlk       |      an RFC 5444 Address TLV Block      |
>       |      AddrBlk[1]     |    The first address slot in AddrBlk    |
>       |      AddrBlk[N]     |     The Nth address slot in AddrBlk     |
>       |  AddrBlk[OrigNode]  | AddrBlk[1]               |
>       |  AddrBlk[TargNode]  | AddrBlk[2]               |
>       |       AddrTLV       |      an RFC 5444 Address Block TLV      |
>       |      AddrTLV[1]     |        the first item in AddrTLV        |
>       |      AddrTLV[N]     |         the Nth item in AddrTLV         |
>       |  AddrTLV[OrigNode]  | AddrTLV[1]               |
>       |  AddrTLV[TargNode]  | AddrTLV[2]               |
>
> These are pretty intuitive, given the notation already in RFC 5444.
>
>       |      SeqNumTLV      |   Sequence Number AddrTLV for AddrBlk   |
>
> Looks O.K. to me...?
>
>       |       OrigNode      |             Originating Node            |
>       |       RREQ_Gen      |    AODVv2 router originating an RREQ    |
>       |       RREP_Gen      |   AODVv2 router responding to an RREQ   |
>       |        RteMsg       |           Either RREQ or RREP           |
>       |    RteMsg.{field}   |          Field in RREQ or RREP          |
>       |      RteMsg_Gen     |        Router generating a RteMsg       |
>       |     HandlingRtr     |             Handling Router             |
>       |       TargNode      |               Target Node               |
>       |   UnreachableNode   |             Unreachable Node            |
>
> I am guessing that, if you find any of the notation difficult to read,
> it would be one of these.  I have been steadily reducing the number of
> different such notations over time, but the above seem to be very useful
> and seem pretty transparent to me.
>
> I have replaced "OrigRtr" by "RREQ_Gen" and "TargRtr" by "RREP_Gen" in
> the version I am editing now.  This has the advantage of reducing the
> number
> of notational devices, but did require some rewording of certain sentences
> that seemed to make better sense with the earlier notation.
>
> The case for using "RteMsg" to stand for either RREQ or RREP is pretty
> strong, for anyone who believes in eliminating redundancy in specification.
> There are quite many protocol actions that are the same for RREQ as they
> are for RREP.  To write the relevant sections twice seems wrong to me.
> However, I am quite open to using any other terminology if there are
> suggestions for improvement.  For instance, one could replace all
> instances of "RteMsg" by "RREQ_or_RREP", but (it seems to me) that
> would typically *reduce* readability instead of enhancing it.
>
> If the claim is that *any* such abbreviations should be replaced with
> fully spelled out words, then we should have a discussion.  For instance,
> "UnreachableNode" is equally readable as "Unreachable Node", but the former
> has the advantage of immediately connoting a distinguished term in the
> document.  I tried to have a discussion about this before, using
> "F = ma" as an example (no one complained about the mistake in the
> previous example, surprisingly to me).  As I said before, to someone
> who knows what 'F', 'm', and 'a' mean, "F = ma" is a lot more readable
> than "Force is the same as the product of mass and acceleration".
> Even more to the point, "F = ma" is pretty easy to remember.
> But to someone who has never before encountered the abbreviations for
> those fundamental quantities, "F = ma" is impenetrable.
>
> To reiterate after having said all that, I always remain quite open
> to suggestions for ways to improve the notation.
>
> If there are other concerns about readability, please do not hesitate
> to point them out.  I have made major improvements in document
> organization and editorial style during the last two months, and
> so I hope that you can take a fresh look.
>
> On 12/6/2012 12:37 AM, Henning Rogge wrote:
>> On 12/05/2012 10:45 PM, Charles E. Perkins wrote:
>>>
>>> Hello Henning,
>>>
>>> Here is some more follow-up on your observations and suggestions.
>>>
>>> On 12/3/2012 5:25 AM, Henning Rogge wrote:
>>>>
>>>> > Handling Router (HandlingRtr)
>>>> > HandlingRtr denotes the AODVv2 router handling an AODVv2 message.
>>>>
>>>> Do you really need the "HandlingRtr" abbreviation? It complicates the
>>>> text and does not shorten it that much.
>>>
>>> Would you like to see this terminology changed to instead be "Handler"?
>>> I guess there's no need to constantly remind the reader that the node
>>> doing the AODVv2 processing is a "router"...
>>
>> I think we should have a discussion on the list if that many
>> abbreviations are really useful/necessary for a draft/rfc. In my
>> opinion they have no advantage (beyond saving a few characters) and
>> make the draft harder to read.
>>
>
> --
> Regards,
> Charlie P.
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>