Hi - Gave this a thorough review at the request of the chairs. I'll apologize in advance if I'm retreading old ground, I hadn't been paying close attention to this doc in the past.
Nits: 2.1: expand ASBR on first use. Also, reference RFC4760, etc since you're basically discussing MP-BGP? 3.4: add reference for MP_REACH_NLRI, are the last two "should" normative? If so, capitalize 3.5: is "recommended" normative? If so, you can probably drop the SHOULD (or vice versa) 4.2: is first "may" in 3rd paragraph normative? If so, capitalize Multiple instances of the phrase "It SHOULD be noted that..." - reword to make it clearer what is being normatively directed here and avoid passive voice, or eliminate normative SHOULD. Caveats and warnings don't necessarily need to be normative in that way. Fair warning - our newly-minted routing AD poked me repeatedly over making statements like "Operators [$2119_word] do [foo]" as a misuse of 2119 words. I defended it as being useful when warning about specific things that operators might do to break things, but you may want to use it carefully and be prepared to defend your choice. :-) Substantive: Section 2.2 mixes requirements and problem statement in a way that I'm finding a bit confusing. There's good text here that continues the problem statement's narrative about the changes to how we're using BGP. The first section talks about it from an SP infrastructure perspective, and then this section discusses it from the customer-facing services perspective. However, the inclusion of some requirements about how BGP needs to behave in these cases are better pulled from 2.2 and placed in a more clearly defined top section that discusses the requirements that are derived from both parts of the previous section's problem statements. In other words, I'm not sure you want normative text in a problem statement. You also want to be careful to distinguish what you mean by "requirements" since in the context of this document, they can be interpreted as both "what we need the protocol or implementations to do/what problem the IETF needs to solve" and "customer expectation of the performance and robustness of the service that is built using the protocols the IETF has defined". The latter is certainly important information, but IMO keeping the two cleanly differentiated will make for a clearer document. Similarly, I might suggest moving the normative text in the first part of section 3 and in section 3.5 elsewhere, as it is out of place with the rest of the text categorizing types of errors so that each type can be handled differently. Maybe move to the first part of section 4? More fundamentally: I think some parts of this document are beyond what is appropriate for an informational requirements document that doesn't formally update the BGP protocol spec(s). There is normative text in sections 3.4 and 4.1 (first paragraph) and the first part of section 5 that to the casual reader (who is not familiar with the difference between PS and info and/or missed the brief caveat at the end of the abstract) is explicitly defining new behavior in conflict with the existing standard. If this is simply defining what we'd like the behavior to be in order to address the problems defined elsewhere, we should dispense with the normative text and present it as a recommendation. When I think of a requirement in the context of an IETF document, I think in terms of a list of problems that need to be addressed by a given solution, or a list of functions that a given solution needs to provide. Usually we write those types of docs when we don't have a good solution yet, or we have multiple solutions and need a way to compare them by evaluating how many of the specific requirements each meets. It doesn't seem like either of those are true here, because this draft has actual solutions and even implementation guidance in a number of places. I like the solutions, and I think it's the right way to solve the problems discussed here, so let's skip a step and just publish the solution. Make some tweaks, keeping some of the first couple of sections as intro matter, and have the meat of the document focused on codifying the changes to the protocol and BGP speaker behavior. Move to PS, add the right "updates" metadata, and harden the normative language accordingly so that you can implement from this document. However, as a PS document, there's a question as to where it belongs, and the answer is probably IDR rather than GROW. I'm not sure how that works with the requirements for multiple interoperable implementations before a doc will last call in IDR, but perhaps that's something that the chairs and ADs can discuss to give us the most expedient path forward so that what comes out the other side is vendor implementations that help address the problems we've identified here? Thanks, Wes On 11/10/14, 1:43 AM, "[email protected]" <[email protected]> wrote: >Hi GROW, > >After a relatively long time dormant, since the solutions draft in idr >stablised, I¹ve updated the error handling requirements document. It >captures all the feedback that I¹ve received since the last rev. > >I hope this is stable enough for us to progress to last-call again :-) > >I¹d welcome comments, >r. > >> >> Title : Operational Requirements for Enhanced Error >>Handling Behaviour in BGP-4 >> Author : Rob Shakir >> Filename : draft-ietf-grow-ops-reqs-for-bgp-error-handling-07.txt >> Pages : 14 >> Date : 2014-11-09 Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
