Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-ospf-manet-or-01

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Aug 2009 15:27:40 -0500

Hi,

Your email addresses the remainder of my comments.

Thanks!

Ben.

On Jul 23, 2009, at 1:25 PM, Abhay Roy wrote:

> [sorry for the delay]
>
> Please see responses inline:
>
> On 7/13/2009 5:17 PM, Ben Campbell wrote:
>> On Jul 13, 2009, at 5:44 PM, Abhay Roy wrote:
>>> Thanks for a quick check.. Comments inline..
>>>
>>> On 7/13/2009 2:22 PM, Ben Campbell wrote:
>>>> This is an update to my gen-art review of draft-ietf-ospf-manet- 
>>>> or-01, reflecting version 02 of the same draft.
>>>> All of my comments have been addressed except where noted inline.
>>>> Thanks!
>>>> Ben.
>>>> On Dec 23, 2008, at 3:47 PM, Ben Campbell wrote:
>>>>> I have been selected as the General Area Review Team (Gen-ART)
>>>>> reviewer for this draft (for background on Gen-ART, please see
>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>>>>
>>>>> Please resolve these comments along with any other Last Call  
>>>>> comments
>>>>> you may receive.
>>>>>
>>>>> Document: draft-ietf-ospf-manet-or-01
>>>>> Reviewer: Ben Campbell
>>>>> Review Date: 2008-12-23
>>>>> IETF LC End Date: 2008-12-24
>>>>> IESG Telechat date: (if known)
>>>>>
>>>>>
>>>>>
>>>> [...]
>>>>> -- Section 4:
>>>>>
>>>>> Is the lack of any existing mechanism to authenticate and  
>>>>> authorize nodes to transit packets a show stopper for deployment?
>>>>>
>>>>> If this was standards track, I would want to see a lot more  
>>>>> here, e.g. some exposition of threat models implied by the  
>>>>> wirelessness, or introduced by the extensions and procedures  
>>>>> described in this draft. (Or rational that there are not any new  
>>>>> threat models)  It's probably okay for an experimental RFC to  
>>>>> have less, as I assume we expect to learn such things from  
>>>>> experience. But if any thinking has been done in that direction,  
>>>>> it would be beneficial to document it now.
>>>>>
>>>> My comments on this section have been addressed,  but the  
>>>> approach has been to completely replicate the Security  
>>>> Consideration section (or at least a large part of it ) from  
>>>> [MDR]. Although the text is attributed, there is no visual  
>>>> distinction to show where the quote starts and ends (i.e. quote  
>>>> marks, indents, etc.).
>>>> The easiest solution is probably to simply reference the text  
>>>> from [MDR], rather than quoting it all here.
>>>> (I now consider this an editorial comment rather than a  
>>>> substantive one.)
>>>
>>> The chairs thought it will be best to use the same Security  
>>> Consideration for all MANET drafts. It's not a 100% quote, since  
>>> some references were RFC* in MDR v/s names in OR. Also, it changes  
>>> the mention of MDR in the text to OR. So almost identical.
>>>
>>> I am happy to remove the quoted text, and just leave the reference  
>>> to it, if that makes is clearer.
>> If it's not identical, then it may make sense to leave it. It would  
>> be helpful to visually identify any exact quoted text, though.
>
> We agreed to keep this unchanged in a later email exchange with Acee.
>
>>>
>>>>> Nits and editorial comments:
>>>>>
>>>> [...]
>>>>> -- Section 3.1, paragraph 2:
>>>>>
>>>>> It's not clear to me if the "MAY" constrains protocol, or  
>>>>> constrains future standards work. If the second, it probably  
>>>>> should not use 2119 language.
>>>>>
>>>> No change.
>>>
>>> I read that paragraph in the last edit, and what it's trying to  
>>> say is other interface types could use the features introduced for  
>>> this interface type. If that is confusing, I can drop the case to  
>>> non 2119 language.
>> Given that I'm not sure how you would stop them, it probably makes  
>> sense to be non-normative :-)
>> In particular, it does not put a normative requirement on  
>> implementations of _this_ draft, right?
>
>
> Sure, I will change it to non-normative ;)
>
>
>>>>> -- Section 3.3.10: PushBackInterval
>>>>>
>>>>> Referring sections mention PushbackInterval + jitter. Jitter is  
>>>>> not mentioned here--is propagation delay the same thing in this  
>>>>> context? If so, it would be helpful to be consistent in  
>>>>> terminology.
>>>> No change
>>>
>>> Jitter is a very well known practice in routing algorithms as a  
>>> way to add a small random percentage (say 10%) to a timer. This  
>>> section deals with just the definitions of the newly introduced  
>>> timers, so it doesn't mention the jitter. It's the application  
>>> section which mention the introduced variance in the exact value.  
>>> Hope that clears it up.
>> Jitter is conceptually well known, but can you assume every  
>> implementer will understand what you mean? If they do, will they  
>> pick reasonable ranges of variation? Is it always positive?
>
> Implementations can choose jitters, and they are all interoperable,  
> including the case of no jitter at all. There is no requirement for  
> jitter to be only positive.
>
> Regards,
> -Abhay
>
>
>>> Regards,
>>> -Abhay