I am the assigned Gen-ART reviewer for this document. For background
on Gen-ART, please see the FAQ at:
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
Please consider these comments along with any other last call comments you
may receive.
Document: draft-ietf-idr-rfc3065bis-05.txt
(along with draft-mcpherson-idr-rfc3065bis-impl-00)
Intended status: Draft
Reviewer: Harald Alvestrand
Date: August 16, 2006
Summary: Ready, has nits
This draft is going for Draft Standard. The implementation report (which is an
expired internet-draft, but also stored in the implementation repository;
http://www.ietf.org/IESG/Implementations/implem_RFC3065bis.txt) is also
reviewed here.
Basically, I think this is ready.
Nits:
- The document has no "changes from RFC 3065" section. The introduction has a
paragraph outlining the changes, but does not specify exactly what the protocol-impacting
changes (if any) are. For implementors attempting to upgrade their implementation to
conformance with the new document, such a section would be very helpful.
- Protocol puzzlement: As far as I can see, this protocol extension defines the
AS_CONFED_SET segment type, and specifies when it needs to be removed from an AS_PATH,
but never specifies a condition under which an AS_CONFED_SET is inserted. If that's
correct, adding the phrase "not used now, reserved for future extension" to the
definition in section 3 would be helpful.
- Supernitty nit: In section 7, the sentence
Additionally, confederations (as well as route reflectors), by
excluding different reachability information from consideration at
different locations in a confederation, have been shown [RFC 3365]
cause permanent oscillation between candidate routes when using the
tie breaking rules required by BGP [BGP-4].
is missing the word "to" before the word "cause" in the next-to-last line.....
Implementation report nits:
- It refers to BGP-4 as "work in progress". Should be updated to existing BGP
spec.
- The document is unclear on whether it's an implementation report for
rfc3065bis (in header) or RFC 3065 (in normative references). It should decide
one way or the other - not that I think it matters, given the apparent lack of
technical changes.
IDNits output:
idnits 1.105
tmp/draft-ietf-idr-rfc3065bis-05.txt:
Checking nits according to http://www.ietf.org/ID-Checklist.html:
* The document seems to lack an IANA Considerations section.
Checking conformance with RFC 3978/3979 boilerplate...
* Found RFC 3978 Section 5.4 paragraph 1 boilerplate (on line 519), which
is fine, but *also* found RFC 2026 Section 10.4C paragraph 1 boilerplate
on line 36. It should be removed.
* There are 3 instances of too long lines in the document, the longest one
being 1 character in excess of 72.
Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
Nothing found here (but these checks do not cover all of
1id-guidelines.txt yet).
Miscellaneous warnings:
- Line 332 has weird spacing: '... system withi...'
- The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
Experimental warnings:
- Unused Reference: 'RFC 1771' is defined on line 443, but not referenced
- Unused Reference: 'RFC 1863' is defined on line 446, but not referenced
- Unused Reference: 'RFC 2119' is defined on line 449, but not referenced
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
