- lir-wg - mailman.ripe.net

IPMT specification rough draft
by Manuel Valente 01 May '01

01 May '01

Hi, Following a presentation by Guy Vegoda at the Tools BOF at RIPE37 of an IP Management Tool, interest was expressed in the development of an Open Source version of such a tool and we used the lirwg list to draw up Requirements for this. We have now produced some rough specifications for this tool that we will present at the upcoming Tools WG tomorrow. We will target as users 'The Hostmaster staff of Local Internet Registries which are Customers of the RIPE NCC and who need to manage their IP Allocations and Assignments and the requests for same that they send to the RIPE NCC'. We would now like the help of such potential users to refine these specifications into something that the RIPE NCC and interested developers can go away and implement. So, if you're interested by such a tool, please come along to the RIPE39 Tools WG tomorrow at 16h00 in the Europa Auditorium. Thanks. -- Manuel Valente - Software Manager - RIPE NCC ------------------------------------------------------------------ Draft of Specifications for an IP Management Tool Manuel Valente, Leo Vegoda, Maldwyn Morris RIPE NCC swcontact(a)ripe.net 20010419 0. Introduction Following a presentation of an IP Management Tool by Guy Vegoda at the Tools BOF at RIPE 38 [1], interest was expressed in the development of an Open Source version of such a tool and we drew up Requirements (qv) 1. General Points Open Source: We will release this software under the LGPL licence [2]. We use this instead of GPL [3] because this means we will remain able to using non-GPL'ed libraries, should that prove necessary. The RIPE NCC is happy to support this project, but of course its Open Source nature means anyone else can use the code to begin their own Open Source project. We are also happy about that. IPV6: We would be foolish not to consider the possibility of using this tool for managing IPV6 addresses and writing it such that this is possible, but we think it will be useful even if it does not and do not consider IPV6 support a requirement. 2. Definitions: Parties : RIPE NCC: The European Regional Internet Registry, which grants IPV4 address allocations to its customers, the LIRs. LIR: A customer of the RIPE NCC which interracts with the RIPE NCC in order to make IPV4 address assignments to their LIRCustomers from the LIR's IPV4 address allocation. LIR Customer: A person or organisation which wants to receive IPV4 address assignments. LIR Hostmaster: A person working for a LIR whose job it is to make IPV4 address assignments to the LIR Customers. Registered IPV4 Address Information: There are two forms of IPV4 address information which are registerd by the RIPE NCC and which are stored in the RIPE Whois Database: IPV4 Address allocations and IPV4 Address assignments. IPV4 Address allocations: A range of IPV4 addresses from which the RIPE NCC allows a certain LIR to make IPV4 Address assignments to their LIRCustomers. IPV4 Address assignments: A range of IPV4 addresses from a LIR's IPV4 Address allocations which the RIPE NCC and the LIR allows a certain LIRCustomer to use on the Internet. Interactions: I1: LIR Customer Assignment Request: An LIRCustomer asks their LIR for an IPV4 Address assignment and the LIR replies. Composed of: I1.1: LIRCustomer communicates request for IPV4 Address assignment to LIR I1.2: LIRHostmaster evaluates request I1.3: LIRHostmaster queries LIRCustomer about request I1.4: LIRHostmaster actions request I1.5: LIRHostmaster informs LIRCustomer of request outcome I1.6: LIRHostmaster completes request for LIR Customer I2: LIR Assignment Request: An LIR asks the RIPE NCC for approval of an IPV4 Address assignment and the RIPE NCC replies. I2.1: LIRHostmaster formulates query I2.2: LIRHostmaster sends request to NCC I2.3: LIRHostmaster handles response I2.4: LIRHostmaster completes request I3: LIR Allocation Request: An LIR asks the RIPE NCC for an IPV4 Address allocation and the RIPE NCC replies. I3.1: LIRHostmaster formulates query I3.2: LIRHostmaster sends request to NCC I3.3: LIRHostmaster handles response I3.4: LIRHostmaster completes request I4: LIRH Manages Customers I4.1: LIRHostmaster composes report(s) of info on one customer I4.2: LIRHostmaster composes report(s) on all customers I4.3: Creation of new customer I4.3: Update customer info I4.3: Delete customer I5: LIRH Manages LIR's Assignments I5.1: LIRHostmaster composes report of all assignments I5.2: LIRHostmaster composes report on a specific assignment I6: LIRH Manages LIR's Allocations I6.1: LIRHostmaster composes report of all allocations I6.2: LIRHostmaster composes report on a specific allocation 3. IPMT Functional Breakdown The functions the IPMT tool must provide, divided per Interaction. I1: LIR Customer Assignment Request: I1.1. LIRCustomer communicates request for IPV4 Address assignment to LIR IPMT: F1: receive the LIR Customer Assignment Request F2: store request info F3: LIR Hostmaster sees new request I1.2 LIRHostmaster evaluates request IPMT: F4: Check request correctly formatted and I1.5: Deny if not F5: Check request valid and I1.5: Deny if not F6: Check LIR Customer valid and I1.5: Deny if not I1.3: LIRHostmaster queries LIRCustomer about request IPMT: F7: Get more info from LIR Customer regarding request F8: update request info F9: -> I1.2: Evaluate I1.4: LIRHostmaster actions request F11: Need to ask RIPE to perform request ? -> I2 if so F12: Check request F13: Update request info F14: Check other info concerning assignments F15: Update other info based on request I1.5: LIRHostmaster informs LIRCustomer of request outcome F16: Communicate request outcome and info to LIR Customer I1.6: LIRHostmaster fills in customer request F17: Generate info about request, possible with F7 4. Implementation proposals ?? LIR Hostmaster interracts with IPMT via a GUI. ?? IPMT GUI will have HTML form range of elements ( text, buttons, single-line text, multi-line text, radio buttons, check boxes ). I1.1 LIRCustomer communicates request for IPV4 Address assignment to LIR F1: receive the LIR Customer Assignment Request ?? LIR Customer sends request : - via html form - by snailmail/phone/other & LIRH fills in a GUI form - by email to designated address - address served by mail robot ? - FORGET for now - too complex ? - LIRH uses CLI to fill in - Other LIR fills in using IPMT via API F2: store request info ?? Store in 'LIR Customer request' record in DB ?? Request record: Request id LIR Customer email address date raw request info - from LIR customer comm.s LIRH ID - 'request owner' F3: LIR Hostmaster sees new request ?? IPMT 'fetch next request' button to show next LIR Customer Request in GUI - wait queue... - IPMT perfroms F4,F5,F6 I1.2 LIRHostmaster evaluates request F4: Check request correctly formatted and I1.5: Deny or I1.6 if not IPMT parses 'LIR Customer Request' record, extracts and stores in it: LIR customer id request size in num of IP addresses request category: ?? status: ?? IPMT informs LIR Hostmaster if parse fails F5: Check request valid and I1.5: Deny or I1.6 if not ?? IPMT checks 'LIR Customer request' record ?? I1.3 if more info needed OK ?? IPMT sets 'checked' flag F6: Check LIR customer valid and I1.5: Deny or I1.6 if not IPMT looks up LIR customer info ?? LIR customer info stored in a DB ?? 'LIR customer' record LIR customer id customer email addresses and other contact info. request ids of previous requests total space size of assignments - enough info to make Whois DB person object ? IPMT informs LIR Hostmaster if customer not valid I1.3: LIRHostmaster queries LIRCustomer about request F7: Get more info from LIR customer regarding request ?? LIR Hostmaster uses IPMT to compose and send email to LIR customer ?? LIR customer reply automatically added to 'customer request' record or LIRH can use IPMT to do this ( e.g. : enter phone conversation ) ?? IPMT 'action needed' button to show customer reply received F8: update request info LIR Hostmaster updates 'customer' and 'customer request' records F9: -> I1.2: Evaluate I1.4: LIRHostmaster actions request F11: Need to ask RIPE to perform request ? -> I2 if so IPMT Check LIR Assignment window vs size of request - force insert of NCC# ticket number of approval if it's needed - need access to LIR Assignment window reports to LIR Hostmaster F12: Check request IPMT examines request record vs customer and LIR assignment and allocation records ?? assignment records - in whois ??: - or IPMT stores this locally - or LIR's records ?? via defined API ?? ipv4 range - IPMT makes _suggestion_ - allow choice of methods by config file as debatable - what methods are there ? netname - IPMT makes _suggestion_ ?? allocation records - in whois ??: - or IPMT stores this locally - or LIR's own records ?? via defined API ?? ipv4 range F13: Update request info ?? IPMT generates assignment addresses from 'customer request' record and assignment and allocation records LIR Hostmaster agrees or alters assignment addresses F14: Check other info concerning assignments - too varied so LIR to implement - IPMT provides I4,5,6 to allow LIRH access to info it has ?? LIR workflow stats ?? LIR Hostmaster stats ?? LIR infrastructure updates ?? LIR customer billing F15: Update other info based on request IPMT stores assignment addresses in 'customer request' record I1.5: LIRHostmaster informs LIRCustomer of request outcome F16: Communicate request outcome and info to customer LIR Hostmaster uses IPMT to compose and send email to customer Update 'customer request' record I2: LIR Assignment Request: An LIR asks the RIPE NCC for approval of an IPV4 Address assignment and the RIPE NCC replies. I2.1: LIRHostmaster formulates query F20: LIRH uses IPMT to produce a filled-out 141 Form. Gets data from customer, request and assignment records I2.2: LIRHostmaster sends request to NCC F21: Send request to RIPE-NCC by e-mail I2.3: LIRHostmaster handles response F22: Check response of RIPE-NCC and resent request if necessary -> repeat F20 I2.4: LIRHostmaster completes request F23: Update customer, request and assignment records. I3: LIR Allocation Request: An LIR asks the RIPE NCC for an IPV4 Address allocation and the RIPE NCC replies. I3.1: LIRHostmaster formulates query F30: Gets data from assignment and allocation records and fills out pro-forma request to RIPE-NCC. I3.2: LIRHostmaster sends request to NCC F31: Send request by e-mail. I3.3: LIRHostmaster handles response F32: Check response of RIPE-NCC and resent request if necessary -> repeat F30 I3.4: LIRHostmaster completes request F33: Update assignment and allocation records

1 0

agenda for IPv6 working group RIPE39
by David Kessens 29 Apr '01

29 Apr '01

Hi, Below follows the final version of the agenda for the ipv6 wg. The second part of our session will be used for ipv6 policy discusions. This part will be a joint session with the local-ir working group. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE39, Bologna Tuesday, May 1, 2001, 14:00-17:30 1st part 14:00-15:30 A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Securing the Mobile-IPv6 Binding Update (Tony Hain) D. 3G and IPv6 (Niall Murphy) E. IPv6 deployments at Jippii (Jan-Ahrent Czmok) F. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) 2nd part 16:00-17:30 joint session with lir-wg G. Draft on allocation sizes http://www.enigma.ie/articles/global-ipv6-alteration.html (Niall Murphy) other info: http://www.djp.net/ipv6/proposal.html http://www.ripe.net/ripe/mail-archives/ipv6-wg/20010101-20010401/msg00017.h… (Dave Pratt) H. Status of IETF/RIR allocation boundary discussions (Randy Bush/Mirjam Kuehne) Z. AOB ---

1 0

The status of the migration iissues
by Andrei Robachevsky 26 Apr '01

26 Apr '01

Dear Colleagues, As some of you might have noticed, several problems showed up after the migration. Let me present an update on their status: 1. PGP signed messages sent to <auto-rpsl(a)ripe.net> didn't pass authorization checks This was fixed on 24th of April. Please note that PGP signed updates cannot be processed by <auto-dbm(a)ripe.net>. Until 14th of May, <auto-dbm(a)ripe.net> processes updates in RIPE-181 format and automatically translates them into RPSL, which voids PGP signatures. 2. Conversion problems of updates sent to <auto-dbm(a)ripe.net> Problematic objects were: - Objects with syntax errors - Indented objects (containing leading whitespace) In both cases objects were not converted to RPSL and user received an empty acknowledgement. This was fixed today, 26th of April. Please note that <auto-dbm(a)ripe.net> cannot reproduce all the behaviour of the v2 database. In particular, empty attribute is treated as a syntax error and Routing Policy System Security authorization rules apply. We strongly recommend you to switch to updates in RPSL format as soon as possible. Also note, that <auto-dbm(a)ripe.net> will process updates in RIPE-181 format until 14th of May. After that, updates in RIPE-181 format should be sent to the new address, <auto-181(a)ripe.net>, and <auto-dbm(a)ripe.net> will accept only RPSL syntax. 3. Due to above problems some of the updates were not processed. If you haven't received an acknowledgement from the database one day after you sent your update we would kindly ask to re-send it. We apologize for any inconvenience these problems caused. We are working on some minor problems and rely on your understanding. Please visit the "Migration Issues" link on the "Database Status" page (http://www.ripe.net/ripencc/pub-services/db/issues.html) for the up-to-date information. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

3 2

Hostmaster Centre at RIPE 39
by RIPE NCC Staff 25 Apr '01

25 Apr '01

Dear all, Ripe NCC Registrations Services are pleased to announce that during the RIPE 39 Meeting in Bologna, we will open a Ripe NCC Hostmaster Centre. Ripe NCC Hostmasters will be available for any IP and ASN request questions, and also any general policy questions. A timesheet at the centre will be made available for appointments, though 'walk-in's will also be welcome. Please note the following time-table: Monday April 30. 12:30 - 14:00 Tuesday May 1. 9:00 - 17:30 Wednesday May 2. 12:30 - 14:00 & 16:00 - 17:00 Thursday May 3. 9:00 - 14:00. Friday May 4. CLOSED. (IP request Tutorial, 14.00-17.30) We look forward to meeting you. Regards, Ripe NCC Hostmasters

1 0

portable address space
by RIPE NCC Staff 25 Apr '01

25 Apr '01

Dear all, At the upcoming RIPE meeting next week, the RIPE NCC will put forward a proposal attempting to clarify current policy on independent/portable address space. We are seeking the communities input on this matter. The RIPE NCC is currently experiencing an increased demand for portable address space, clearly visible through the amount of new members signing up from a need for portable address space but also through the amount of PI (Provider Independent) address requests received at the RIPE NCC. At this time there is no clear and consistent policy on any of these types of portable address space. - PI address space is discouraged and requestors are informed of disadvantages with PI space and what possible implications there may be. However, there are no criteria for obtaining PI address space. - PA allocations can be obtained by anyone who is a member of the RIPE NCC. (The RIPE NCC membership is open.) The LIR is only required to justify the first assignment out of that address block. As all members are required to request and justify each assignment made to customers or own infrastructure, we feel that current poorly defined PA Allocation criteria create an inconsistency in policy. In practice it means that anyone justifying the need of one IP address can receive a PA allocation (currently a /20 = 4096 addresses). This has resulted in an enormous growth of new members over the last three years. Whilst ARIN has a clearly defined policy on portable address space, APNIC has experienced the same dilemma as the RIPE NCC with their similar policies on portable address space. This was brought up and discussed at the APNIC meeting in Kuala Lumpur, March 2001. (see URL below.) As demonstrated in several recent studies of the changes in the Internet over the last years, it is clear that there is an increase of multi-homing taking place globally, an increase of smaller routes being announced in the Internet and an increased need for portable address space. The RIPE NCC wishes to develop a clear and consistent policy for portable address space in a realistic and pragmatic manner that also accommodates this increased need for portable address space. We will at the upcoming lir-wg meeting present statistics showing this trend and suggest possible steps forward. We wish to request the communities input in this discussion and we look forward to a fruitful discussion. Kind regards Nurani Nimpuno Registration Services Manager RIPE NCC http://www.ripe.net REFERENCES: -------------------- Policy documentation: "European Internet Registry Policies and Procedures", section 3.4.2.PA vs PI Space http://www.ripe.net/ripe/docs/ripe-185.html#toc34 "Provider Independent versus Provider Aggregatable Address Space" http://www.ripe.net/ripe/docs/ripe-127.html APNIC policy documentation: http://www.apnic.net/docs/add-manage-policy.html ARIN policy documentation: http://www.arin.net/regserv.html Presentations and papers: "Architectural Requirements for Inter-Domain Routing in the Internet" - Geoff Huston http://www.ietf.org/internet-drafts/draft-iab-bgparch-00.txt "The State of BGP routing" http://www.telstra.net/gih/papers/ietf/ietf50-plenary.pdf "Consistent and realistic policy framework for 'Portable' allocation and assignment" - Paul Wilson http://www.apnic.net/meetings/presentations/pa-pi-criteria.ppt Global policy document: "RIR comparative Policy Overview" http://www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix-rev.h…

1 0

Proposed Agenda for Tools WG at RIPE 39
by Maldwyn Morris 25 Apr '01

25 Apr '01

Proposed Agenda for Tools WG at RIPE 39 --------------------------------------- 1. Administratrivia a. Scribe b. List of participants 2. Agenda bashing 3. Election of WG Chair Maldwyn Morris is leaving the RIPE NCC and will be stepping down as Chair of the WG, so we need to chose a new Chair. Manuel Valente, the new RIPE NCC Software Manager, will stand for the position. 4. IPMT - Manuel Valente a. Specifications We have already produced basic requirements for the IP Management Tool ( IPMT ) and would now like your assistance to flesh out the specifications - a real _working_ group ! Anyone who has used a similar tool or might use IPMT is encouraged to come along and help. b. Developers Group We would like to organise a group of people willing to help implement IPMT. 5. Tools and Techniques - Manuel Valente We would like to discuss proposed and existing tools or techniques of use to LIRs. If you have tools or ideas of your own, please bring them along. Cheers, Maldwyn Morris Software Manager RIPE NCC

1 0

IPv6 addresses for Exchange Points
by Mirjam Kuehne 24 Apr '01

24 Apr '01

[Appologies for multiple postings. I suggest to keep the discussion on <lir-wg(a)ripe.net> as it is related to address allocation policies]. Dear colleagues, The RIPE NCC received a number of requests from Internet Exchange Points (IXPs) for IPv6 address space. While evaluating these requests, we realised that it is still not entirely clear what the role of an IXP is in the IPv6 world. We also noticed that the allocation criteria currently described in the 'Provisional IPv6 Assignment and Allocation Policy Document' (http://www.ripe.net/ripe/docs/ripe-196.html) do not necessarily apply to IXPs. Please find some more details regarding this issue below. We would like to discuss this with you at the upcoming RIPE Meeting in Bologna. For more information abut the schedule, please refer to the agenda of the EIX-WG and the LIR-WG: http://www.ripe.net/ripe/meetings/current/ripe-39/ Kind Regards, Mirjam Kuehne RIPE NCC ------------ PROBLEM STATEMENT: - IXPs need independent address space for their infrastructure to allow their members/customers to connect via native IPv6 - IXPs do not necessarily fulfill the current criteria: - they do not have 40 customers (in most cases IXPs do not assign address space to their members) - if IXPs are on the 6bone, they might not have a whole pTLA, but only connect to the 6bone via another ISP - they do not need a whole subTLA (a /64 or /48, depending on the case, might be enough) POSSIBLE SOLUTIONS: 1. view IXPs as a site and assign them a /48 (or /64) directly (equivalent to IPv4 PI space) 2. require IXPs to fulfill the criteria and allocate a subTLA: - either by requiring them to get 6bone experience first - or by applying the general allocation criteria and require to connect to 3 other subTLA holders OPEN ISSUES: - what about IXPs with multiple PoPs - technical criteria for exchange points

1 0

First phase of the migration to the new RIPE Database is completed
by DB-News 23 Apr '01

23 Apr '01

Dear Colleagues, The new version of the RIPE Database is now up and running! All objects have been automatically converted to RPSL and loaded into the new version of the Database. The first phase of the migration has been successfully completed. The following mail robots accept updates to the RIPE Database: <auto-dbm(a)ripe.net> - updates are accepted in RIPE-181 format and automatically translated into RPSL. However, several restrictions apply to such updates: empty and misspelled attributes are not allowed, PGP auth is not supported. Also, RPSL authorization rules apply. <auto-rpsl(a)ripe.net> - updates are accepted in RPSL format. This setup will be in place till 14 May, 2001. For more information about the migration please visit http://www.ripe.net/ripencc/pub-services/db/rpsl/announcement.html and http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html Best Regards, Andrei Robachevsky DB Group RIPE NCC

4 4

Migration of the TEST database is completed
by Andrei Robachevsky 20 Apr '01

20 Apr '01

Dear Colleagues, The TEST database has been successfully migrated to v3 software. All objects in the TEST database were converted to RPSL compliant format. You can continue using the TEST database till 14 May as follows: - <test-dbm(a)ripe.net> mail robot accepts updates in RIPE-181 format with some limitations. - <test-rpsl(a)ripe.net> mail robot accepts updates in RPSL format. After that day changes in robots' functionality will follow the plan fro the production database. Please see http://www/ripencc/pub-services/db/rpsl/announcement.html and http://www/ripencc/pub-services/db/rpsl/index.html for more information. Finding objects in the TEST Database: Do whois -h test-whois.ripe.net <Search String> e.g. whois -h test-whois.ripe.net PB3-TEST The whois options that work in the RIPE Database also work in the TEST Database. We invite you to try them. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Re: IP Management Tool - Minimum Requirements
by Guy Vegoda 20 Apr '01

20 Apr '01

> Our internal solution does: > > -> assigns subnets out of internal 'allocations' to help aggregation. > The LIR allocations and internal 'allocations' form a tree down to > the most specific assignments. I think that this comes under designing the human viewable data structures to store information about the IP address space itself. I think what you have done is a good idea, though. As Nigel Titley pointed this out to me originally, IP lends itself very nicely to a binary tree of largest free blocks. Lets design the data structure available to the hostmaster. > -> validation against 'overlapping' assignments and assignments out > of 'less specific' allocation bounds. We definately need overlap detection. > -> 'allocation pools' for flexible assignments in cases where addresses > for a single site are not aggregated into a single block. This comes under designing the data structures, I think. > -> searching of unassigned space using a combined exact-fit/first-fit > strategy. Please expand on this. I don't want an end product that decides for you which subnet you will be assigning. That will be useful for people who need to migrate already used ranges of IP address space into the tool (ie everyone). QIP 4 does this, which is another reason why IMHO, it's totally useless. (My views do not represent anybody that Lucent can sue). > -> heuristic net_name generation I think that this is a lovely touch, but it doesn't come into the "minimal requirements" umbrella. > -> quick overview of allocation tree, also showing unassigned gaps. think that this will indeed be a useful feature of any data structre we decide on. > -> data is stored in a database that also stores routing and reverse > DNS information. I don't believe if IPMT is mandated to deal with DNS at all, at least in its first incarnation. > no support for IPv6 so far... IPv6 is something I'd like IPMT to eventually support. Still, this might have to get stuck on the back burner for the moment... So; A summary so far: 1) We need to check for properly formulated dotted quad format IPs: n.n.n.n/m where n >= 0; n <= 255; m >= 1; m <= 32; 2) We need to check for overlaps so that two subnets cannot overlap any space. We need to check for: (where a is frist IP in range, z is last IP in range) 0 : No overlap a1---z1 a2---z2 a1---z1 a2---z2 1 : Range 1 totally inside range 2 a1---z1 a2--------------z2 2 : Range 2 totally inside range 1 a1--------------z1 a2---z2 3 : Partial overlap a1-----z1 a2-----z2 a1-----z1 a2-----z2 4 : Perfect overlap, range 1 == range 2 a1-----z1 a2-----z2 5 : Edge overlap = someone screwed up, editing by hand a1---z1 a2---z2 a1---z1 a2---z2 ie. 10.15.20.0 -- 10.15.21.0 10.15.21.0 -- 10.15.21.255 (oops). 3) We need some kind of data structure to be defined, so that the hostmaster can access the IP space in a sensible way. I reckon this should include: o A way of seeing the IP space - what is free, what is used. o A way of dividing the IP space into sections for assigning to different areas, such as colo, dialup etc. o A sensible method of assigning free space (ie not always the next free block - think of migration). 4) We need to think about IPv6 I hope people will comment on this summary and pummel beat it into shape. Nothing worthwhile ever happened by people being polite. Thank you very much Michael for your comments. Guy -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

6 5