On Aug 16, 2006, at 2:30 AM, Harald Alvestrand wrote:
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.
Harald,
Good feedback, thanks. I'll add a complete "changes from previous
rev/3065"
section, as there were a few noteworthy for the implementer. I'm
still working
with John on what to do with AS_CONFED_SET - more to follow there. I'll
fix the nits below as well.
Good feedback from the GEN-ART team, many thanks!
-danny
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
