Docuemtn: draft-ietf-idr-bgp-analysis-06.txt Review: Elwyn Davies Date: 29 november 2004 I was asked to take a look at this doc, re-reviewing it after fixes relating to comments on -05 by Lucy Lynch. Unfortunately the updates don't appear to have taken care of many of the formatting and boilerplate issues flagged by idnits. There are still several over-long lines and hyphenations plus the URL for the list of I-Ds is still wrong. Idnits output follows: idnits 1.51 tmp/draft-ietf-idr-bgp-analysis-06.txt: tmp/draft-ietf-idr-bgp-analysis-06.txt(41): Line is too long: the offending characters are 'ld be' tmp/draft-ietf-idr-bgp-analysis-06.txt(189): Line seems to end with a hyphenated word. --> that routing within an autonomous system is done by an intra- tmp/draft-ietf-idr-bgp-analysis-06.txt(368): Line seems to end with a hyphenated word. --> flapping. However, although peer oscillation is found to be wide- tmp/draft-ietf-idr-bgp-analysis-06.txt(447): Line seems to end with a hyphenated word. --> The aggregation scheme, defined in [CIDR],describes the provider- tmp/draft-ietf-idr-bgp-analysis-06.txt(540): Line is too long: the offending characters are '--' tmp/draft-ietf-idr-bgp-analysis-06.txt(581): Line seems to end with a hyphenated word. --> interactions with network engineers in an environment lacking vendor- tmp/draft-ietf-idr-bgp-analysis-06.txt(630): Line has weird spacing: '... AS4 is a mul...' tmp/draft-ietf-idr-bgp-analysis-06.txt(749): Line is too long: the offending characters are 'd' tmp/draft-ietf-idr-bgp-analysis-06.txt(750): Line is too long: the offending characters are 'ts' tmp/draft-ietf-idr-bgp-analysis-06.txt(754): Line is too long: the offending characters are 're' tmp/draft-ietf-idr-bgp-analysis-06.txt(756): Line is too long: the offending characters are 'g' tmp/draft-ietf-idr-bgp-analysis-06.txt(757): Line is too long: the offending characters are 'ic' tmp/draft-ietf-idr-bgp-analysis-06.txt(762): Line is too long: the offending characters are 'AS' tmp/draft-ietf-idr-bgp-analysis-06.txt(951): Line is too long: the offending characters are 's for' tmp/draft-ietf-idr-bgp-analysis-06.txt(952): Line is too long: the offending characters are 'rogress.' tmp/draft-ietf-idr-bgp-analysis-06.txt(957): Line is too long: the offending characters are 'P",' Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3667/3668 boilerplate... the boilerplate looks good. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? (Expected a match on the following text: "The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html" ... but found this: "The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.") Miscellaneous warnings: None Other matters relating to language: =================================== Terminology: There is a considerable amount of terminology in the document which is not defined either explicitly or by reference, notably BGP speaker, peer, EBGP Some language improvements: Section 1: s/Classless InterDomain/Classless Inter-Domain/ in line with title of [CIDR] Section 2.1, para 1: s/network layer reachability information/Network Layer Reachability Information/ Section 2.2, para 1, last sentence: s/assist/assists/(also in para 2 last sentence), s/select/to select/ Section 2.2, para 2, last sentence: I don't think you can limit congestion to window limits: How about 'The window limits used by TCP further assists BGP to constrain any congestion that might result from updates.' Section 2.2: para 3: s/sent as a single Network Layer Reachability (NLRI)./sent in a single Network Layer Reachability Information (NLRI) attribute./ Section 2.3: s/There may exist a temporary period where in a BGP peer may have separate incoming and outgoing connections resulting into two different BGP FSMs for a peer (instead of one). This can be resolved following BGP connection collision rules defined in the [BGP4]./ There may be a short period during which a BGP peer may have separate incoming and outgoing connections resulting in the creation of two different BGP FSMs relating to a peer (instead of one). This can be resolved by following the BGP connection collision rules defined in the [BGP4] specification./ Section 2.3, para 3: s/Following are different states of BGP FSM for its peers:/The BGP FSM has the following states associated with each of its peers:/ Section 2.3, next to last para: s/different/a number of/, s/BGP FSM/the BGP FSM/, s/These BGP events are/Support of these BGP events is/, s/using an/as a result of/ Section 2.3, last para: s/Both,/Both/ s/in details/in detail/ Section 4: Should be consistent in using either 'flapping' or 'oscillation'. Flapping is normally used with routes. Section 4: Is 'Ideally' the right word? ... Maybe either 'By default' or 'According to [BGP]' Section 5: s/bound,/bounded,/ s/loosing/losing/g s/clesrly/is clearly/ Section 6.1: s/,describes/, describes/ Section 6.1.1: s/announcments/announcements/ s/During the periods/During periods/ Section 6.1.2: s/byte/octet/g s/(and ignoring/(ignoring/ Section 7, para 2: s/provided hundreds/provide hundreds/ [? really hundreds??] s/more and more/increasingly/ Section 7: s/nondeterminism/non-determinism/g Section 8: s/we answer the question of which environments is BGP well suited/we identify the environments for which BGP is well suited/ Section 8, para 3: s/that allow/that allows/ Section 8, lata para: s/suitable/suited/ Section 10: s/exhanged/exchanged/ s/guage/gauge/ s/vulneribility/vulnerability/ Section 10: Need to expand the EBGP abbreviation. Section 10: The reference to [SOBGP] is inconsistent with the list of refs [soBGP]. Also another couple of editorial nits: (Throughout) There are multiple blank lines surrounding section headings and in some cases between paragraphs - a single blank line would save paper.