April 1996 - dns-wg - mailman.ripe.net

RE: Charging by local IRs
by Wilfried Woeber, UniVie/ACOnet 05 May '96

05 May '96

Daniel said: = > "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> writes: = > . Either store the documents where they are maintained = > --> broken links, eventually. = =I do not expect much volatility in this area. Also the new setup of =the RIPE docstore will note this as it happens and it can be fixed quickly. = = > . Or store the documents alongside with the parent doc at the RIPE-NCC = > --> non-trivial to make the access "secure" and at the same time = > resonably comfortable to ensure regular updates. = =This is slightly more involved and therefore 2nd choice. I stil think that it would be much simpler to put any relevant urls into the TLD-objects in the RIPE-DB, either in a remark: attribute or in the (proposed) url: attribute. Wilfried. BTW, technical curiosity: how do you intend to keep track of dangling pointers in the "new RIPE Web"? Carol mentioned that aspect briefly in the plenary report but didn't go into details... -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

TLD admin mailinglist
by Roderik Muit 30 Apr '96

30 Apr '96

It has been said a few times at the 24th RIPE meeting in Berlin that a mailinglist for Top Level Domain adminstrators has not been created yet. (Action point 23.2 was still considered open.) This is not true, however. The mailinglist was set up in the week after the 23rd RIPE meeting. The announcement of this has been sent to the DNS working group mailinglist. ======

3 3

Re: Charging by local IRs
by Niall O'Reilly 30 Apr '96

30 Apr '96

> > > Piet Beertema <Piet.Beertema(a)cwi.nl> writes: > > > > Hyperlinking documents in a national language into some > > international document is pretty useless. > >I do not agree. Someone local searching for the document >may find it through the international document. >Why don't you let the user decide? Aontai/m le Daniel. Ik ben met Daniel mee eens. I agree with Daniel. Niall O'Reilly

2 1

Re: Charging by local IRs
by Wilfried Woeber, UniVie/ACOnet 29 Apr '96

29 Apr '96

= > Piet Beertema <Piet.Beertema(a)cwi.nl> writes: = > = > Hyperlinking documents in a national language into some = > international document is pretty useless. = =I do not agree. Someone local searching for the document =may find it through the international document. =Why don't you let the user decide? While I do not want to comment on the usefulness of this approach - I'm certainly worried with the logistics. How would you keep the links "healthy" in the long run and the referred-to documents up-to-date? . Either store the documents where they are maintained --> broken links, eventually. . Or store the documents alongside with the parent doc at the RIPE-NCC --> non-trivial to make the access "secure" and at the same time resonably comfortable to ensure regular updates. = > The best = > compromise would be a short description in English of = > the procedures and policies, provided that is made very = > clear that said description does *not* formally take the = > role of the original documents. = =That would be excellent service o course. Nice to have, I agree. Otoh, I don't really understand the rationale to register a name in country when there is nobody available to cope with a local-language document... (Yes we keep getting such requests more frequently these days :-) =Daniel Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

Re: Charging by local IRs
by Hank Nussbacher 29 Apr '96

29 Apr '96

On Fri, 26 Apr 1996 10:12:45 +0100 you said: > Charging by Local Internet Registries > > ripe-xxx ... >5. Recommendations >To meet with the objectives outlined in this paper, it is recommended that >all registries: > > - publish their operating procedures; > > - publish details of the services they offer and the conditions and > terms that apply, including scales of tariffs if applicable; Why not have these procedures and national policies hyperlinked into this document, or have RIPE act as a repository for such docs such that countries exploring this area can compare "notes" with what other countries do? Hank

3 2

Windows NT and UDP checksums (fwd)
by David.Kessens＠ripe.net 29 Apr '96

29 Apr '96

> Peter Lothberg writes : > From roll(a)Stupi.SE Sun Apr 28 15:37:15 1996 > Date: Sun, 28 Apr 96 15:35:17 MET DST > From: Peter Lothberg <roll(a)Stupi.SE> > Subject: Windows NT and UDP checksums > To: staff(a)ripe.net > Message-Id: <CMM.0.90.0.830698534.roll(a)Junk.Stupi.SE> > > > It was discussed at the ripe meeting, if NT could support UDP checksums or not, > it turns out that it can... > > --Peter > > ------------------------------------------------------------------------ > REG: TCP/IP Transport Entries, PART 1 > Article ID: Q102973 > Revision Date: 05-APR-1996 > > The information in this article applies to: > > - Windows NT operating system version 3.1 > - Windows NT Advanced Server version 3.1 > > > The article contains REGISTRY entries for the TCP/IP Transport Entries, Part > 1. These subgroups are included: > > - TCP/IP Parameters Subkey Entries > - Adapter Card Parameters for TCP/IP > > > This is the first of two articles on these entries; for the other entries, > see "TCP/IP Transport Entries, Part 2." > > TCP/IP TRANSPORT ENTRIES > > The various TCP/IP keys do not appear in the Registry unless TCP/IP is > installed using the Network icon in Control Panel. > > With Registry Editor, you can modify the following parameters for the TCP/IP > transport. This section does not include all the TCP/IP > parameters that can be set using the Networks application in Control Panel. > > The startup parameters defined in this section are found in these subkeys of > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services: > > TCPIP\Parameters > adapter_name#\Parameters\TCPIP, (where adapter_name# indicates a > Services subkey for a network adapter > card) > Ftpsvc\Parameters > NBT\Parameters > Streams\Parameters > > > Parameters for network bindings for this service are described in the > article "NetRules Subkey Entries." See also > IsDomainMasterBrowser in the article "Browser Service Entries." > > TCP/IP PARAMETERS SUBKEY ENTRIES > > The entries for TCP/IP parameters appear under the following Registry path: > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters > > > ArpCacheLife REG_DWORD Number of Seconds > > Default: 600 (10 minutes) > > > Determines the default lifetime for entries in the ARP cache table. Once an > entry is placed in the ARP cache, it is allowed to remain > there until its lifetime expires or until its table entry is reused because > it is the oldest entry. > > ArpCacheSize REG_DWORD Number Default: 62 > > Determines the maximum number of entries that the ARP cache table can hold. > The ARP cache is allowed to grow dynamically until > this size is reached. After the table reaches this size, new entries can > only be added by replacing the oldest entries that exist. > > DatabasePath REG_EXPAND_SZ Pathname Default: > %SystemRoot%\system32\drivers\etc > > Determines where TCP/IP and NBT look for the hosts, services, networks, > protocols, NETRC, and LMHOSTS files. > > IpEnableRouter REG_DWORD 0 or 1 Default: 0 (false) > > Determines whether IP routing is enabled between local interfaces. IP > routing is always enabled for packets generated by the local > host. This parameter determines whether, for packets received on an > interface and not destined for this host, IP will attempt to actively > forward the packets to hosts that can be reached via its other interfaces. > > IpReassemblyTimeout REG_DWORD Number of seconds Default: 60 seconds > > Determines how long IP accepts fragments when attempting to reassemble a > previously fragmented packet. That is, if a packet is > fragmented, all of the fragments must make it to the destination within this > time limit; otherwise, the fragments will be discarded and > the packet will be lost. > > TcpDisableReceiveChecksum REG_DWORD 0 or 1 Default: 0 (false, that is, > checksums will be checked on receives) > > Specifies whether Checksums is disabled on receive. > > > TcpDisableSendChecksum REG_DWORD 0 or 1 > > Default: 0 (false, that is, checksums will be generated on sends) > > Specifies whether Checksums is disabled on send. > > > TcpKeepCnt REG_DWORD Number in Minutes > > Default: 120 > > > Specifies how often TCP/IP will generate keep-alive traffic. When TCP/IP > determines that no activity has occurred on the connection > within the specified time, it generates keep-alive traffic to probe the > connection. After trying TcpKeepTries number of times to deliver > the keep-alive traffic without success, it marks the connection as down. > > TcpKeepTries REG_DWORD Number Default: 20 > > Specifies the maximum number of times that TCP/IP will attempt to deliver > keep-alive traffic before marking a connection as down. > > TcpLogLevel REG_DWORD Number Default: 16 (log everything) > > Specifies how verbose TCP/IP should be about logging events in the event > log. The highest level of verbosity is 16, and 1 is the > lowest level. The following shows general information about these levels. > > Level Events to be included > --------------------------------------------- > 1 Only the most critical errors > 4 Serious protocol violations > 8 Nonserious protocol violations > 12 Information about unusual events > 16 Information about unusual events that > some networks normally allow > > > TcpMaxConnectAttempts REG_DWORD Number > > Default: 3 > > > Specifies the maximum number of times TCP/IP attempts to establish a > connection before reporting failure. The initial delay between > connection attempts is 3 seconds. This delay is doubled after each attempt. > > TcpMaxRetransmissionAttempts REG_DWORD Number Default: 7 > > Specifies the maximum number of times that TCP/IP attempts to retransmit a > piece of data on an established connection before ending > the connection. The initial delay before retransmitting is based on the > current estimate TCP/IP makes of the round-trip time on the > connection. This delay is doubled after each retransmission. Acknowledgment > of the data results in a recalculation of the estimate for > the round-trip time. > > TcpNumConnections REG_DWORD Number Default: 64 > > Specifies the maximum number of TCP endpoints. > > > TcpRecvSegmentSize REG_DWORD Bytes > > Default: 1460 > > > Specifies the maximum receive segment size. > > > TcpSendDownMax REG_DWORD Number > > Default: 16384 > > > Specifies the maximum number of bytes queued by TCP/IP. > > > TcpSendSegmentSize REG_DWORD Bytes > > Default: 1460 > > > Specifies the maximum send segment size. > > > TcpWindowSize REG_DWORD Number > > Default: 8192 > > > Sets the size of the TCP send and receive windows, which is the amount of > data that can be accepted in a single transaction. This > parameter is important in transferring files between a client and a server > and is critical for performance for one-way traffic, such as for > FTP. > > UdpDisableReceiveChecksum REG_DWORD 0 or 1 Default: 0 (false--that is, > checksums will be checked on receives) > > Specifies whether Checksums is disabled on receive. > > > UdpDisableSendChecksum REG_DWORD 0 or 1 > > Default: 0 (false--that is, checksums will be generated on sends) > > Specifies whether Checksums is disabled on send. > > > UdpNumConnections REG_DWORD Number > > Default: 64 > > > Specifies the maximum number of UDP endpoints. > > > ADAPTER CARD PARAMETERS FOR TCP/IP > > These parameters for TCP/IP are specific to individual network adapter > cards. These appear under the following Registry path, where > adapter name# refers to the Services subkey for the specific adapter card: > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services > \adapter name#\Parameters\Tcpip > > > BroadcastType REG_DWORD 0 or 1 > > Default: 1 (all 1 s) > > > Determines whether broadcast packets contain all 0 s or all 1 s as the > broadcast address. The most common broadcast type is all 1 s. > The all-0 s setting is provided for compatibility with BSD 4.2 systems. > > ForwardBroadcasts REG_DWORD 0 or 1 Default: 0 (false) > > Specifies whether broadcasts should be forwarded between adapters. If > enabled, broadcasts seen by this interface are forwarded to > other IP interfaces. > > KeepAlive REG_DWORD 0 or 1 Default: 1 (true) > > Determines whether TCP connections that request keep-alive packets result in > keep-alive packets being sent. This feature is used to > determine when inactive connections can be disconnected. When a connection > becomes inactive, keep-alive packets are periodically > exchanged. When 20 (the default value for TCPKeepTries) consecutive > keep-alive packets go unanswered, the connection is broken. > This disconnect is initiated by the endpoint that is sending keep-alive > packets. > > MTU REG_DWORD Number in octets Default: 0 (That is, use the value supplied > by the adapter.) > > Specifies the maximum transmission unit size of an interface. Each interface > used by TCP/IP may have a different MTU value specified. > The MTU is usually determined through negotiation with the lower driver, > using that lower driver s value. However, that value may be > overridden. > > Ideally, the MTU should be large enough to hold any datagram in one frame. > The limiting factor is usually the technology making the > transfer. Some technologies limit the maximum size to as little as 128; > Ethernet limits transfers to 1500; and proNet-10 allows as many as > 2044 octets per frame. > > Datagrams larger than the MTU value are automatically divided into smaller > pieces called fragments; size is a multiple of eight octets. > Fragmentation usually occurs somewhere through which the traffic must pass > whose MTU is smaller than the encapsulated datagram. > If fragmentation occurs, the fragments travel separately to the destination > computer, where they are automatically reassembled before > the datagram is processed. > > RouterMTU REG_DWORD Number in octets Default: 0 (That is, use the value > supplied by the lower interface.) > > Specifies the maximum transmission unit size that should be used when the > destination IP address is on a different subnet. Each > interface used by TCP/IP may have a different RouterMTU value specified. In > many implementations, the value of RouterMTU is set > to 576 octets. This is the minimum size that must be supported by any IP > node. Because modern routers can usually handle MTUs > larger than 576 octets, the default value for this parameter is the same > value as that used by MTU. > > Trailers REG_DWORD 0 or 1 Default: 0 (false) > > Specifies whether the trailer format is used. This feature provides > compatibility with BSD 4.2 systems. When this feature is enabled, > TCP/IP header information follows the data area of IP packets. > > Reference: "The Windows NT Resource Kit for Operating System Version 3.1" > > Additional reference words: prodnt 3.10 > > > > KBCategory: kbother > KBSubcategory: ntregistry > > THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS > PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS > ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES > OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO > EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR > ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, > CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF > MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE > POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION > OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES > SO THE FOREGOING LIMITATION MAY NOT APPLY. > > Copyright Microsoft Corporation 1996. > > > > >

1 0

Charging by local IRs
by mnorris＠dalkey.hea.ie 26 Apr '96

26 Apr '96

Please see the following paper on "Charging by Local Internet Registries". This was enhanced by the Local IR working group and adopted by RIPE earlier this week as a brief statement of current practice in Europe, together with some guidelines for registries. I'm sending this to the Local IR and the DNS lists, and will also copy the European TLD administrators, so apologies for multiple instances of the same mail. Your comments and suggestions are always welcome. Regards. Mike Norris Charging by Local Internet Registries ripe-xxx 1. Abstract This paper deals with charging for services by Internet registries, and indicates acceptable practice for such charging. It identifies name- and address-space as finite resources with no intrinsic value; as such, direct costs cannot be ascribed to such space. It also makes recommendations for the operation of European registries in general, and additionally for those with monopoly positions. 2. Internet services In Europe as elsewhere, providers offer a range of services relating to Internet access. These include Internet connectivity, the provision of applications to end-users, design, consultancy and training services, as well as system services such as IP registration, DNS, routing and packet forwarding. With some identifiable exceptions (to which we shall return), there is generally an open market in the provision of such services. On the supply side, there is freedom to enter the market, to compete for business, and to charge for services in order to stay in business. In this context, it is acceptable practice for Internet service providers (ISPs) to charge for services such as domain registration, routing services, packet forwarding and IP services. On the demand side, the general plurality of service providers means that the customer has a choice; if not satisfied with the terms of one supplier, she can take her business to another. 3. Registries and Resources Two of the above services involve the assignment of finite resources to customers; these are domain name space and IPv4 address space. They are managed and assigned by registration agencies, respectively domain name registries and IP registries. By themselves, these resources have no intrinsic value; their worth is only realised in conjunction with the provision of Internet access. Thus, while registries may charge for their administrative and technical services, they may not charge for namespace or address space as such; no unit cost or price tag can be attached to a domain name or to an IP address, public or private. This principle must be made clear to the market in general and to the customer in particular. The customer must be aware of precisely what she is getting from the registry, whether it is paid for or not. Where there is a charge, the customer must not be under the illusion that this translates into a unit cost per resource assigned, nor that the transaction is an indefinite transfer of ownership of the merchandise. Finally, the customer must accept the terms under which name or address space is assigned. In the case of IP address space, these include the contractual term that the assignment is only valid for so long as the criteria of the assignment are valid [ref 1]. As soon as the original criteria no longer apply, the address space must be returned without penalty or premium to the assigning registry. 4. Special Case Registries As indicated above, there are certain exceptions to the market principle in the Internet registration services. These occur where, by virtue of their location in the hierarchy of Internet registration, certain registries find themselves in a monopoly position. In the case of namespace, this applies to top-level domain (TLD) registries (in Europe, these are all country registries), as well as certain administratively unique second-level domain registries (such as .co.uk, .ac.at etc). When it comes to IP address allocation, regional registries constitute monopolies within the communities they serve. In Europe, one instance is the RIPE NCC, registry for the European region [ref 2]. Other possible examples are the last resort (non-provider) IP registries, although nowadays the customer has an alternative to their services. It is important that there be transparency in the procedures and accounts of such "special case" registries. They must not generate excessive profits by virtue of their monopoly position. 5. Recommendations To meet with the objectives outlined in this paper, it is recommended that all registries: - publish their operating procedures; - publish details of the services they offer and the conditions and terms that apply, including scales of tariffs if applicable; - explicitly publish the fact that they do not sell name or address space as such. As for "special case" registries as defined above, it is recommended that where such a registry charges for service, it should, in addition to complying with the recommendations listed above: - relate charges to costs of operation and apply all revenues to such costs; - regularly publish a budget of its anticipated operating costs and revenue; - publish guidelines and apply these uniformly; - ensure equality of access to registration services; - aim to achieve consensus within the community it serves as to the disposal of any surplus revenues; - regularly publish accounts of income and expenditure; - refrain from using their unique position as leverage in any other business venture. Daniel Karrenberg and Mike Norris 22nd April 1996 References 1. "European Internet Registry Policies and Procedures" by Orange, C., Kuehne, M., Karrenberg, D. (ripe-104, 1996) 2. "RIPE NCC - Delegated Internet Registry" (ripe-112, 1994)

1 0

[Internet-Drafts@CNRI.Reston.VA.US: I-D ACTION:draft-ietf-dnsind-serial-03.txt]
by Lars-Johan Liman 24 Apr '96

24 Apr '96

Regarding the documents that Blasco forwarded to the list (in the agenda): The one regarding DNS serial numbers has just been uptated. ------- Forwarded Message Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: namedroppers(a)internic.net Sender: ietf-announce-request(a)IETF.CNRI.Reston.VA.US From: Internet-Drafts(a)CNRI.Reston.VA.US Reply-to: Internet-Drafts(a)CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-dnsind-serial-03.txt Date: Tue, 23 Apr 96 08:57:06 -0400 X-Orig-Sender: cclark(a)CNRI.Reston.VA.US Message-ID: <9604230857.aa11201(a)IETF.CNRI.Reston.VA.US> Status: O - --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS IXFR, Notification, and Dynamic Update Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Serial Number Arithmetic Author(s) : R. Elz, R. Bush Filename : draft-ietf-dnsind-serial-03.txt Pages : 8 Date : 04/22/1996 This draft defines serial number arithmetic, as used in the Domain Name System. The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This draft supplies the missing definition. It is intended to update RFC1034 and RFC1035. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsind-serial-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-serial-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv(a)ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnsind-serial-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts(a)cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv(a)ds.internic.net" Content-Type: text/plain Content-ID: <19960422112750.I-D(a)CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnsind-serial-03.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsind-serial-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960422112750.I-D(a)CNRI.Reston.VA.US> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message

1 0

RIPE24 DNS-WG proposed agenda
by Antonio_Blasco Bonito 19 Apr '96

19 Apr '96

Hi everybody, sorry to be so late. The following is my poor proposal for the agenda of the DNS-WG. Please: - *contribute* to improve the agenda - come to the meeting having seletected your preferred candidate for the WG chairman position Agenda ------ 1. Scribe 2. WG-agenda bashing 3. Nomination of the DNS Working Group chair 4. Status of discussions about TLDs administration 5. Report of problems experienced 6. AOB ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito(a)nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 50 593246 Via S. Maria, 36 Fax: +39 50 904052 I-56126 PISA Telex: 500371 CNUCE I Italy Url: http://www.nis.garr.it/nis/staff/bonito.html ---------- ----------

4 8