[Forwarding it as I am not sure it got through] -------- Forwarded Message -------- Subject: Re: [bcop] Last Call: MANRS BCOP document Date: Mon, 28 Nov 2016 18:33:50 +0100 From: Massimiliano Stucchi <mstucchi@ripe.net> Reply-To: mstucchi@ripe.net Organisation: RIPE NCC To: bcop@ripe.net Hi, On 31/10/16 17:38, Andrei Robachevsky wrote:
As agreed at the RIPE BCOP TF meeting last week, here is a last call for the review of the MANRS BCOP document. This last call ends on November 28, 2016.
The document is available here: http://tinyurl.com/jlulren
I'm sorry if I write on the very last day of the last call period. We as Training Services were recently approached by Andrei about this document as part of a broader project to collaborate on some topics. I read through it and have some suggestions on how to improve it. I had not had time before to read it, so some of the suggestions come from a fresh reader that saw the text for the first time. We do mention it already in our BGP and routing security training course (https://www.ripe.net/support/training/courses/bgp), and I'm sure we are going to add more details as the document will be officially published. I really think we needed something like this, and I'm sure we are going to add it to the material we distribute with our BGP and routing security training course, as it perfectly rounds what we teach there in a nice and concise way, good for both newcomers and experts. So, here are some suggestions for improvements: - Section 4.1.1.2, second paragraph: I would change from the second sentence with "The advantage of using a ROLE object is that, while people can change jobs and move to a different organisation, a department or role does not change. A ROLE object can, in fact, optionally refer to other PERSON objects, adding information about contact persons for a specific group or department"; - In the following example, I would add some admin-c and tech-c attributes as examples, with a description of what they do and the differences between them; - On a related note, it would allow to build a whole chain with the following example of inet6num. After that, then I would take a paragraph to discuss the relationships with all the objects, then (I mean the chain between person-->role-->inet6num, and their roles with abuse handling as well); - The second paragraph after the inet6num example is no more correct. The database recently changed so that every LIR has its own maintainer set also for allocations, together with RIPE-NCC-HM-MNT. This means that changes can be made to an allocation inet{,6}num directly into the database. Business rules are going to restrict what you - as an LIR - can change, though; - Section 4.1.5: At the end of the first paragraph there's a double "and"; - Same section, at point 2-C, I think the sentence needs to be finished. I think we're missing "the ASN in the database", but I could be wrong here; - Section 4.2: At the first bullet point, I would add a semicolon instead of a full stop; - I would change the second paragraph in the same section to something like this: "Routing information should be made available on a global scale to facilitate validation. This includes routing policy, ASNs and prefix that are intended to be advertised to third parties. Since the extent of the internet is global, information should be made public and published in a well known place using a common format." - I would also change the following paragraph to something like this: "MANRS participants should maintain public information updated in order to facilitate the validation of routing information. This includes the following data:" - I would change the first paragraph in section 4.2.1 to something like this: "The goal of Origin validation is to verify that the rightmost - also called the originator - ASN in an AS_PATH is correct. This can be verified by correlating address space (or prefixes) and ASNs. To facilitate this, all MANRS participants should make these information available publicly in database such as the IRRs. They should also encourage their IP transit customers to do the same for their own address space."; - Section 4.2.1.2: In the first paragraph, I would suggest we say "The RPKI repository can store information about prefixes originated by your network in _the_ form of ..."; - Section 4.2.1.2.3: I would eliminate the first "of" in the first sentence; - In the same paragraph, last sentence, I would change the sentence like this: "... or customers that received address their address space as an assignment from their provider, ..."; - In the following paragraph: "Establish a process that ensures that every time you originate _a_ new prefix from your network, ..." and "This should become a a normal process integrated in your NOCs procedures" as last sentence; - In section 4.2.2.1, I would put an example of an AS-SET. This is not discussed anywhere, so I would also be happy to provide some info if we decide it's worth to have it there; - After the routing policy example, I would change the wording in the first paragraph to this: "as-set and other object sets derived from _an_ AS Policy documentation and then..."; - In the following paragraph, I would change the first "can" with "could"; - Section 4.3, 3rd paragraph: I would the wording into this: "Since 2005, deployment of anti-spoofing techniques _has_ not been a limitation ..."; - I would change the beginning of the following paragraph into this: "Ironically, significant DoS amplification attacks can be expensive for Service Providers."; - In paragraph 5, I would change "... there are no benefits to a service provider ..." into "... there are no benefits for a service provider ..."; - In paragraph 6: "These methods can ease the overhead of administration in cases where routing and topology _are_ relatively dynamic."; - In section 4.3.2, I think we should add a description of how feasible path works, even if we decide to keep it small and concise; - I noticed we should make the use of ASN or ASes consistent accross the document. It's spelled in different ways all over. This is something for the final review, though; - Section 4.4, second bullet point: I would change "their" into "its"; - Section 4.4, 5th paragraph: "... provided by the customer about their identity and resources _are_ correct"; - Section 4.4, 7th paragraph: " ... or fully validated _against_ the entire ordered set ..."; - Section 4.4, between the two example datasets: "And similar objects for their _other_ customer, AS64502"; - Section 4.4.1.2.1, last paragraph: "As you can see _in_ the IPv6 example ..."; - Section 4.4.1.2.2, first paragraph: "IRRPT generates prefix-lists just _like_ bgpq3 ..."; - Section 4.4.1.4, Delta checks: "Ensure that if a filter changes _by_ a delta ..."; - Section 4.4.2.1: Remove "it" from the first sentence; - Section 4.4.3, first paragraph: "For these purposes, a path is considered valid if it _is_ consistent with ..."; Sorry if this email looks pedantic, but I wanted to make sure we make a great document that can be used and distributed as much as possible, and so far we're on the right track! :) I'm available for any comment or to discuss any of my suggestions. Ciao! -- Massimiliano Stucchi RIPE NCC mstucchi@ripe.net Follow us on Twitter for the fastest and latest RIPE NCC Training news! @TrainingRIPENCC