[arin-ppml] Advisory Council seeks additional commentary on PP-158

[William Herrin]

On Sun, Nov 13, 2011 at 2:58 AM, Owen DeLong <owen at delong.com> wrote:
> Frankly, this sets off my "extreme corner case" detector,

Hi Owen,

Yes, that's the idea. In any ROBUST engineering activity you have to
find where the boundary cases lie and beware of them lest you create a
Tacoma Narrows Bridge or a Boston Plywood Palace. Something as simple
as missing the threat from heavier than normal snow can lead to a
Dulles Jet Center collapse with an impact in the hundreds of millions
of dollars.

A process doesn't necessarily have to perform at the boundary cases,
but it's usually important that it fail gracefully. Until you know
where the boundary cases are, it's impossible to even assess how the
process performs as it approaches those cases, let alone verify
graceful failure.

When it works well, designing game scenarios as I described leads to
the identification of the corner cases an ARIN policy author should
watch out for in his draft. What one does about the corner cases is
often a matter of reasonable debate but drafting without identifying
or assessing the corner cases yields faulty policy more often than
not.



> This particular policy wouldn't deal with it until the applicant came for
> more addresses. It would also depend on what is meant by your
> term administratively distinct. For example, if it were spun off
> into a separate organization or other wise transferred to a different
> organization through a section 8 process, then, the remaining 7
> would likely still qualify as discrete networks.

Scenario: IT services runs a corporate LAN. Software services runs a
separate developer's network with an entirely different security
posture. The grocery home delivery product team runs a complex network
independent of IT, etc. These networks in the same building don't
touch and all deal with Internet vendors separately until someone gets
the bright idea to buy a smaller number of larger Internet lines and
share.


> In the case where they remain part of the original ORG, the
> alleged administrative distinction is not relevant to ARIN and
> they would still be a single org. Since they now share a common
> routing policy (everything through the one network) as far as the
> outside world is concerned, I would say they are no longer
> discrete networks in the meaning of the policy.

As would I. My concern is that it's fairly easy for a large contractor
not specifically focused on Internet services to fall in to the
pattern above. The best minds get sucked out of central IT by the
revenue-producing product teams resulting in a central IT incapable of
supporting the products' needs. So the networking activity fractures.
Eventually someone in central IT grows a brain but by then the
addressing is inaggregable with a substantial cost not to the company
itself but to the rest of the world.


> 2.      It really is a very bizarre scenario in that particular network
>        in which case it would occur so infrequently as to be irrelevant
>        in evaluating policy efficacy.

Such fractured networking is a very popular error. Sophistication
among such subnetworks' operators sufficient to interact with ARIN for
addresses is much less popular but as nines of reliability enter the
product managers' lexicon it's becoming more so.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004