[aodvv2-discuss] Writing for the future <was, Appendices and RFC 5444 >
- From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Tue, 3 Mar 2015 09:20:36 +0000
Hi Lotte,
This was based on the notation at the start of the appendix for a general
RteMsg. Good catch, I should have had RteMsg.OrigAddrMetric and
RteMsg.TargAddrMetric in there and throughout, same way I did for seqnums.
Regards,
Vicky
On Tuesday, March 3, 2015, Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx
<javascript:_e(%7B%7D,'cvml','lotte.steenbrink@xxxxxxxxxxxx');>> wrote:
> Hi Victoria,
>
> one small question– While loking for occurrences of OrigAddrMetric I
> noticed that the metric of a RREQ was only referred to as *RREQ.metric ,
> instead of *RREQ.OrigAddrMetric (the same with RREP). While there is only
> one metric value in each packet that needs to be looked at, it's
> counterintuitive to me to switch from using the name of the Metric TLV
> that's being used there to (the admittedly more concise) “metric”.
>
> Or am I missing something here?
>
> Regards,
> Lotte
>
> Am 02.03.2015 um 17:17 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
>
> Hi all,
>
> Further to this, I've finished updating Appendix A (attached) to reflect
> the current contents of section 8 and 9 and had a stab at updating the RFC
> 5444 bits too (please don't shoot me!)
>
> A couple of things I noticed while doing this:
> 8.6 - should say it needs to match MsgType too, and also we could update
> this section to say RteMsg not only RREQ
> 9.3.2 - if the current route to UnreachableAddress in the RERR is already
> invalid, we can ignore and move on to the next UnreachableAddress - I put
> this in the appendix pseudo-code too.
> A.5.1 - it says MF = 0, but all other messages say MF = 4 because only the
> msg-hop-limit field is there, which is true of this message too, should
> this also be MF = 4?
>
> Regards,
> Vicky.
>
>
> On Fri, Feb 27, 2015 at 10:37 PM, Victoria Mercieca <vmercieca0@xxxxxxxxx>
> wrote:
>
>> Hi Charlie,
>>
>> Thanks for the new version, I'll give it a read over the next day or so.
>>
>> Couple more comments below.
>>
>>
>> On Fri, Feb 27, 2015 at 10:22 PM, Charlie Perkins <
>> charles.perkins@xxxxxxxxxxxxx> wrote:
>>
>>> Hello Vicky,
>>>
>>> It would be a sin to mandate use of the RFC 5444 parser in order
>>> to build AODVv2. On the other hand, it would be a sin to make it
>>> difficult to use the RFC 5444 parser.
>>>
>>> Then maybe it should stay there. It will be valuable for implementors
>> who are not going to use a RFC5444 parser.
>>
>>
>>> Regarding the pseudo-code, well, some people really like having
>>> pseudo-code, and to others it doesn't matter. I thought that Stan's
>>> object mainly revolved around making a bigger target for criticism
>>> from people looking for that sort of thing.
>>>
>>> I guess the pseudo-code could stay there too for the people that would
>> prefer it to the descriptions in Sections 8 and 9. It does pretty much
>> duplicate whats already been said, but if there's value in it being
>> expressed in this way I don't have any real objection.
>>
>> Regards,
>> Vicky.
>>
>> Regards,
>>> Charlie P.
>>>
>>>
>>> On 2/27/2015 2:09 PM, Victoria Mercieca wrote:
>>>
>>> Hi all,
>>>
>>> As I was looking at it, the pseudo-code stuff seemed to overlap a lot
>>> with what we have in sections 8 and 9.
>>>
>>> The RFC 5444 stuff - if we are handing our Data Elements to a RFC5444
>>> implementation and we don't actually create the RFC5444 message ourselves,
>>> I don't know that we need to include it. If there might be AODVv2
>>> implementations that attempt to create the RFC5444 message directly, it
>>> would be useful.
>>>
>>> Regards,
>>> Vicky.
>>>
>>>
>>> On Fri, Feb 27, 2015 at 9:54 PM, Charlie Perkins <
>>> charles.perkins@xxxxxxxxxxxxx> wrote:
>>>
>>>> Hello Stan and all,
>>>>
>>>> There are two appendix sections. One shows example RFC 5444 formats.
>>>> The other shows some pseudocode. These are independent of each other.
>>>>
>>>> I hear your frustration about RFC 5444 discussions in the past. But
>>>> please
>>>> consider that we are writing this specification for future implementers,
>>>> not as a rebuttal to ongoing RFC 5444 discussions and recriminations.
>>>>
>>>> From *that* standpoint, I think the case for inclusion is very clear.
>>>> The
>>>> downside is that we might make mistakes. But, if we DO make mistakes,
>>>> that only makes the case for inclusion even stronger! Because, if WE
>>>> make
>>>> those mistakes, then future implementers are even MORE likely to make
>>>> those mistakes.
>>>>
>>>> Of course our jobs as editors will be easier if we delete text. I
>>>> don't view
>>>> that as the highest priority for decision making, however.
>>>>
>>>> Please consider this when making your decision.
>>>>
>>>> Regards,
>>>> Charlie P.
>>>>
>>>>
>>>>
>>>> On 2/27/2015 1:46 PM, Stan Ratliff wrote:
>>>>
>>>> Charlie,
>>>>
>>>> Catching up on the recent email, I now see 3 "votes" to remove the
>>>> 5444 discussions in the appendices - granted, I may be overstating Vicky's
>>>> position, but...
>>>>
>>>> So, that leaves 3 votes to pull it out, 1 to keep it (yours), and "1
>>>> in the wind" (Lotte, but then it's late in Germany)... ;-)
>>>>
>>>> What I'm proposing is that we only wait for consensus in the
>>>> Editorial team before posting to the list - I'd assume Monday at the
>>>> latest. Otherwise, I'll feel obligated to follow the posting with an email
>>>> stating we're discussing pulling that information out (and thereby
>>>> soliciting WG input on the issue).
>>>>
>>>> Regards,
>>>> Stan
>>>>
>>>>
>>>> On Fri, Feb 27, 2015 at 3:42 PM, Charlie Perkins <
>>>> charles.perkins@xxxxxxxxxxxxx> wrote:
>>>>
>>>>> Hello Stan,
>>>>>
>>>>> Please read to the end of this email...
>>>>>
>>>>> I did mean to submit the current revision as an Internet Draft.
>>>>> It includes almost all of the issue resolutions. We need to have it
>>>>> out there so we can point out to people the issue resolutions in
>>>>> the draft. Jiazi already complained about this.
>>>>>
>>>>> Are you really set against this? If so, how else can we have a
>>>>> reasonable discussion on the mailing list about the many and
>>>>> pervasive changes to the draft? Draft ...-06 has some errors that
>>>>> need to be corrected ASAP. I am O.K. to make draft ...-07 today
>>>>> and draft ...-08 next week, including mailing list discussion about
>>>>> draft ...-07...
>>>>>
>>>>> Did you look at the "Changes" section in the recent intermediate
>>>>> revisions?
>>>>>
>>>>> I fear that if we can't have the mailing list discussion about the
>>>>> issue resolutions, we will miss our deadline. If, on the other hand,
>>>>> we can have the discussion, there is a chance that the draft would
>>>>> be ready for Last Call by Dallas.
>>>>>
>>>>> I don't mean it will be perfect. I mean that we can represent that
>>>>> we have taken action to resolve the issues.
>>>>>
>>>>> Regards,
>>>>> Charlie P.
>>>>>
>>>>>
>>>>>
>>>>> On 2/27/2015 12:19 PM, Stan Ratliff wrote:
>>>>>
>>>>> Charlie,
>>>>>
>>>>> When you say "put this version out", do you mean post it to the
>>>>> MANET list? Or, just "discuss amongst ourselves"? I would agree with the
>>>>> latter, but not the former.
>>>>>
>>>>> Regards,
>>>>> Stan
>>>>>
>>>>> On Fri, Feb 27, 2015 at 3:15 PM, Charlie Perkins <
>>>>> charles.perkins@xxxxxxxxxxxxx> wrote:
>>>>>
>>>>>> Hello Stan,
>>>>>>
>>>>>> Oh, O.K. -- I did misunderstand...
>>>>>>
>>>>>> By the way, I think we agreed to have another teleconference next
>>>>>> Thursday morning. The plan currently is to put out this revision
>>>>>> today,
>>>>>> so we can discuss whether the existing issues have been resolved.
>>>>>> Then we will make another revision (...08) before the draft deadline.
>>>>>>
>>>>>> Regards,
>>>>>> Charlie P.
>>>>>>
>>>>>>
>>>>>> On 2/27/2015 12:08 PM, Stan Ratliff wrote:
>>>>>>
>>>>>> Charlie,
>>>>>>
>>>>>> Umm, no. You misunderstand. I'm calling for consensus *amongst the
>>>>>> author team*. From the way I read this thread, there's already some
>>>>>> amount
>>>>>> of push-back from Vicky, and myself.
>>>>>>
>>>>>> I await the responses from the other members of the team.
>>>>>>
>>>>>> Regards,
>>>>>> Stan
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 27, 2015 at 2:54 PM, Charlie Perkins <
>>>>>> charles.perkins@xxxxxxxxxxxxx> wrote:
>>>>>>
>>>>>>> Hello Stan,
>>>>>>>
>>>>>>> Well, I certainly get how you feel about this. Nevertheless, I would
>>>>>>> really like to keep those appendices around. Let's see if anyone
>>>>>>> actually
>>>>>>> does make the complaint that you are suggesting. We can take out the
>>>>>>> appendices very easily, but once they are out, it would be very hard
>>>>>>> to
>>>>>>> get them back in...
>>>>>>>
>>>>>>> Regards,
>>>>>>> Charlie P.
>>>>>>>
>>>>>>>
>>>>>>> On 2/27/2015 11:14 AM, Stan Ratliff wrote:
>>>>>>>
>>>>>>> Sorry for the double-post on this topic. I saw another item that I
>>>>>>> want to comment on. text inline.
>>>>>>>
>>>>>>> On Fri, Feb 27, 2015 at 1:09 PM, Charlie Perkins <
>>>>>>> charles.perkins@xxxxxxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> Hello Vicky,
>>>>>>>>
>>>>>>>> One comment below...
>>>>>>>>
>>>>>>>> On 2/27/2015 8:02 AM, Victoria Mercieca wrote:
>>>>>>>>
>>>>>>>>> Hi Charlie,
>>>>>>>>>
>>>>>>>>
>>>>>>>> <.... editorial comments all done with microscopic wordsmithing in
>>>>>>>>> a couple of places... >
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Appendices:
>>>>>>>>> I started looking at updating the appendix A algorithms but I'm
>>>>>>>>> not sure there's much point - this stuff seems to be in section 8 and
>>>>>>>>> section 9 in the main body of the draft now, and I'm not sure if we
>>>>>>>>> should
>>>>>>>>> be instructing how to construct the RFC5444 messages? I've attached my
>>>>>>>>> early work on this and I put some comments between <>, it might be
>>>>>>>>> worth
>>>>>>>>> merging anything thats not already in sections 8 or 9 and removing
>>>>>>>>> appendix
>>>>>>>>> A?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I spent a long time on those appendices, and it seems like a lot of
>>>>>>>> people might benefit from actually seeing how the RFC 5444 headers
>>>>>>>> look in real life.
>>>>>>>
>>>>>>>
>>>>>>> Place my vote FIRMLY in the camp that says "remove any and all
>>>>>>> instruction, tables, appendicies, etc. that attempt to divine the
>>>>>>> rationale
>>>>>>> behind the cluster-@!#!@ that is RFC 5444.
>>>>>>>
>>>>>>> There have been literally HUNDREDS, if not THOUSANDS, of emails
>>>>>>> and discussions that whirl and whine around the notion that "... the
>>>>>>> AODVv2
>>>>>>> authors either don't know, or are attempting to bastardize, that
>>>>>>> WONDERFUL,
>>>>>>> MAJESTIC, EASY-TO-READ-AND-UNDERSTAND, piece of BRILLIANCE that is RFC
>>>>>>> 5444!"
>>>>>>>
>>>>>>> In the current hyper-heated political environment we find
>>>>>>> ourselves in, I'd MUCH rather take any and all possible ammunition away
>>>>>>> from the opposing camp - notwithstanding the facts that (a) you spent a
>>>>>>> lot
>>>>>>> of time on the appendices, and (b) frankly, I like the way they look. At
>>>>>>> this point, I'd rather not (even inadvertently) hand the anti-AODVv2
>>>>>>> camp a
>>>>>>> hand grenade they can use to blow us up with...
>>>>>>>
>>>>>>> Regards,
>>>>>>> Stan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Plus, from comments received at the time, it was
>>>>>>>> clear that there are many ways to get it wrong. Even recently, I
>>>>>>>> was
>>>>>>>> using "Tail" instead of "Mid" -- and nobody caught that for well
>>>>>>>> over
>>>>>>>> a year.
>>>>>>>>
>>>>>>>> This leads me to think that there is a lot of value in that
>>>>>>>> non-normative
>>>>>>>> pseudocode, and I don't think it hurts anything to have it there.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Charlie P.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
> <appendix a update complete.txt>
>
>
>
Other related posts:
