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
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf

Reply via email to