[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(a)ripe.net>
Reply-To: mstucchi(a)ripe.net
Organisation: RIPE NCC
To: bcop(a)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(a)ripe.net
Follow us on Twitter for the fastest and latest RIPE NCC Training news!
@TrainingRIPENCC
Hi,
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
Regards,
Andrei
