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

Hay,

On Tue, Aug 26, 2003 at 12:57:13PM +0200, Dominic Spratley wrote:
> Hi Christian, Sascha,
> 
> You both made several points and I hope I can explain our thinking on them
> for you. We think these new forms represent a change in the way we provide
> services to LIRs so we've addressed this answer to the NCC Services WG list.
> We don't think they represent a change to the RIPE community's policy.
> 
> This new set of forms is intended to reduce the burden on both the LIRs and
> the RIPE NCC. By reducing the administrative burden we hope to allow LIRs to
> access our services faster and improve the level of service we are able to
> offer.
[...]

of course.
I want to apologize that noone noticed the _good_ changes but only the
apparently "bad" ones.Though such things happen if you change something 
without discussing it BEFORE.

I like those parts of the new form(s). Some silly or at least outdated
questions have been removed, the complicated part of the Current Address
Space Usage was reduced to a simple question ect. 
No doubt, that helps.

> We introduced a template asking about the equipment being used by the End
> User to help us understand requests faster. We often received requests for
> fairly large amounts of address space for vaguely described "network
> devices" or "LAN segments". The information provided was not sufficient for
> us to evaluate the request. As such the Hostmaster would need to ask the LIR
> for additional information. This would delay the request. We hope that the
> introduction of this new template will help us evaluate requests more
> quickly and improve the level of service we offer you. It is possible to put
> "N/A" in the equipment template fields but the Hostmaster might need that
> information to understand your request and ask you to supply it. This would
> delay things for you.

That's the only thing I wanted to hear, because it's not that clear in
the supporting notes.
So the information is OPTIONAL, one CAN provide it IF AVAILABLE and one 
can speed up a request by doing so.
But it is not a REQUIREMENT if the rest of the request or the 
additional text information is clear enough.

> We understand that it may not always be possible to include useful
> information in this template. However, we believe that the template will
> have a broadly positive effect on the level of service we can offer.

Fine for me after this explaination.
Probably the supporting notes should be more clear about that though.

And if a customer explicitely denies detailed information about
his equipment or network being revealed to RIPE, this must not be a
reason for denying an Assignment either.
And yes, such customers exist.

> You asked about the requirement for a network diagram to be supplied when
> requesting an IPv6 allocation. There are two reasons for this. Firstly, the
[...]

I'm going to answer this one seperately.

> Finally, we agree with you that many LIRs are not aware of the difference
> between PA and PI address space. This is unfortunate and has several roots:
> many LIRs have a large number of staff that change regularly. Also, many
> people find the difference between PA and PI rather arcane and difficult to
> understand. We try to address the former issue through LIR Training Courses
> and by making policy documents clearer to read. We've made updates to all
> the RIPE community's policy documents over the last few months. The IPv4
> policy has been updated and a draft of the revised text is available for
> review by the community, now. It can be found at:
> 
> <http://www.ripe.net/ripe/draft-documents/ipv4-policies.html>
> 
> We have also taken a look at the wording used to distinguish between PA and
> PI. We would like to make the distinction more apparent to the untrained
> eye. We have published initial proposals on changes to the status attribute
> value names and are co-ordinating with APNIC on this work. We hope to make
> it easier for everyone to understand the status of address space.

I don't think changing words does help much here. "untrained eyes"
without any knowledge about what they do don't understand the 
differences better just by using different terms.
(Actually the new words do confuse a "trained eye" in this draft :-)

More focus on having the LIRs train their staff better would be 
of more success in general in my eyes. 

[...rant about unassigned but used IP-Ranges and noone doing anything
 about it deleted...wrong place, wrong time...]

> There are also a few advantages to the new forms that may not be apparent
> from the customer perspective but remain very important. Because the
> syntax-checking software at the RIPE NCC has been replaced the forms can be
> changed and updated more easily in the future. This means we can be more
> responsive to your needs than in the past.
> Also, providing services via the LIR Portal will let us improve the request
> process to make it easier and faster in the future.
> Thank you for your insights into these new forms. We are keen to get
> reactions from LIRs so that we can continue to improve and update them and
> the services we provide - both e-mail and web versions.

Well, i just submitted my first ripe-283 (manually, the Web-
thing didn't work right and resulted in an error after the "Address space
returned?" page...), let's see what happens. 

The first thing i noticed is, the CIDR notation in the Address Space
Usage section...sounds like a nice idea, but turns out being a bit messy.
Especially if you need to count the totals manually.
No fun, one can get blind from that :)

I don't know how the LIR-portal thing handles it (most likely 
does the maths job?), but otherwise a small Tool for 
"addition of CIDR ranges" would be nice, not everyone got something
like that at hand i think.

So far, thanks for the clarifying answers.

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