September 2003 - ncc-services-wg

Re: [ncc-services-wg] Re: dnsmon / .org
by Andreas Bäß/Denic 10 Sep '03

10 Sep '03

Daniel, > However it is very difficult to do it for some for free and > ask the others to pay. So doing that may lead to a situation where the > RIPE NCC membership ends up paying the whole bill. I would actually > like that because it makes the measurements even more independent > and I would not have to invest time into making agreements with the TLD > admins, billing, etc. pp. from our (DENIC) point of view an independant professional monitoring of our services has value and we certainly will pay a fair share to continue this service. Monitoring other parties that are not able to pay for that (maybe unwanted) service is nonetheless of value for us too, as we are often contacted to explain anomalies or to make judgements on explanations/justifications where independant monitoring is better than believe/rumors ;-) > But is this acceptable to the RIPE NCC memebrship in the long run? I think the system has enough options to provide to those who pay more and better service (realtime vs. delayed data access, access to single monitor point data vs. only overview, breakdown so single minute measurements vs. 15 minutes overviews or just events, maybe complex alarming conditions). Have a nice day Andreas

1 0

Re: [dns-wg] Re: dnsmon / .org
by Marcel Schneider 10 Sep '03

10 Sep '03

On Wednesday, 10 Sep 2003, Daniel Karrenberg writes: Daniel > While we so far have only monitored TLDs with whome we have some contact, > we can certainly also monitor any TLD if there is an expressed interest > from the RIPE community. Thechnically this is no problem at all. > Configuring it takes all of 5 minutes and even the alpha version > of the analysis web site on the development server box can easily take > the load. Here the views of a (small) ccTLD (CH): 1. Monitoring TLD name servers from different points on earth in a, let's say 'standardized' way, and publish such data is welcome. The points to clarify here are: standardized and 'such', the later designating a subset of all possible measurements or everything. The standardization aspect is is IMO more interesting: we need an RFC for these measurements. 2. Since this kind of monitoring can be bought from e.g. UltraDNS, it may be wise not enter in any competition, meaning it should have a price tag. 3. If it has aprice tag, people will want to know what to get for the money, meaning an SLA is required. An SLA is a contract with technical, organizational, legal and administrative definitions. 4. It is to be determined if RIPE NCC is the appropriate org to offer such services. Good: neutral, professional, some hard- and software already in place and can be used; bad: not really RIPE's core business, the competition with commercial firms. How about a RIPE-spin-off, Netlabs, etc. ? Summary: desirable service, still much to be defined. Marcel

1 0

RE: [ncc-services-wg] Re: dnsmon / .org
by Mike Norris 10 Sep '03

10 Sep '03

> I have had a number of questions like Joerg's already for all gTLDs > besides .MIL. I see little chance that we can get them all to agree to > pay a share of the cost. I also see that the overhead of making > agreements with some of the organisations involoved can be prohibitive. > If there is interest from the RIPE community it is easy to monitor these > domains. However it is very difficult to do it for some for free and > ask the others to pay. So doing that may lead to a situation where the > RIPE NCC membership ends up paying the whole bill. I would actually > like that because it makes the measurements even more independent > and I would not have to invest time into making agreements with the TLD admins, > billing, etc. pp. I agree; if people want accuracy and integrity, the measurements have to be taken independently. Mike Norris

1 0

Re: [ncc-services-wg] RIPE tasks
by Michael.Dillon＠radianz.com 10 Sep '03

10 Sep '03

>> Indeed the board has been exploring how to allow as many members as possible >> to vote. I am afraid our legal counsel advised us that electronic voting is >> not legal in the Netherlands, and the current proxy mechanism is the only viable >> form. >- In Norway public votes on important questions (like joining the EU or >not) does not have a legal foundation - they are only advisory to the >parlament. This type of an advisory voting process is often called polling or "opinion polling". Imagine the following scenario. 1. RIPE NCC publishes an omnibus plan that will be voted on at the AGM. This plan is composed of several distinct items that have been grouped together for the single approval vote. 2. RIPE NCC sets up a website which allows registered RIPE members to express their opinion of each of the distinct elements of the omnibus plan. Because this is an electronic opinion poll, the choices are more than simply yes or no. Probably it would be best to have 5 choices (Strongly Disagree, Disagree, Don't Care, Agree, Strongly Agree). And because it is an opinion poll, each registered RIPE member can change their entries any time up to the day before the AGM. 3. The day before the AGM, RIPE NCC compiles the results of the opinion poll into a short simple graphical presentation. 4. At the AGM, the poll results are presented early in the agenda as an information only item with no discussion. There should be at least an hour between the presentation of poll results and the vote on the omnibus plan to ensure that people do not confuse the two items. They are separate things. This accomplishes two things. First, it gives people an opportunity to express their opinions on planned actions and to see the opinions of other RIPE members. It isn't as detailed as the KPMG study, but it is better than nothing at all. Secondly, this satisfies the request for electronic/Internet participation in the decision-making process and should be acceptable under Netherlands law. It will also show how much real demand there is for member participation because if members don't use the opinion polling system then they really don't care what RIPE NCC does with their money. --Michael Dillon

1 0

summary of organisation object discussions
by Engin Gunduz 08 Sep '03

08 Sep '03

Dear Colleagues, [apologies for duplicate messages, and for having misspelled ncc-services-wg(a)ripe.net in the previous posting] I'd like to summarise the discussions took place in the last two weeks in the working group mailing lists after the publication of the organisation object proposal ( http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00159.html ) and after the presentation in the DB-WG session last week in RIPE 46 Meeting ( http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-organisat… ). 1. "org:" attribute mandatory or optional in aut-num objects? The proposal mentioned above specified "org:" attribute in aut-num objects to be mandatory. However, often LIRs request an ASN for their customers and the RIPE NCC does not have enough information for them to fill in an organisation object completely. Rather than putting invalid information on the whois database, the RIPE NCC thinks it is better to make "org:" attribute optional in aut-nums. 2. "org:" attribute multi- or single-valued? The proposal specified "org:" attribute single-valued in all objects. During the discussions in the DB WG, commentors from the audience stated that in some cases a person object works for more than one companies, thus one might want to put multiple "org:" attributes in his/her person object. Similar reasoning could apply to other object types as well. However, the "org:" object specifies the holder of an Internet resource in inetnum, inet6num and aut-num objects, thus it must be single-valued in these objects. For the rest of the objects, we propose to modify the rule so it can be multi-valued. 3. addition of "mnt-ref:" attribute. The proposal suggested the use of "mnt-by:" attribute for both authorisation of modification of the organisation object and the authorisation of adding a reference to the organisation object from other objects. This has a shortcoming when the organisation object is protected by an entity other than the organisation itself (for example, an LIR, whose organisation object is protected by the RIPE NCC). We would propose to introduce mandatory "mnt-ref:" attribute to control the references to the organisation object, while "mnt-by:" protects the organisation object itself, as usual. 4. "org:" attribute in the organisation object itself. The proposal suggested the use of "org:" attribute in non-organisation objects. I think it could be used in organisation objects as well, to indicate business relations like being a dependent company to another one. 5. "business-id:" attribute. It was suggested to add an attribute to specify the national organisation number or VAT number or a similar ID of the organisation. While we see the point in this, we feel it needs some more discussion. It can be added to the organisation object after its introduction. 6. changing the meaning of '-r' flag. The proposal suggested that, when a query returns an object with an "org:" attribute, the organisation objects mentioned in this attribute be appended to the query results. This behaviour can be changed by using '-r' flag in the query. This idea was based on the fact that the "org:" attribute is at least as relevant to the resource as the "admin-c:", "tech-c:" and "zone-c:" attributes as contact information. Thus, if we return person/role objects mentioned in the query results, we should also return the organisation objects. Basically, the proposed behaviour maintains the consistency. During the discussions it was proposed to change the default behaviour of whois server, and change the meaning of '-r' flag, so that - the server does not 'expand' "admin-c:", "tech-c:" and "zone-c:" attributes, nor "org:" attribute by default, - and it expands them only when '-r' flag is used. This can separately be discussed, however, I think this is out of the scope of organisation object. I hope I did not miss any other issues. If these points are OK, we will prepare another proposal for organisation object and publish it. Best regards, -- Engin Gunduz RIPE NCC Database Group

1 0

Re: [ncc-services-wg] dnsmon - why?
by Henk Uijterwaal (RIPE-NCC) 05 Sep '03

05 Sep '03

Hank, > Continuing in my previous view of examining RIPE services and alternatives > that are available: > > At the RIPE meeting, I saw http://dnsmon.ripe.net. > > How is this different than: > http://www.caida.org/cgi-bin/dns_perf/main.pl and > http://www.cymru.com/DNS/dns.html First of all, the main difference is that dnsmon monitors root server and ccTLD server performance from approximately 60 different locations all over the world. The two projects you mention, only monitor performance from 1 or a few points (3 or 4, all in the Western US), in the world. With one measurement point, it is impossible to determine if any problem is caused near the measurement point, somewhere in between or near the root server. With 60 measurement points, one can easily determine if a non-responding root server is caused by problems near the monitoring point, the intermediate networks or near the root server. The measurements done around the time of the slammer worm confirm this. There is also the issue of support. One of the project you mention, is done by a University professor in his spare time, with very little funding, lots of other obligations and no guarantee that the project can continue for any time in the future. OTOH, members of the DN* WG have indicated interest in a service that monitors their services 24/7 on a professional basis. The RIPE NCC already has staff and a highly automated system, to maintain a measurement infrastructure. Adding dnsmon to their tasks, involves very little additional work or other resources. Related to this, several TLD's are prepared to provide a 'substantial share' of the costs because publishing the data by the NCC is in their interest as well as in the interest of the RIPE community. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)

1 0

The New "organisation object" Proposal
by DB-News 03 Sep '03

03 Sep '03

Dear Colleagues, [apologies for duplicate messages] Following discussions at the RIPE NCC about a new Whois Database object, the organisation object, we have modified the previous proposal that you can find at: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00013.html The main changes from the previous proposal are: - a "country:" attribute is added. - "org-type:" and "org-name:" attributes are added, and "organisation:" attribute is now a NIC handle, which will be automatically assigned during the creation of the object. The motivation for this is explained in Section 3 of the proposal. - Hierarchical names can be removed, mainly for simplicity. - Differing query results on the whois server introduced in section 5. According to this, the relevant organisation objects are appended to the query results (because the organisation that holds the resource is at least as important as the person/role objects mentioned in the resource object). Please let us know your comments and concerns about the new proposal attached to this mail. Thanks for your time and best regards, -- Engin Gunduz RIPE NCC Database Group An organisation object in the RIPE Database -------------------------------------------- 1. Motivation ------------------- Currently the RIPE Database stores two main types of contact information: person and role objects. The person and role objects provide a way to contact people responsible for operations or usage of the resources represented in the RIPE Database (IP blocks, autonomous systems, and domain names). However, none of these provide an easy way of mapping resources to a particular organisation. A user must first find an object containing contact information for that organisation. Then, assuming all of the organisation's objects refer to this contact information, the user must perform an inverse query to obtain a list of objects referencing the specified person or role. This indirect process can be somewhat obscure and therefore a request for a more direct way of attaching an object to an organisation is seen as a useful addition to the RIPE Database. This document is a proposal for an organisation object in the RIPE Database and the necessary database functionality. 2. The organisation object ----------------------- The organisation object provides information identifying an organisation such as a company, charity or university, that is a holder of a network resource whose data is stored in the RIPE Database. The organisation object is identified by a unique ID specified in the "organisation:" attribute which is the primary key. An organisation object can be referenced from other types of objects using an "org:" attribute. All objects associated with a particular organisation can be retrieved by performing an "inverse query" for the organisation's ID (handle) used in the "org:" attribute of database objects. Following is a template for the proposed organisation object and an example. All attributes except the "ref-nfy:", "organisation:", "org-name:" and "org-type:" have their usual meanings. organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [look-up key] org-type: [mandatory] [single] [ ] descr: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 3. New attributes ---------------------- "organisation:" Specifies the ID of an organisation object. An organisation ID is made up of 'ORG-' prefix, followed by 2 to 4 letters, digits, a dash and is followed by the database source (in the RIPE Whois Database this is 'RIPE'). For example: ORG-RT34-RIPE Note that all parts are mandatory, thus ORG-RT-RIPE would be an invalid ID as it is missing the numeric part. Organisation object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. The user has to specify the ID of an organisation object as ORG-AUTO-<digit> during creation of the object, then it will be assigned an appropriate ID. The organisation ID is assigned using the "org-name:" attribute of the object. The user can specify the letter combination he/she prefers. For example if the user wants TTR as the letter combination, in the organisation ID, then ORG-AUTO-1TTR should be put into "organisation:" attribute during the creation of the object. The organisation ID cannot be reused. If an organisation ID was used in the past by an organisation object and then deleted, this ID cannot be used in new organisation objects. The auto-generation of organisation IDs and preventing reuse of them simplifies the external references. Note that when an organisation changes name, the "org-name:" can be modified accordingly. There is no need to change the organisation ID. "org-name:" Specifies the name of the organisation that this organisation object represents in the whois database. This is an ASCII-only text attribute. The restriction is because this attribute is a look-up key and the whois protocol does not allow specifying character sets in queries. The user can put the name of the organisation in non-ASCII character sets in the "descr:" attribute if required. "org-type:" Specifies the type of the organisation. The possible values are 'IANA' for Internet Assigned Numbers Authority, 'RIR' for Regional Internet Registries, 'NIR' for National Internet Registries, 'LIR' for Local Internet Registries, and 'NON-REGISTRY' for all other organisations. "ref-nfy:" Specifies the e-mail address to be notified when a reference to the organisation object is added or removed. An e-mail address as defined in RFC 2822. [This functionality is used in the "irt-nfy:". The name of this attribute is more neutral allowing reuse in other object types.] "country:" Specifies the two-letter ISO3166 country code of the country where this organisation resides. "address:" Specifies the address of the organisation. This is a free-text attribute. "org:" May be included in any other object type. It points to an existing organisation object representing the entity that holds the resource. The value of this attribute is the ID of the organisation object. It is mandatory in the aut-num objects, and inetnum and inet6num objects with "ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects. 4. Authorisation checks ---------------------------------- When modifying an organisation object the update must pass authorisation checks specified by one of the mntners listed in the "mnt-by:" attributes of the organisation object. When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks: - from one of the maintainers of the organisation object - from one of the maintainers of the object being updated 5. Query changes ---------------- If a whois query returns an object with an "org:" attribute, the organisation object mentioned in this attribute is also appended to the query results. This behaviour can be disabled by using the '-r' flag in the query. 6. Examples ------------ A basic organisation object: organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. city: Amsterdam country: NL phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE notify: ripe-mailbox(a)example-org.net ref-nfy: ripe-mailbox(a)example-org.net mnt-by: EXAMPLE-MNT changed: someguy(a)example-org.net 20030121 source: RIPE A network that references an organisation object: inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE status: ALLOCATED-BY-RIR PORTABLE mnt-by: EXAMPLE-MNT mnt-lower: EXAMPLE-MNT changed: someguy(a)example-org.net 20030122 source: RIPE A query for this inetnum object: % whois 192.168.86.251 inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE [...] source: RIPE organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. address: The Netherlands phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE [...] source: RIPE person: John Example nic-hdl: JE1-RIPE [...] source: RIPE person: John Example Jr nic-hdl: JE2-RIPE [...] source: RIPE

12 20

Proposal for easing keysigning at meetings
by Phil Pennock 02 Sep '03

02 Sep '03

A little hallway conversation led to a concensus that NCC-Services is the correct place to suggest this idea; it's a minimal-cost suggestion for aiding crypto key-signing via the RIPE conference registration. The main issue with exchanging crypto keys (eg PGP) is verifying that all the information has been copied correctly and spending the actual time to do it. If the online registration form has an optional field to supply a key fingerprint, then those who supply this will have their fingerprint listed in the attendee list and shown on their registration badge (optionally with keyid if not embedded in fingerprint). Then, if you're interested in verifying keys at the level of "I've talked to this person and someone has paid a few hundred euros for him to attend a conference in his name" or greater trust, then you can glance over the fingerprint on the badge, versus that on the list, and just tick the item. Then, later, working through the list you can just retrieve/sign/upload those keys which you've ticked. Benefits: * makes valid key-signing friendlier to the lazy and those without a surface to easily write on (or a PDA or ...) * so web of trust more likely to be established at RIPE meetings Disadvantages: * minimal change to registration form, slightly longer printouts * it's not _entirely_ free, but it's once-off minimal development and probably some text in the booklets explaining the system (and why people shouldn't just sign every key on the list) Does anyone think that this is a good idea, or a violently stupid idea? Should RIPE be doing this? (I actually proposed this at LISA a couple of years ago and the staff-member liked it and thought they'd try this at a USENIX Security conference, but I heard nothing more about it) -- Phil Pennock, Senior Systems Administrator, Demon Internet Netherlands NL Sales: +31 20 422 20 00 Thus Plc NL Support: 0800 33 6666 8

4 4

RE: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal
by Dominic Spratley 02 Sep '03

02 Sep '03

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. One of the ways we have attempted to reduce the burden on LIRs is by removing the Current Address Space Usage template in requests for IPv4 space. The template was fairly difficult for LIRs to complete. However, while the template has been replaced, the principle it represents - conservation - remains. That is why we ask whether the End Users has address space that can already meet the needs of this request. The situation with regard to address space that is being returned has not changed in these forms. We realise that many enterprises are not fully aware of the address space they use. To help LIR in these situations we have a Glimpse index of the database available. It can be found at: <http://www.ripe.net/db/whois-free.html> The LIR remains responsible for ensuring that assignments are justified and that address space that should be returned is returned. This remains the same. Nonetheless, LIRs must still ensure that the assignments they make are justified. That means that they need to gather appropriate justification. 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. 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. 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 RIPE NCC has not yet made yet 250 IPv6 allocations. Our experience with IPv6 networks is limited and we need network operators to show us how they intend to use IPv6 address space in their networks. Secondly, the current IPv6 policy does not allow stockpiling of IPv6 address space. One way of distinguishing a genuine request from one that is intended for stockpiling reasons is to request a diagram showing how the address space will be used. It doesn't have to be a a fancy diagram. It's also fine to fax a hand-drawn diagram instead of sending one by e-mail. When we have more experience with IPv6 I expect we will make the diagram optional. 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. 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. regards, Dominic Spratley, Registration Services Manager RIPE NCC

4 4