[aodvv2-discuss] Re: Writing for the future <was, Appendices and RFC 5444 >
- From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Tue, 3 Mar 2015 10:05:39 +0100
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:
