[OSPF] Re: Comments on draft-ietf-ospf-rfc2370bis-00.txt

Hi Lou,
Sounds good - this choice is both backward compatible and symmetric  
with respect to setting and interpreting the O options bit in other  
packet types.
Thanks,
Acee
On Apr 11, 2007, at 9:45 AM, Lou Berger wrote:

> Acee,
>
> Okay.  Will go with SHOULD NOT set and SHOULD ignore on receipt for  
> other packet types.
>
> Lou
> At 09:58 AM 4/10/2007, Acee Lindem wrote:
>
>> Hi Lou,
>>
>> On Apr 10, 2007, at 8:59 AM, Lou Berger wrote:
>>
>>> Acee,
>>>
>>> Thanks for the comments.  Please see below.
>>>
>>> At 02:23 PM 4/6/2007, Acee Lindem wrote:
>>>
>>>> Lou, Alex, Igor,
>>>>
>>>> I have three categories of comments:
>>>>
>>>>    Technical   - For WG discussion
>>>>    Editorial   - Text changes I think are needed
>>>>    Suggestions - Style comments based on my own preferences and
>>>>                  RFC Editor guidelines. I had a conversation with
>>>>                  them in Prague regarding style and improving
>>>> document
>>>>                  readability.
>>>>
>>>>  See section 4 (starting on slide 47) in <ftp://ftp.rfc- 
>>>> editor.org/ in-notes/rfc-editor/tutorial.latest.pdf>ftp:// 
>>>> ftp.rfc-editor.org/ in-notes/rfc-editor/tutorial.latest.pdf
>>>>
>>>>    Technical Comments on draft-ietf-ospf-rfc2370bis-00.txt
>>>>
>>>> 1. Page 6, First Paragraph - I think we should change "MUST NOT" to
>>>>    "MAY". Also, go ahead and make two sentenses rather than
>>>> connecting them
>>>>    with a semicolon.
>>>>
>>>>  A neighbor is opaque-capable if and only if it sets the O-bit  
>>>> in the
>>>>  options field of its Database Description packets. The O-bit MAY
>>>> be set in
>>>>  the options field for other packet types its setting is not
>>>> mandatory.
>>>
>>> okay, but as the meaning of the 0-bit in other packet types isn't
>>> defined, is  "SHOULD NOT" acceptable?
>>
>> This would certainly be better than "MUST NOT" since it doesn't imply
>> we shouldn't accept the packet. I don't see a big advantage in trying
>> to enforce a different set of options on DD packets versus hello
>> packets. With LLS as WG document, I'd rather extend the protocol via
>> that mechanism rather than redefining options bits for different
>> packet types.
>>
>>>
>>>> I guess I'm not compelled to potentially render existing
>>>> implementations
>>>> in compatible and the "MUST NOT" begs the question of what one
>>>> does if
>>>> it is set in other pacØÛ Èˆ=ÿÿÿÿlZb ket types.
>>>
>>> agreed, but I think the question is even more relevant with MAY.
>>
>> In either case, I think we should say it "SHOULD be ignored on packet
>> types other than Database Description packets". This may seem
>> inconsistent with the above but it is in the spirit of bine "liberal
>> in what you accept".
>>
>>
>>
>>>
>>>
>>>>     Editorial Comments on draft-ietf-ospf-rfc2370bis-00.txt
>>>>
>>>> [..]
>>>
>>> okay to all.
>>
>> Great.
>>
>> Thanks,
>> Acee
>>
>>>
>>> Lou
>>>
>>
>>
>>
>

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf