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