From huber at verw.switch.ch Thu Jul 2 13:25:26 1992 From: huber at verw.switch.ch (Willi Huber) Date: Thu, 2 Jul 1992 13:25:26 +0200 Subject: To get things started Message-ID: <433*/S=huber/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> Dear colleagues, As this new mailing list (dns-wg at ripe.net) has been created and the discussion about a second root server in Europa started I would like to say few words. SWITCH has run an inofficial root name server *) here in Zuerich for quite some time. The reason for setting up this service was the bad connectivity to the US internet in the past. This service was been offered not only to the Swiss universities but to everybody else who wanted to use it. The matter was discussed in the RIPE meetings. *) The file domain/root.zone is periodically fetched via anonymous FTP from nic.ddn.mil. But no information for the toplevel domains edu, com, org, ... is used. SWITCH offers to officially host and operate a secondary root server. The server would be placed in the western part of Switzerland with good connectivity to CERN (2 Mbit/s, 128 kbit/s backup). This location complements well the root server at NORDUnet. The name server would run on a state of the art SUN server, connected to an uninterruptable power source and be managed by adequat staff. In fact this DNS service is part of an offer SWITCH has handed in to the RARE Operational Unit recently. What the relation to RIPE is concerned I would like to cite from this proposal: "The operation of the root server should be guided by RIPE NCC under the auspice of RARE. The DNS server manager will have to attend RIPE meetings where the set-up of all the DNS servers is discussed and defined." With this message I hope to stimulate the discussion about root name servers in Europa. Willi Huber SWITCH From Yves.Devillers at inria.fr Thu Jul 2 17:55:40 1992 From: Yves.Devillers at inria.fr (Yves Devillers) Date: Thu, 02 Jul 92 17:55:40 N Subject: Problems sending to Master400.it In-Reply-To: Your message of Thu, 02 Jul 92 13:55:15 T. Message-ID: <199207021555.AA01184@chenas.inria.fr> In your previous mail you wrote: Hi, my PP mail MTA just received a message via x.400 originating in the x.400 ADMD Master400 in Italy. The sending user had requested a positive delivery report for the message. Unfortunately, my PP MTA was not configured to route the DR back via x.400, so it tried to use SMTP instead. Your system, corton.inria.fr is the preferred mail exchanger for the Master400.it domain and its subdomains. Sending back the DR via SMTP is not really a problem for my system (although it leads to loss of functionality of the sender of the original message), but unfortunately this failed. After looking into this a little further, it appears that it is corton.inria.fr which is the problem. My PP MTA said: > Your message was not delivered to > VINCENZO.COZZOLINO at ENEL.ENELUTI.Master400.it > for the following reason: > Unknown Address > MTA 'ENEL.ENELUTI.Master400.it' gives error message > ... hostname < > ENEL . ENELUTI . Master400 . it > unknown to name-server This was verified this way: % mconnect corton.inria.fr connecting to host corton.inria.fr (192.93.2.5), port 25 connection open 220 corton.inria.fr The EUnet gateway to France - Thu, 2 Jul 1992 13:44:06 + 0200 - (Sendmail+IDA+ 5.65c8d/92.02.29) vrfy vincenzo.cozzolino at enel.eneluti.master400.it 554 vincenzo.cozzolino at enel.eneluti.master400.it... hostname < enel . enelut i . master400 . it > unknown to name-server quit 221 corton.inria.fr closing connection % Which name-server is corton talking about? The master400.it domain has (as far as I can see) been properly registered in the DNS with both a "direct" MX and a wildcard MX for *.master400.it. The parties wanting to communicate would probably appreciate it if this problem could be fixed. If you could report back to me, I will notify the two parties wanting to communicate. Thanks. - Havard, (one of) postmaster at runit.sintef.no --> Havard, I (one of the manager of the EUnet-FR backbone machine: corton.inria.fr) would have been deeply flattered by Master400.it selecting us as their relay between SMTP and X.400 world (likely based on the excellence of our service). This choice would of course have led to some kind of 'contract', or at least minimum initial agreement; which we often accept in the context of EUnet to help connectivity. Unfortunatly, no such agreement exist, nor any initial agreement have ever been made between Master400 and EUnet-FR; agreement which would have allowed us to set up the proper dedicated routes directing to Master400 once the mail is caught by the MX on corton. You will certainly understand that it's quite hard for us to set up a special route (eg: non MX driven) for an entity we have never known of before. I suspect that this MX has been set by persons not understanding the full details and subtleties of MX, a well used tehcnique in the IP world. May I suggest those people read the excellent paper Piet Beertema once wrote in the context of RIPE DNS WG, as stored in ~ftp/ripe/doc/lpr/DNS-advice.txt on machine mcsun.eu.net Please note that this paper has been approved as a RIPE recommendation. It contains a good description of this "MX records surprise" (quoting Piet's paper): In a sense similar to point 3. Sometimes nameserver managers enter MX records in their zone files that point to external hosts, without first asking or even informing the systems managers of those external hosts. This has to be fought out between the nameserver manager and the systems managers involved. Only as a last resort, if really nothing helps to get the offending records removed, can the systems manager turn to the naming authority of the domain above the offending domain to get the problem sorted out. Here is what DNS query yield on corton: > Master400.it Server: corton.inria.fr Address: 192.93.2.5 Master400.it preference = 10, mail exchanger = corton.inria.fr Master400.it preference = 20, mail exchanger = infngw.infn.it Master400.it preference = 30, mail exchanger = cosine-gw.infn.it corton.inria.fr internet address = 192.93.2.5 infngw.infn.it internet address = 131.154.1.1 cosine-gw.infn.it internet address = 140.105.6.99 Another query for zone trasnfert for IT, as stored on NIS.GARR.IT shows the following setting up: master400 MX 10 corton.inria.fr master400 MX 20 infngw.infn.it master400 MX 30 cosine-gw.infn.it *.master400 MX 10 corton.inria.fr *.master400 MX 20 infngw.infn.it *.master400 MX 30 cosine-gw.infn.it And also: y-net MX 10 corton.inria.fr y-net MX 20 infngw.infn.it y-net MX 30 cosine-gw.infn.it *.y-net MX 10 corton.inria.fr *.y-net MX 20 infngw.infn.it *.y-net MX 30 cosine-gw.infn.it The latter one direct mail for *y-net.it to the gateway to ynet-gw, which happens to be chenas.inria.fr rather than corton.inria.fr The recommendation by YMU (Ynet management unit) are that an MX should point to chenas.inria.fr, and only to it. This later point has to be dealt with directly with Teleo in Bruxelles. Cordialement, Yves ---------------------------------------------------------------- Yves Devillers Internet: Yves.Devillers at inria.fr Institut National de Recherche Goodie-Oldie: ...!uunet!inria!devill en Informatique et Automatique Phone: +33 1 39 63 55 96 INRIA, Centre de Rocquencourt Fax: +33 1 39 63 53 30 BP 105, 78153 Le Chesnay CEDEX Twx: 633 097 F France. From Havard.Eidnes at runit.sintef.no Fri Jul 3 13:14:57 1992 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Fri, 3 Jul 92 13:14:57 MET DST Subject: Problems sending to Master400.it In-Reply-To: Your message of Thu, 02 Jul 92 17:55:40 N Message-ID: > I (one of the manager of the EUnet-FR backbone machine: corton.inria.fr) > would have been deeply flattered by Master400.it selecting us as their > relay between SMTP and X.400 world (likely based on the excellence > of our service). This choice would of course have led to some kind of > 'contract', or at least minimum initial agreement; which we often > accept in the context of EUnet to help connectivity. > > Unfortunatly, no such agreement exist, nor any initial agreement have > ever been made between Master400 and EUnet-FR; agreement which would > have allowed us to set up the proper dedicated routes directing to Master400 > once the mail is caught by the MX on corton. I really should have guessed that. It's of course difficult for you to set up something you haven't been asked about and where no agreement exists. My apologies for indicating that this was a problem of yours. However, I think that some of the people receiving your message (and this) will feel a responsibility to contact the people administrating the x.400 service in Master400, Italy, to get the proper agreements in place, have the SMTP/ x.400 gateway configured accordingly and to complete the associated DNS registrations. Isn't it natural that the people behind domain at nis.garr.it take this ball? Regards, Havard From Daniel.Karrenberg at ripe.net Mon Jul 6 12:21:03 1992 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 06 Jul 92 12:21:03 +0200 Subject: NCC to provide secondary name service for Top Level Domains? Message-ID: <9207061021.AA24811@ncc.ripe.net> Thomaz Kalin has raised the question with me whether the NCC should provide secondary domain service for top level domains with servers located in Europe and (by arrangement) on other continents. Should this be added to the NCC activity plan? So far my personal experience has been that all top level domain administrators have been able to make satisfactory arrangements for this service. Daniel From Daniel.Karrenberg at ripe.net Mon Jul 6 12:24:31 1992 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 06 Jul 92 12:24:31 +0200 Subject: Domains in the RIPE database Message-ID: <9207061024.AA24822@ncc.ripe.net> While I am busy asking difficult questions :-). Recent statistics show that the number of domain entries in the RIPE database is increasing at a sub-linear rate. I infer from this that by far not all European domains are represented by domain objects in the database. At the same time RFC1183 defines a method of incorporating contact information for zones into the DNS itself. Doesn't this invalidate the rationale for keeping information about domains in the database? Should we discontinue the domain object in the database? Daniel From Piet.Beertema at cwi.nl Mon Jul 6 12:40:36 1992 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Mon, 06 Jul 1992 12:40:36 +0200 Subject: NCC to provide secondary name service for Top Level Domains? In-Reply-To: Your message of Mon, 06 Jul 92 12:21:03 +0200 . <9207061021.AA24811@ncc.ripe.net> Message-ID: <9207061040.AA22570.piet@kraai.cwi.nl> So far my personal experience has been that all top level domain administrators have been able to make satisfactory arrangements for this service. Indeed they have. Piet From Piet.Beertema at cwi.nl Mon Jul 6 12:43:25 1992 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Mon, 06 Jul 1992 12:43:25 +0200 Subject: Domains in the RIPE database In-Reply-To: Your message of Mon, 06 Jul 92 12:24:31 +0200 . <9207061024.AA24822@ncc.ripe.net> Message-ID: <9207061043.AA22582.piet@kraai.cwi.nl> At the same time RFC1183 defines a method of incorporating contact information for zones into the DNS itself. Doesn't this invalidate the rationale for keeping information about domains in the database? No, it doesn't. The 'whois' service is just to easy and widely in use for this purpose already that you cannot suddenly switch to another method. The only way to do that would be in a worldwide coordination action where the domain information would be removed from the NIC whois database too. Personnally I don't see that happen. Piet From rafal at cocos.fuw.edu.pl Mon Jul 6 13:41:26 1992 From: rafal at cocos.fuw.edu.pl (rafal at cocos.fuw.edu.pl) Date: Mon, 6 Jul 92 13:41:26 MET DST Subject: Domains in the RIPE database Message-ID: <9207061141.AA03532@cocos.fuw.edu.pl> Yes, in my opinion this information is spurious while causing unnecesary work for the NCC sfaff. As such the domain registration should be discontinued. Rafal From Daniel.Karrenberg at ripe.net Wed Jul 22 13:52:14 1992 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 22 Jul 92 13:52:14 +0200 Subject: Suggestion from Piet Beertema Message-ID: <9207221152.AA18981@ncc.ripe.net> ------- Forwarded Message Date: Tue, 21 Jul 1992 11:45:04 +0200 From: Piet.Beertema at mcsun.EU.net Sender: piet at mcsun.EU.net To: ncc at ripe.net Subject: Suggestion Add a "connect" field to domain entries, showing the service provider(s) for a particular domain; alternatively set up a new field for it, although I can't think of an appropriate name for it right away. This feature would be valuable, as it would provide sites all over Europe with the possibility to exert access control on domain names, using the RIPE whois database as authoritative source (like it is used already for e.g. router access lists). Piet ------- End of Forwarded Message From rv at deins.informatik.uni-dortmund.de Wed Jul 22 15:12:00 1992 From: rv at deins.informatik.uni-dortmund.de (rv at deins.informatik.uni-dortmund.de) Date: Wed, 22 Jul 92 15:12:00 N Subject: Suggestion from Piet Beertema In-Reply-To: Your message of Wed, 22 Jul 92 13:52:14 +0200. <9207221152.AA18981@ncc.ripe.net> Message-ID: <9207221312.AA12922@meins.informatik.uni-dortmund.de> > ------- Forwarded Message > > Date: Tue, 21 Jul 1992 11:45:04 +0200 > From: Piet.Beertema at mcsun.EU.net > Sender: piet at mcsun.EU.net > To: ncc at ripe.net > Subject: Suggestion > > Add a "connect" field to domain entries, showing the service > provider(s) for a particular domain; alternatively set up a > new field for it, although I can't think of an appropriate > name for it right away. > This feature would be valuable, as it would provide sites all > over Europe with the possibility to exert access control on > domain names, using the RIPE whois database as authoritative > source (like it is used already for e.g. router access lists). > > > Piet > > ------- End of Forwarded Message The internal data database of DE-NIC for DE subdomains carries a field with this kind of information; in the application we are asking for the "primary network supporting the domain" (and setting the rules for use of gateways etc.), we also ask the service providers to confirm the support. Adapting to what seems to be needed these days the field usually is multi valued; with several sets of keywords describing different views or levels of the network structure (e.g. international service provider ./. integration in some regional network). I can come up with more detailled information in a few days. (and well, as the scheme did evolve over time, some aspects are not as precisely defined and documented as ...) Ruediger Ruediger Volk Universitaet Dortmund, Informatik IRB (DE NIC) Postfach 500 500 D-W-4600 Dortmund 50 Germany E-Mail: rv at Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386 From root at estec.esa.nl Thu Jul 23 16:48:07 1992 From: root at estec.esa.nl (root at estec.esa.nl) Date: Wed, 22 Jul 92 15:48:07 -2300 Subject: Suggestion from Piet Beertema Message-ID: <9207231448.AA18847@bcserver.estec.esa.nl> thank you the only OSF offices that i know of are in Munich, the US and Japan regards From rv at deins.informatik.uni-dortmund.de Wed Jul 22 15:54:51 1992 From: rv at deins.informatik.uni-dortmund.de (rv at deins.informatik.uni-dortmund.de) Date: Wed, 22 Jul 92 15:54:51 N Subject: Suggestion from Piet Beertema In-Reply-To: Your message of Wed, 22 Jul 92 15:48:07 +0100. <9207231448.AA18847@bcserver.estec.esa.nl> Message-ID: <9207221354.AA19400@deins.informatik.uni-dortmund.de> > thank you > the only OSF offices that i know of are in Munich, the US and Japan no, the Munich office of OSF has been closed down. However I think there was - and still is - another European office in Grenoble, France (or something inthat area). But BTW why discuss this on dns-wg at ripe.net? Regards, Ruediger Ruediger Volk Universitaet Dortmund, Informatik IRB (DE NIC) Postfach 500 500 D-W-4600 Dortmund 50 Germany E-Mail: rv at Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386 From nipper at ira.uka.de Wed Jul 22 15:11:50 1992 From: nipper at ira.uka.de (Arnold Nipper) Date: Wed, 22 Jul 92 15:11:50 MET DST Subject: Suggestion from Piet Beertema Message-ID: <9207221352.AA04069@reif.ripe.net> >Subject: Suggestion from Piet Beertema >From: Daniel Karrenberg >Date: Wed, 22 Jul 92 13:52:14 +0200 >Sender: Daniel.Karrenberg at ripe.net > >------- Forwarded Message > >Date: Tue, 21 Jul 1992 11:45:04 +0200 >From: Piet.Beertema at mcsun.EU.net >Sender: piet at mcsun.EU.net >To: ncc at ripe.net >Subject: Suggestion > >Add a "connect" field to domain entries, showing the service >provider(s) for a particular domain; alternatively set up a >new field for it, although I can't think of an appropriate >name for it right away. >This feature would be valuable, as it would provide sites all >over Europe with the possibility to exert access control on >domain names, using the RIPE whois database as authoritative >source (like it is used already for e.g. router access lists). > > > Piet > >------- End of Forwarded Message Suppose "nslookup" does domain name to adress translation, "net" does IP adress to IP net translation and finally "connect" gives the connect information about IP networks (This information already is in the RIPE DB), then connect ( net ( nslookup ( domain name ) ) ) does what you want. What I want to say is: a domain name ( when used acessing a site ) can be mapped onto an IP address. Don't overload the DB with information (Current size: 7315558 Byte. We started with some hundred KB). Arnold From Piet.Beertema at cwi.nl Wed Jul 22 16:18:53 1992 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 22 Jul 1992 16:18:53 +0200 Subject: Suggestion from Piet Beertema In-Reply-To: Your message of Wed, 22 Jul 92 15:11:50 MET DST . <9207221352.AA04069@reif.ripe.net> Message-ID: <9207221418.AA16473@kraai.cwi.nl> Suppose "nslookup" does domain name to adress translation, "net" does IP adress to IP net translation and finally "connect" gives the connect information about IP networks (This information already is in the RIPE DB), then connect ( net ( nslookup ( domain name ) ) ) does what you want. No, it doesn't. The connect field gives the connectivity a given network has, partly in "real" connectivity (e.g. "EU"), partly in "pseudo" connectivity ("RIPE"), but it doesn't state which the network service providers are nor nor the order in which these are service providers. And the latter is extremely important for determining policy based routing. The least that should be done to treat the connect field as routing source is to list the mnemonics that stand for the real service providers in order of routing preference (for the associated network of course). However, I don't like this "solution" at all, given the mix of "real" and "pseudo" connectivity in the connect field. Besides, a new field could be based an AS numbers in order of preference, much like the NSFnet policy routing database does now, making life infinitely easier. Furthermore I would consider building potentially large access or other lists for a router in the suggested way, through massive DNS queries, a crime... Don't overload the DB with information (Current size: 7315558 Byte. We started with some hundred KB). It will keep on growing anyway, especially when the RIPE, NIC and Merit databases get synchronized. Database size should not be used as an argument to keep out *useful* and authoritative information. Piet From nipper at ira.uka.de Wed Jul 22 17:00:11 1992 From: nipper at ira.uka.de (Arnold Nipper) Date: Wed, 22 Jul 92 17:00:11 MET DST Subject: Suggestion from Piet Beertema Message-ID: <9207221502.AA19500@ncc.ripe.net> > Suppose "nslookup" does domain name to adress translation, > "net" does IP adress to IP net translation and finally > "connect" gives the connect information about IP networks What I was thinking of was the "*n[io]" - tag already used. (e.g: *ni: 1=701 2=1800 3=1238 ) > (This information already is in the RIPE DB), then > connect ( net ( nslookup ( domain name ) ) ) > does what you want. >No, it doesn't. The connect field gives the connectivity >a given network has, partly in "real" connectivity (e.g. >"EU"), partly in "pseudo" connectivity ("RIPE"), but it >doesn't state which the network service providers are nor >nor the order in which these are service providers. And >the latter is extremely important for determining policy >based routing. The least that should be done to treat the >connect field as routing source is to list the mnemonics >that stand for the real service providers in order of >routing preference (for the associated network of course). >However, I don't like this "solution" at all, given the >mix of "real" and "pseudo" connectivity in the connect >field. Besides, a new field could be based an AS numbers >in order of preference, much like the NSFnet policy routing >database does now, making life infinitely easier. > >Furthermore I would consider building potentially large >access or other lists for a router in the suggested way, >through massive DNS queries, a crime... As far as I remember there is a "*di" - tag for domain name entries listing IP adresses used in this domain. Hence no usual "nslookup"! > > Don't overload the DB with information (Current size: 7315558 Byte. > We started with some hundred KB). >It will keep on growing anyway, especially when the RIPE, >NIC and Merit databases get synchronized. Database size >should not be used as an argument to keep out *useful* Don't misunderstand me!! I don't want to keep out *useful* information. I just want to minimize and streamline the DB. Keep the DB as small as possible and join the information on your local machine (NO DNS lookups!). >and authoritative information. > > > Piet Arnold From Piet.Beertema at cwi.nl Wed Jul 22 17:34:12 1992 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 22 Jul 1992 17:34:12 +0200 Subject: Suggestion from Piet Beertema In-Reply-To: Your message of Wed, 22 Jul 92 17:00:11 MET DST . <9207221502.AA19500@ncc.ripe.net> Message-ID: <9207221534.AA16619@kraai.cwi.nl> What I was thinking of was the "*n[io]" - tag already used. (e.g: *ni: 1=701 2=1800 3=1238 ) Hmmm, I doubt whether the *n[io] would be adequate to unequivocally identify the network service providers for a given network, but I can't think right away of a good [counter]example. As far as I remember there is a "*di" - tag for domain name entries listing IP adresses used in this domain. Hence no usual "nslookup"! A "*di" tag may ever have been proposed, but I don't see it in any of the RIPE templates. Don't misunderstand me!! I don't want to keep out *useful* information. I just want to minimize and streamline the DB. Then we're operating on the same wavelength. Piet From nipper at ira.uka.de Wed Jul 22 17:43:32 1992 From: nipper at ira.uka.de (Arnold Nipper) Date: Wed, 22 Jul 92 17:43:32 MET DST Subject: Suggestion from Piet Beertema Message-ID: <9207221552.AA19564@ncc.ripe.net> > As far as I remember there is a "*di" - tag for domain name > entries listing IP adresses used in this domain. Hence no > usual "nslookup"! >A "*di" tag may ever have been proposed, but I don't >see it in any of the RIPE templates. Just have a look at document "ripe-w02" chapter 2.1 (RIPE Databases; R.Blokzijl ; 28 August, 1990) Arnold From Piet.Beertema at cwi.nl Wed Jul 22 21:15:41 1992 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 22 Jul 1992 21:15:41 +0200 Subject: Suggestion from Piet Beertema In-Reply-To: Your message of Wed, 22 Jul 92 17:43:32 MET DST . <9207221552.AA19564@ncc.ripe.net> Message-ID: <9207221915.AA16855@kraai.cwi.nl> A "*di" tag may ever have been proposed, but I don't see it in any of the RIPE templates. Just have a look at document "ripe-w02" chapter 2.1 (RIPE Databases; R. Blokzijl ; 28 August, 1990) Yep, you're right, the field is there; but the description is "IP addresses of networks in this domain". Now, how could this information possibly be useful in determining network service providers for a domain??? Unless of course you go through a chain of queries for each network found in a given domain and finding its *co or *n[io] field. Especially now, with the need to assign multiple class C numbers instead of a class B number to large organisations, this doesn't seem very practical to me in determining the service provider(s) for a given domain and building access lists from it. Furthermore, a practical problem is that domain entries are often submitted as a block by the registrar of the top (or next higher) domain; and for the registrar IP addresses in a domain are irrelevant information. By contrast, information about service providers *is* relevant information, if only in conjunction with setting up MX records, which often point to hosts of service providers and therefore require the permission of those service providers. In other words: you can't see putting information in the RIPE database separate from the practical issue of gathering the information and of the relevance of that information. Piet From Daniel.Karrenberg at ripe.net Thu Jul 23 11:16:15 1992 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 23 Jul 92 11:16:15 +0200 Subject: Suggestion from Piet Beertema In-Reply-To: Your message of Wed, 22 Jul 92 21:15:41 +0200. <9207221915.AA16855@kraai.cwi.nl> Message-ID: <9207230916.AA20449@ncc.ripe.net> I am still not clear what is really needed. I read: - information about service provider(s) for a domain But i assume what is meant is: - information about *e-mail* service provider(s) for a domain We have information about IP service providers in the database and while the currenct "connect" field is not very well defined we will have the more clearly defined fields soon. Questions: Do we need information about mail service providers separately? My answer: Don't know. Who will maintain the information? My answer: This is the key question. I think the providers should. This raises similar problems as the routing-privilege one. Is the RIPE database the right place? My answer: maybe. How to code it in the RIPE database (object, attribute)? My answer: Piet is right that it should go with the domain object. I would propose a new attribute "mail-provider" or some similar name. This should probably be an *ordered* list of tags much like the new routing privilege. It should definitely not be named just "connect". Daniel From Daniel.Karrenberg at ripe.net Thu Jul 23 11:24:40 1992 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 23 Jul 92 11:24:40 +0200 Subject: Suggestion from Piet Beertema In-Reply-To: Your message of Thu, 23 Jul 92 11:21:49 +0200. <9207230921.AA17828@kraai.cwi.nl> Message-ID: <9207230924.AA20470@ncc.ripe.net> > Piet Beertema writes: > > We have information about IP service providers in the database > Related to domains? That's the point! I don't understand you at all. Why do you want that. Give an example. From Piet.Beertema at cwi.nl Thu Jul 23 11:29:21 1992 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Thu, 23 Jul 1992 11:29:21 +0200 Subject: Suggestion from Piet Beertema In-Reply-To: Your message of Thu, 23 Jul 92 11:24:40 +0200 . <9207230924.AA20470@ncc.ripe.net> Message-ID: <9207230929.AA17865@kraai.cwi.nl> I don't understand you at all. I stand corrected: I should have said 'service provider(s) in general to a domain, not just IP service only'. So yes, that specifically includes mail service provider(s). Piet From Piet.Beertema at cwi.nl Thu Jul 23 11:21:49 1992 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Thu, 23 Jul 1992 11:21:49 +0200 Subject: Suggestion from Piet Beertema In-Reply-To: Your message of Thu, 23 Jul 92 11:16:15 +0200 . <9207230916.AA20449@ncc.ripe.net> Message-ID: <9207230921.AA17828@kraai.cwi.nl> I read: - information about service provider(s) for a domain But i assume what is meant is: - information about *e-mail* service provider(s) for a domain No: information about services other than IP is pretty useless for building router access lists. We have information about IP service providers in the database Related to domains? That's the point! Questions: Do we need information about mail service providers separately? I don't see a use for that right away. Piet