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

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