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
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.
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 packet types.
Editorial Comments on draft-ietf-ospf-rfc2370bis-00.txt
1. Other than in the RFC boilerplate, replace "memo" with "document".
Both are used in the document but, in the OSPF WG, we work on
"documents" rather than "memos".
2. Page 3, section 2 - Replace "Overview" with "Introduction". If you
run the id-nits script, it will point out that you have neglected
to include an "introduction" in your document (not your memo :^).
3. Page 6, second paragraph - Replace "Opaque LSAs MUST placed" with
"Opaque LSAs MUST be placed".
4. Page 7, third paragraph, remove the sentense "Each Database
Description packet MUST have ...". This is not new for opaque
LSAs.
5. Page 9, (1) - Singular/Plural problem. Replace "advertise
themselves as ASBRs." with "will advertise itself as an ASBR.".
6. Page 9,(2) - Replace "(i.e., ASBR" with "(i.e., the ASBR".
7. Page 9, Section 7, second paragraph - Replace "Note, that"
with "Note that".
8. Page 11, IANA Considerations - Add:
There are no changes to the IANA number assignment
requirements from
RFC 2370 [RFC2370].
If you don't, I can almost guarentee that they'll ask.
9. Page 13, Section 12.1, second paragraph - Replace
s "not to forward certain" with not to flood certain".
10. Page 15, third bullect - Replace "MUST NOTE" with "MUST NOT".
Suggestions based on RFC Editor Guidelines
1. Consistent with RFC Editor guidelines. Replace "types 9, 10 and
11" with
"types 9, 10, and 11".
2. Page 6, Section 3.2 - Replace "Summary LSAs and types 9 and 10" with
"Summary LSAs, type-9 opaque LSAs, and type-10 opaque LSAs".
3. Throughout - Replace Hello packets, Database Description packets
and" with
"Hello packets, Database Description packets, and".
4. Page 7, Protocol Data Structues - Replace "uses only, and"
with "uses only. They" There is a tendency for OSPF documents to
string
independent clauses together with ", and". I'd like to reverse
this trend.
5. Page 8, section 4.1, Neighbor Options - Replace "packets, and" with
"packets. It" or "packets and".
6. Page 8, section 5, first paragraph - Replace "applications, and" with
"applications and". At least that is the way I read it.
7. Page 8, section 5, second paragraphs - Split into more than one
sentense to
improve readability.
Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem
since the receiving router can detect whether or not the
advertising router
is reachable within the LSA's respective flooding scope. In the
case of
type-9 LSAs, the originating router must be an OSPF neighbor in
Exchange
state or greater. In the case of type-10 Opaque LSAs, the intra-
area SPF
calculation will determine the advertising router's reachability.
8. Page 9, first sentense - Replace "neither are AS scoped ...." with
"AS scoped opaque LSAs are not flooded into these area types.".
9. Page 9, Section 6, - Replace "ospfOriginateNewLsas" with
"ospfOriginateNewLsas,".
10. Page 14, section 12.2 - Replace "future extensibility of OSPF" with
"future OSPF extensibility".
11. Page 14, figure - Replace "9, 10 or 11 " with "9, 10, or 11".
12. Page 15, second bullet - Replace "the area that they are
originated into" with "their area of origin".
Thanks,
Acee
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
