Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal

[Sascha Lenz <]

Hay,

On Thu, Aug 21, 2003 at 04:02:16PM +0200, Dominic Spratley wrote:
> Hi Daniel,
> 
> I hope I can clarify some of your points below:

actually i didn't really want to get into this discussion, but
it looks like _noone_ else has anything to say about the issues Daniel
raised?
Than can't be since he is right in most points.

> At 03:37 AM 8/21/2003 +0200, Daniel Roesen wrote:
[...]

most points have been more-or-less clearified by Dominic's answer, but: 

> >- [EQUIPMENT DESCRIPTION]
> >
> >     This requirement _can't_ be meant serious. We're not on April 1st,
> >     are we? The silliness of such information requirement was already
> >     recognized within the IPv6 allocation realm, so why introducing it
> >     now again for IPv4?
> 
> This is a difficult one as it does require the LIR to do more preparation on
> their side.   The less time a Hostmaster spends sending E-mails asking
> for additional information, the sooner the LIR gets their requested resource.
> Asking for the type of equipment used really helps the Hostmaster
> understand what and why IP addresses are being requested.

... i still have a problem here if that should be a "must provide
this information".

I have no much problems with questions like "why-pi" or "routing-reasons"
because they can obviously be answered with standard phrases
(which renders them useless again, but if RIPE NCC sees that many 
"bad" requests from many LIRs (aren't they trained?), it's OK for me,
no much work, no stupid questions).

BUT... information like the equipment being used or a network
plan or so _must_ be optional information, not _required_ information.
It can't be that a company is _required_ to make statements about
their network and equipment if they want to have IP-Adresses!
(and no, RIPE doesn't always qualify for receiving such information).

Besides that it's way too much work to fill that in seriously for 
big requests, and doesn't really make sense for small requests.

This should be _optional_ information in cases where it's needed
to explain an unusual request, whatever, "we have only one machine
but it has 500 IP Adresses due to this and that special purpose which
can't be handled otherwise due to these and those hardware and software
limitations".

Is it really only me who is of that opinion, or noone recognized this
problem or doesn't think it's a problem? Or isn't it meant as
_required_ information anyways and a "N/A" is enough in most cases as
answer to this part of the request? 
...curious.

The reason i noticed that this might get a problem was due to the
unholy 

[...]
#[REQUIRED INFORMATION]#
[...]
%
% 2. Please provide a network diagram in PostScript or JPEG 
% format showing your IPv6 network. Submission instructions 
% can be found in the RIPE document "Supporting Notes for the 
% Initial IPv6 Allocation Request Form in the RIPE NCC Service 
% Region" found at:
% 
% http://www.ripe.net/ripe/docs/ipv6-support-initial.html
% 
% The diagram should indicate expected completion dates of 
% construction as well as how much IPv6 address space is 
% expected to be used in each subnet.
%

%
[...]

in the (old and new) IPv6 Initial Allocation request form.

Since it says "required information" there, i already assumed
that it might get a problem to get the IPv6 Allocation for us 
without providing this one.
But i didn't see the point in doing so if i can make our network
plans clear in text form, and explain the reasons why a
network diagram for an IPv6 network is _completely_useless_
in general at the moment and especially in our case.

Though, even on my 2nd mail on that request i just got the reply from
some RIPE Hostmistress that "the inability to provide this
network topology map calls into question the need for the IPv6
addresses being requested.".

At the moment i'm really mad about this.
We are currently prevented from deploying IPv6 addresses immediately
because i don't have any Windows PC with Viso or something at
hand, let alone the time to paint a very useless topology of
our IPv6 overlay network, though i explained it in detail in
text.
(Not to mention that the statement that an active LIR which assigns
IPv4 addresses for years is questioned that it will assign
IPv6 addresses just because it doesn't like to waste time 
on painting network maps of some routers and tunnels  
is VERY doubiously to me.)

Why the hell is such information _required_? 
Information about what equipment being used and a network 
topology map on a picture might be additional information at best.

I fear that IP(v4) request will be denied or at least delayed in
future if the RIPE Hostmasters are gonna complain about missing
or unsatisfying information about the equipment in the future, too.

That's not acceptable i think. 
But i might be wrong, we're realatively small and don't have 
that many requests in general, i just wonder why noone of the
"big LIRs" sees this problem? You all have AWs that big that
you don't care about filling in RIPE forms anyways and have payed
managers to paint network diagrams all day? *hint* :)

> >Further, the term "peer" is used in a very unclear way in the ASN
> >request form and the supporting notes.
> >
> >Formerly, one uplink and one peer (commercial term) were enough to
> >justify an ASN, as this constitutes a "unique routing policy". The
> >ASN request form allows this interpretation of "peering partners"
> >with "peering" in the technical sense. BUT the supporting notes
> >specifically mention the requirement for two peers to "ensure that the
> >organisation is multihomed". For me, multihoming means to have at least
> >two _upstreams_. This would be a more stricter policy than before.
> >What was the real intention behind these phrases? These documents
> >should be very specific in the usage of "peer". It might be interpreted
> >technically or commercially, each implying different constraints.
> >I suggest changing the wording from "peer" to "upstream" in order to
> >avoid ambiguities.
> 
> Again this is a good point.   However I don't think that either term is
> appropriate for all situations.  When writing these documents we used
> the word peer as we wanted to emphasise it was the routing policy which
> was important.

So, the policy didn't change to "you have to have two _upstreams_ to
get an ASN" but it's only a language-confusion here?

P.S.: I think this discussion belongs to the address-policy-wg, not
      ncc-services-wg?  Sorry for crossposting, remove the latter
      in any replies if i'm right.

-- 
==========================================================================
= Sascha 'master' Lenz          SLZ-RIPE           slz@localhost         =
= NOC BayCIX GmbH                                                        =
= http://www.noc.baycix.de/                * PGP public Key on demand *  =
==========================================================================