Subject: [sidr] Comments on sidr-arch-04

From: Danny McPherson <[email-masked]>
Date: Tue, 2 Dec 2008 18:12:08 -0700

Matt/Steve,
Finally find time to do a detailed review of sidr-arch-04,
some comments below.

---
High-level comments:

-
Use of the term "holder", "resource holder", "legitimate
holder", etc.. occurs throughout.  It might be useful to
make this term explicit.

-
Use of the terms "registry/registries" and "subscribers"
is loose and could use an explicit definition and some
consistency early in the document, in particular in S 2
where some ambiguities might exist.

-
S 3.1.

I quite like this section, in particular:

"These filters would prevent importation of any route in which the
origin AS of the AS-PATH attribute is not an AS that is authorized
(via a valid ROA) to originate the route. (See Section 6.3 for more
details.)"

The reference should be S 7.3, not S 6.3.

Furthermore, given this text, and all of S 7.3., and discussions on
the mailing list as of late, we should perhaps revisit this discussion
explcitly and rework this text to accommodate consensus, and see
that any consensus finds it's way into subsequent documents (e.g.,
the ROA validation I-D).

-
Perhaps it'd be useful throughout to replace "portable" with
PI and PA, and then expand upon PA w/multi-homed from there?
Introducing the term portable may not necessarily mean PI, of
course.  S 7.2.3. attempts to talk about this briefly.

-
Option 1 in 7.2.2 seems untenable to me.  If the "susbcriber"
isn't willing to deal with getting their own AS, then it is
quite certain they'll not want to bother with getting a CA,
creating ROAs, etc..  Either way, in both examples, it's most
likely to be handled via proxy functions by one of the ISPs
involved.  It may be worth noting here that inconsistent AS
origins are generally considered undesirable on the global
Internet, for this, and other reasons.

On that, I wonder if any more text needs to be added regarding
issues with "proxy" handling by ISPs in scenarios such as this,
or do you believe we're covered fully with the existing
framework?

Furthermore, on 3/2007 Iljitsch pointed out that there is very
little discussion of a case where "customer M" announces a subset
of ISP 1s address block to ISP 1 and ISP 2 and you agreed to add
some text around this.  I don't see it either.

-
IANA Considerations surely should include some guidance to
IANA about investigation and preparation for anything that might
be required WRT serving as a TA.  Also, for legacy space, etc..

In general, I like to see more description and discussion of the
TA model here, as others (e.g., Roque on 11/17/08) and previous
discussions seem to support as well.

---
Editorial comments:

-
You'll need to update to the 4748 boilerplate in the next
revision, as you likely know.

-
sidr-res-certs-14 reference can be updated to -15 now.

-
S 2.

s/block of IP address/block of IP address/
s/knowledge the/knowledge of the/
s/IP address is hierarchic/IP addresses is hierarchic/
s/National Internet Registries and (NIRs)/National Internet Registries  
(NIRs), as/
s/regional or national registries/RIRs or NIRs/

-
S 2.1.

The acronymn 'CA' is introduced for the first time, might
be good to expand it in it's first use in an architecture
document.

-
S 2.2.

Graf 1 Ref to 6.2.2 should be 7.2.2.

s/internet registry or/RIR or/

-
S 2.5.

What would "in an out-of band fashion" entail in practice?

s/material provide to/material to/

-
S 3.

The tail end of this reads a bit odd:

"A Route Origination Authorization (ROA) makes such authorization
explicit, allowing a holder of address space to create an object
that explicitly and verifiably asserts that an AS is authorized
originate routes to prefixes."

Perhaps replace "to prefixes" with "for a given set of prefixes"?

-
S 3.1.

Graf 2 ref should be S 7.3, not S 6.3.

-
S 3.2.

s/time that is quite low/that time is quite low/

-
S 4.

s/The use access controls/The use of access controls/

-
S 4.2.

s/each registry/each RIR/ ?
s/Registries are encouraged/RIRs are encouraged/ ?
s/encouraged maintain/encouraged to maintain/

-
S 6.

Graf 1 ref should be 7.3, not 6.3.

Should't step 3 also saying something about missing data as
well, as S 7.3. does for ROAs?

-
S 7.

I'm not sure first-hop AS is unambiguous.  Why not be explicit
and say "origin AS" here?

-
S 7.1.

Graf 1 ref should be 7.2.2., not 6.2.2.

Graf 3 perhaps s/effected by/accomplished by/ ?

s/SHOULD NOT to/SHOULD NOT/

-
S 7.2.1.

s/certificates its own/certificates from its own/

-
S 7.2.2.

s/originate routers/originate routes/
s/encompassing prefix/encompassing aggregate/ ?

-
S 7.2.3.

s/regional or national registry/RIR or NIR/

-
7.3.

This entire section needs reworked, IMO.  Perhaps it should
just be removed and handled elsewhere, e.g., the ROA validation
draft?

I particularly do not like this text, which seemed to be bolted
onto the end, clearly as an afterthought:

"(and thus the filter described below which naively rejects all
UPDATES without a corresponding ROA would incorrectly reject valid
routes originated by ISPs that do not yet implement this
architecture)."

-
S 8.

s/database servers/database servers./

-
S 10.

s/Time/Tim/

-
S 11.1.

You should all those shold be Normative references, I wouldn't
think so.

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr