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

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Jul 2009 16:22:17 -0500

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.)

> 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.

> -- 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

---

From: Abhay Roy <[email-masked]>
Date: Mon, 13 Jul 2009 15:44:23 -0700

Thanks for a quick check.. Comments inline..

On 7/13/2009 2:22 PM, Ben Campbell wrote:
>> 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.
>>
> 
> 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.).
> 
> (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.

>> 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..

>> If so, it would be helpful to be consistent in terminology.

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.

Regards,
-Abhay

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Jul 2009 19:17:51 -0500

On Jul 13, 2009, at 5:44 PM, Abhay Roy wrote:

>> This is an update to my gen-art review of draft-ietf-ospf-manet- 
>> or-01, reflecting version 02 of the same draft.
>>> Is the lack of any existing mechanism to authenticate and  
>>> authorize nodes to transit packets a show stopper for deployment?
>>>
>>> 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  
> 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.

>>> 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?

>>> 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?

---

From: Acee Lindem <[email-masked]>
Date: Mon, 13 Jul 2009 20:35:59 -0400

On Jul 13, 2009, at 8:17 PM, Ben Campbell wrote:

>>>> 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.
> 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.

It makes sense to acknowledge the original discussion of OSPF MANET  
threats (whether it be the MDR draft or RFC 5449). However, I don't  
think we need to worry about there being some replication of the less  
than draft two pages of security considerations.

Thanks,
Acee

>> 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.
>
>> 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.
>
> implementer will understand what you mean? If they do, will they  
> pick reasonable ranges of variation? Is it always positive?
>
>
>> Regards,
>> -Abhay
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Jul 2009 21:03:49 -0500

On Jul 13, 2009, at 7:35 PM, Acee Lindem wrote:

> think we need to worry about there being some replication of the  
> less than draft two pages of security considerations.
>
> Thanks,
> Acee
>

Okay, I'm convinced, and will yield this point.

Thanks!

Ben.

---

From: Abhay Roy <[email-masked]>
Date: Thu, 23 Jul 2009 11:25:31 -0700

[sorry for the delay]

Please see responses inline:

On 7/13/2009 5:17 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.
>>>> been done in that direction, it would be beneficial to document it now.
>>>>

We agreed to keep this unchanged in a later email exchange with Acee.

> Given that I'm not sure how you would stop them, it probably makes sense 
> to be non-normative :-)
> 

Sure, I will change it to non-normative ;)

>> 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