Slashdot Mirror

To be more specific, the late, great John Postel wrote in RFC 1591 that dot-orgs can be any damn organization they want:

ORG - This domain is intended as the miscellaneous TLD for
organizations that didn't fit anywhere else. Some non-
government organizations may fit here.

So peta.org didn't really have any special rights, according to my interpretation.

sulli

There are no reasons at all in theory for people to change URIs (or stop maintaining documents), but millions of reasons in practice.

The Network Working Group is working on a replacement for URLs -- Uniform Resource Names. URNs are intended to serve as persistant, location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space.

SLP (Service Locator Protocol) seems to already be a good way to detect and locate services automatically on a network. It is a defined standard in RFC2608 and is used as the basis many networking technologies already (NetWare 5, MS W2K) and can be easily and consistantly configured to support any service type imaginable (it uses URI/URLs as its encoding system). There is already two SLP libraries for Linux, one from Sun under the SCSL and one from Caldera under the GPL.

Actually, in my limited research, this looks like a really neat way to generally advertise services. You would be able to create something like the Network Neighborhood or an NDS tree (Using SLP and LDAP together) for UNIX. Being able to plug into a network and instantly find out exactally what hosts have what services available without any configuration on your part (info for master DA server can be sent via DHCP) without all the messiness that the SMB browser protocol has (SMB, against all odds, is actually considered a protocol! Ha!) is a Really Good Feature(tm).

US is the country code here, we just truncate it for convenience since we in the US run the show. Here you go, read all about it. You may also wish to browse rfc1480 but I'm sure they will point this out to you at the ICANN forum .

while we are on the topic, does anyone know if appending .us onto a regular US site is supposed to work? I wouldn't imagine any dns servers bother with it. And it don't work from here...


:)Fudboy

QOS is a must! RFC 2459 - IP Over Avian Carriers with Quality of Service

--
Eric is chisled like a Greek Godess

I haven't looked at the IPv6 specs in a while, and when I did last I wasn't really paying attention to that specific point, but every method I studied back in my networks class assumed priority was respected in exchange for cash.

Take a look at HTTP Extension Framework. Note a couple of key aspects:

1. use of mandatory and optional items
2. end-to-end transmission
3. referential connections (ie ensure a link encoded within the content)

Take a careful look at how the protocol extensions are to be used in their examples:

• Man: "http://www.copyright.org/rights-management"; ns=16
• 14-Credentials="g5gj262jdw@4df"
• Expires: Sun, 25 Oct 1998 08:12:31 GMT
• C-Opt: "http://www.meter.org/hits"
• Opt: "http://www.my.com/tracking"
• Cache-Control: no-cache="Ext"

LL

Maybe I should have said that ISI doesn't charge anything for registrations. I know that I got mine for free (the contact in my city worked at the local university), but I don't have any experience outside that area.

But when I was looking over the list of delegated subdomains, I noticed that many of them were delegated out to random companies in different states. It's ridiculous. Many of the places given subdomains aren't real towns. I guess some people at those companies looked through a map and wrote down the names of some places and asked ISI to make them the contact so they could charge your something that costs them nothing.

Maybe I should have said that ISI doesn't charge anything for registrations. I know that I got mine for free (the contact in my city worked at the local university), but I don't have any experience outside that area.

But when I was looking over the list of delegated subdomains, I noticed that many of them were delegated out to random companies in different states. It's ridiculous. Many of the places given subdomains aren't real towns. I guess some people at those companies looked through a map and wrote down the names of some places and asked ISI to make them the contact so they could charge your something that costs them nothing.

The Internet is more than just a packet switched network. The idea that made it possible is the catenet (concatenated networks). See IEN 48, The Catenet Model for Internetworking, Vint Cerf, 1978. The catenet model made it possible to build an Internet out of many incompatible and proprietary networks. Like the Borg, the catenet model could assimilate other networks, without discarding their hardware or software.

There's actually an internet protocol for just this kind of situation. I don't know of any real-world implmentations, though. See RFC 1149.

--Fzz

Boy now weren't most of those international domains?

Interesting question. From back in the day, I thought that they were all US only. (And it's pretty believable that the US would have an ego like that, isn't it?) But RFC1591 and IANA seem to agree with you. .com, .org, and .net are all intented to be international in nature.

To save you a click, IANA says:

• GOV = US only
• EDU = US only
• MIL = US only
• COM = anybody
• NET = anybody
• ORG = anybody
• INT = organizations established by international treaties between governments

But you can find plenty of people that state or imply that .com is for US commercial interests, so I don't feel too bad for being confused.

Oh well. I'm going to try to get myself registered as a .int just for the hell of it.

perhaps they can implement it using RFC 2795
Seriously, this is not something that warrants actual spending of tax dollars. God knows those poor bastards in europe pay enough already. Not that the 1% of science^H^H^H^H^H^Hpeculative fiction which is based on real science doesn't have merit; there are thousands upon thousands of good, feasable ideas IMAO. For example Jack Vance suggests selling human pelts. A completely untapped market. Akkad Pseudoman (EF Northrup -yes, that one) suggested electromagnetic launch in a 1937 book entitled "Zero to Eighty". Intel ads have maglev material handling systems. There is Heinlien's oft mentioned 'waldo' of "Waldo and Magic Inc.". And John Christopher suggests electrical 'caps' to bend human minds to your every whim. Tell me thats not a good idea! All good ideas. But not worth spending tax money on.

Isn't it amazing how many of my sentences begin with contractions?

Remeber the AOL vs. IM debacle? When AOL refused to allow IM to work with AIM, Microsoft wanted a standards agency to govern some sort of instant message standard. Well, well, well, now we have a real, open RFC standard defining Kerberos, but do they want it?

This is typical Microsoft. They have some of the most excellent coders, and excellent people in other fields working there, but they also have some of the most selfish policies in the industry.

The wheel is turning but the hamster is dead.

Huffman, Postel, Stevens . . . Now P.W. Katz. I feel guilty for not ever considering any of these people beyond what their program does or does not do for me -- or how I benefitted from their books, until after their death. To think that while we're all out there unzipping our latest copy of the Jargon file or stashing a bunch of porn in a password protected ZIP file, this guy was suffering a serious problem which eventually took his life at the age of *thirty-seven*.

I'm only 22. I spend all my time working at a desk. I haven't been in-shape for almost six years. I could be next. I could be next and I haven't offered a damn thing to the computer or internet community. These people -- and many others, have.

I hope that we'll remember these things in subsequent posts in reply to this article. The last thing we need is another disgustingly barbaric replay of the posts we saw when W. Richard Stevens died.

I hope you have peace, Phillip.

W. Richard Stevens Slashdot Article
W. Richard Stevens Home Page
David Huffman Slashdot Article
Jon Postel Slashdot Article
Jon Postel's Home Page

---
icq:2057699
seumas.com

So, I have to ask: why didn't ISO take off due to the issues with IPv4, thus giving IPv6 a chance to fill the niche?

Basically because there was too much political infighting in the standards committees. So you ended up with all sorts of features that were of no use to anybody except one particular vendor. As opposed to the IETF, which worked things out on technical merit. What resulted from the ISO was incredibly tricky to implement correctly, and the specs had plenty of gray areas which could frequently lead to incompatibility.

Not that people didn't try. If you look back through rfc-index.txt, you can see efforts like TUBA and IP with CLNP where people tried to bring some of the good features of ISO networking into IP.

Also, the experience of putting the Internet together gave the IETF people a far better insight into the problems of scaling very large networks than the people on the ISO committees (IMHO).

A mess: that's what I think the whole DNS system has become. It is being used for something which is completely unrelated to what it was designed for: it was designed as a way to associate IP addresses to computer names, and it is being used as a way to find data on the information web.

The three-letter domains are not at all being used as they should. Essentially, any name of importance gets registered under .com, .org and .net (except, of course, just the name I happen to be looking for, which is registered in just the one I don't think it is).

Now even two-letter domains are being used stupidly. We already have the .jump.to and .go.to silliness (.to is the country of Togo), now for the .tv silliness.

The solution lies, I think, in developping a new distributed database (one that is truly distributed and not centralized-distributed as the DNS is) and to replace Uniform Resource Locators by the Uniform Resource Names defined in RFC 2141 (not implemented) subset of Uniform Resource Identifiers.

It is certainly worthwhile to pursue research in this direction, if only to gain insight on how distributed databases can work. Unfortunately, it will be many years before a solution can be practically implemented, even if one is found. I am afraid that organizations such as the IETF are gradually being contaminated by commercial near-sightedness. But then, IPv6 development has been possible, even though it was a long-term project, so maybe a DNS replacement is not all that hopeless.

BTW: Does anyone know when pigs will fly? (c:

According to RFC 1925:

(3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.

If we are allowed to link to the DeCSS source code, are we allowed to link to it using the data: URL scheme that is defined in RFC 2397? That would, of course, be exactly the same as mirroring it; but there's no limit to the amount of hair-splitting that legal nonsense can lead us to.

If your browser supports the data: URL scheme (pretty damn unlikely, really), then you should be able to read this document.

For the remote hosts, we need protocols that do not allocate resources unless they are absolutely necessary. Look at upcoming protocols like SCTP. The protocol mandates that the initial connection sequence be stateless on the server side. So at levels below the application, DDoS attacks become much, much harder. This is essentially the SYN cookie hack, but made official.

So what about the application level? Well, applications need written to allocate state only when absolutely necessary. This doesn't necessarily imply pushing all state to the client side, however. Mainframe folks have been doing some this for a long time. It'd be interesting to see just how much carries over to a networked system.

And NI / bus bandwidth on the receiving host? This one's a cool problem. How much processing can be done in the NI to reduce host bus traffic? And how can one reserve resources in the NI to statistically guarantee that proper sessions work during a bombardment with bogus sessions? (Extra credit: How does one move some of the app-level down to the NI to help? Or out to the routers?)

These are the interesting areas for server-side DoS defenses, not DNS and router games. Then things like CIDF and/or the idwg work for detecting and squelching DDoS attacks... Imagine if every Gnutella, SETI@home, and distributed.net client and server also helped with DDoS detection... Much more interesting and practical than DNS and router tricks.

And then there's the boost in performance SETI and distributed.net would get from the new IMPS protocol...

For the remote hosts, we need protocols that do not allocate resources unless they are absolutely necessary. Look at upcoming protocols like SCTP. The protocol mandates that the initial connection sequence be stateless on the server side. So at levels below the application, DDoS attacks become much, much harder. This is essentially the SYN cookie hack, but made official.

So what about the application level? Well, applications need written to allocate state only when absolutely necessary. This doesn't necessarily imply pushing all state to the client side, however. Mainframe folks have been doing some this for a long time. It'd be interesting to see just how much carries over to a networked system.

And NI / bus bandwidth on the receiving host? This one's a cool problem. How much processing can be done in the NI to reduce host bus traffic? And how can one reserve resources in the NI to statistically guarantee that proper sessions work during a bombardment with bogus sessions? (Extra credit: How does one move some of the app-level down to the NI to help? Or out to the routers?)

These are the interesting areas for server-side DoS defenses, not DNS and router games. Then things like CIDF and/or the idwg work for detecting and squelching DDoS attacks... Imagine if every Gnutella, SETI@home, and distributed.net client and server also helped with DDoS detection... Much more interesting and practical than DNS and router tricks.

And then there's the boost in performance SETI and distributed.net would get from the new IMPS protocol...

This just makes the fight against spam that much more difficult.

Don't try to tell me that AOL can't pay a FTE or three to sort through the abuse mailbox and dispatch the complaints to the appropriate team.

http://www.homs-smarthome.com/1275.html

Check that main page too and these links:

href=http://search.yahoo.com/bin /search?p=home+automation

You can also set up your house as a domain for future compliance:

href=http://www.isi.edu/in-notes/ us-domain-delegated.txt

Send those people an email and set DNS to 1313mockingbirdlane.yourtown.MA.US

-Kris

IP may or may not live forever. Efficient overlays and active networks help abstract away the lower levels, so it won't matter. Hardware is fast enough to still perform well, and advanced software techniques help reduce the overhead... Keep your eyes open...

And make 'em put all of them up at a website. One open to everybody. I got it! call it MSDN, and have the website at msdn.microsoft.com and make them put out a GIANT SDK, with LOTS of example code and help files! And you're right about those super-secret FrontPage extensions... Those are more super secret than the Colonel's 27 herbs and spices and the Big Mac secret sauce combined! They should have to publish them all in an RFC, like ftp://ftp.isi.edu/in-notes/rfc2518.txt.

There is no Constitution for the Net, no bylaws or widely agreed-upon system or Constitution to protect widely agreed upon system to protect such rights as privacy, openness, and property.

This is not entirely accurate. RFCs define 'bylaws' of communications protocols and necessary prerequisites of 'membership' in the Internet, and even define privacy rights (here, here, and here, among others) and openness (SMTP being the first and most common that springs to mind). The concept of property is hotly debated, but will at some point probably be covered by a mechanism defined by an RFC.

You might rebut that these concepts are merely the definition of mechanisms by which discourse on the 'net is defined and regulated. But I ask you, is the Constitution not itself merely a document which defines mechanisms for human discourse (by laying the groundwork for the definition of law and administration of government)? I would go so far as to say that app-layer RFCs are to laws as TCP/IP is to the Constitution...


Your Working Boy,

There is no Constitution for the Net, no bylaws or widely agreed-upon system or Constitution to protect widely agreed upon system to protect such rights as privacy, openness, and property.

This is not entirely accurate. RFCs define 'bylaws' of communications protocols and necessary prerequisites of 'membership' in the Internet, and even define privacy rights (here, here, and here, among others) and openness (SMTP being the first and most common that springs to mind). The concept of property is hotly debated, but will at some point probably be covered by a mechanism defined by an RFC.

You might rebut that these concepts are merely the definition of mechanisms by which discourse on the 'net is defined and regulated. But I ask you, is the Constitution not itself merely a document which defines mechanisms for human discourse (by laying the groundwork for the definition of law and administration of government)? I would go so far as to say that app-layer RFCs are to laws as TCP/IP is to the Constitution...


Your Working Boy,

There is no Constitution for the Net, no bylaws or widely agreed-upon system or Constitution to protect widely agreed upon system to protect such rights as privacy, openness, and property.

This is not entirely accurate. RFCs define 'bylaws' of communications protocols and necessary prerequisites of 'membership' in the Internet, and even define privacy rights (here, here, and here, among others) and openness (SMTP being the first and most common that springs to mind). The concept of property is hotly debated, but will at some point probably be covered by a mechanism defined by an RFC.

You might rebut that these concepts are merely the definition of mechanisms by which discourse on the 'net is defined and regulated. But I ask you, is the Constitution not itself merely a document which defines mechanisms for human discourse (by laying the groundwork for the definition of law and administration of government)? I would go so far as to say that app-layer RFCs are to laws as TCP/IP is to the Constitution...


Your Working Boy,

There is no Constitution for the Net, no bylaws or widely agreed-upon system or Constitution to protect widely agreed upon system to protect such rights as privacy, openness, and property.

This is not entirely accurate. RFCs define 'bylaws' of communications protocols and necessary prerequisites of 'membership' in the Internet, and even define privacy rights (here, here, and here, among others) and openness (SMTP being the first and most common that springs to mind). The concept of property is hotly debated, but will at some point probably be covered by a mechanism defined by an RFC.

You might rebut that these concepts are merely the definition of mechanisms by which discourse on the 'net is defined and regulated. But I ask you, is the Constitution not itself merely a document which defines mechanisms for human discourse (by laying the groundwork for the definition of law and administration of government)? I would go so far as to say that app-layer RFCs are to laws as TCP/IP is to the Constitution...


Your Working Boy,

They're not releaseing RPC source.

Yes, they are. Sun's announcement says:

NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards: it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.

The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.

(emphasis mine).

Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.

I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).

They're releasing the NFS interface/protocol.

"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)

They're not releaseing RPC source.

Yes, they are. Sun's announcement says:

NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards: it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.

The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.

(emphasis mine).

Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.

I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).

They're releasing the NFS interface/protocol.

"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)

They're not releaseing RPC source.

Yes, they are. Sun's announcement says:

NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards: it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.

The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.

(emphasis mine).

Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.

I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).

They're releasing the NFS interface/protocol.

"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)

They're not releaseing RPC source.

Yes, they are. Sun's announcement says:

NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards: it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.

The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.

(emphasis mine).

Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.

I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).

They're releasing the NFS interface/protocol.

"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)

They're not releaseing RPC source.

Yes, they are. Sun's announcement says:

NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards: it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.

The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.

(emphasis mine).

Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.

I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).

They're releasing the NFS interface/protocol.

"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)

They're not releaseing RPC source.

Yes, they are. Sun's announcement says:

NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards: it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.

The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.

(emphasis mine).

Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.

I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).

They're releasing the NFS interface/protocol.

"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)

They're not releaseing RPC source.

Yes, they are. Sun's announcement says:

NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards: it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.

The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.

(emphasis mine).

Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.

I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).

They're releasing the NFS interface/protocol.

"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)

They're not releaseing RPC source.

Yes, they are. Sun's announcement says:

NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards: it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.

The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.

(emphasis mine).

Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.

I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).

They're releasing the NFS interface/protocol.

"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)

For years, especially while Y2K fears were building, I advocated the One True Date Format: YYYY-MM-DD (punctuation is optional and either dots or dashes may be substituted). It sorts correctly. It is locale-independent. It is Y3K-compliant. You need not use it for human interaction, but it should be used to store the dates and transmit them in internal protocols whenever they must be in a printable form. Binary equivalents are acceptable, but may not easily extend to Y10K compliance (see RFC 2550: Y10K and Beyond).

When you use this format, placing the most significant digits first (2000-02-02, see Jargon File 4.2.0: big-endian), it is painfully obvious that there is going to be a 2 in the high-order digit for the rest of our expected lifespan.

NDS is a directory service. It contains and replicates all information about network users, groups, computers, and other resources on the Net.

NDS uses its own authentication mechanism as well as standard LDAPv3 authentication. ADS uses Kerberos and might even use standard LDAPv3 as well. I should try it sometime using the JNDI LDAP providers we use just to see for myself.

NDS uses multimaster replication, which enables you to have multiple directory masters on your network sharing and updating information. This means all directory information looks the same, no matter from which server you are connected to.

Multimaster replication is very nice for running a large company, as it guarantees referential integrity of all your directory information, no matter how big the company or how physically disparate are your branch offices.

Note that referential integrity is part of NDS: it has no "404 Not Found" equivalent.

NDS V8 scales up to a billion objects in the database, so you could theoretically create user objects for everyone on Earth in six or seven directories, although I would probably just use the two or three NDS servers in my house. =)

We announced NDS for Linux, so you will be able to run it on your favorite Linux distro and redirect all authentication requests into NDS.

Sorry if I sound like an informercial--I live this stuff.

Hope that helps.... =)

............ kris

Kris Magnusson
Open Source Architect
Novell, Inc.
Coauthor, Java Enterprise in a Nutshell
O'Reilly & Associates

First, as I explain in another post in this disucssion, e-.com or microsoft-.com are not illegal domain names. Just read RFC1035: the title of section 2.3.1 is ``Preferred name syntax'': this is a SHOULD, not a MUST.

If someone decides to register this domain, it's their problem. If it breaks programs like TELNET, it's also their problem (``their'' refers to the people who registered, not to the programs): they took the risk to register that domain, knowing that they might have problems, and if their customers get angry because they can't access the domain, it't their problem.

The programs SHOULD, according to the RFC, do the best to be ``liberal in what they accept'', and accept all the names they can to pass them to the resolver library. The resolver library SHOULD accept any kind of characters, binary characters included, and pass them verbatim to the name servers (they shouldn't even change the letter case, only the nameservers are permitted to make the final decision on this subject).

Within their own domain, people are permitted to do whatever they want, including using binary characters in (sub)domain names, not being case-insensitive, or any other stupid thing on the same line. It will break everything, but, again, it's their problem.

I agree with the ICANN's decision to register this. Nowhere in the RFC's does it say they may not (at least, as far as I know). All this, as far as they're (to be) concerned, is ``somebody else's problem''. Just like it is if the IP address you give them as primary nameserver is invalid or does not work.

The other point is RFC1591, which (meta-)specifies the way the three-letter TLD's are organized. Note in particular that nowhere in it is it stated that the .org domain is for non-profit organizations, contrary to what is frequently claimed. But the ICANN is to be blamed for not respecting this RFC on several counts (notably for the .net domain; also, something like un.org should be un.int).

I whish this ``www.[any word].com'' nonsense would stop. My suggested solution would be to invent another, better adapted, distributed data base, to transform a word or phrase to a URL, call it, say, ``true names''; then add a truename:// URL scheme, which gets relocated using the ``true names'' database to the correct URL. Integrate that scheme in every popular browser, and make it the default URL scheme. Then DNS names can become again what they are supposed to be: computer names, not resource names. Admittedly, I am only suggesting displacing the problem, but maybe the other database I mention can be better attuned to the kind of problems we have with the DNS, and which the DNS was not designed to handle.

First, as I explain in another post in this disucssion, e-.com or microsoft-.com are not illegal domain names. Just read RFC1035: the title of section 2.3.1 is ``Preferred name syntax'': this is a SHOULD, not a MUST.

If someone decides to register this domain, it's their problem. If it breaks programs like TELNET, it's also their problem (``their'' refers to the people who registered, not to the programs): they took the risk to register that domain, knowing that they might have problems, and if their customers get angry because they can't access the domain, it't their problem.

The programs SHOULD, according to the RFC, do the best to be ``liberal in what they accept'', and accept all the names they can to pass them to the resolver library. The resolver library SHOULD accept any kind of characters, binary characters included, and pass them verbatim to the name servers (they shouldn't even change the letter case, only the nameservers are permitted to make the final decision on this subject).

Within their own domain, people are permitted to do whatever they want, including using binary characters in (sub)domain names, not being case-insensitive, or any other stupid thing on the same line. It will break everything, but, again, it's their problem.

I agree with the ICANN's decision to register this. Nowhere in the RFC's does it say they may not (at least, as far as I know). All this, as far as they're (to be) concerned, is ``somebody else's problem''. Just like it is if the IP address you give them as primary nameserver is invalid or does not work.

The other point is RFC1591, which (meta-)specifies the way the three-letter TLD's are organized. Note in particular that nowhere in it is it stated that the .org domain is for non-profit organizations, contrary to what is frequently claimed. But the ICANN is to be blamed for not respecting this RFC on several counts (notably for the .net domain; also, something like un.org should be un.int).

I whish this ``www.[any word].com'' nonsense would stop. My suggested solution would be to invent another, better adapted, distributed data base, to transform a word or phrase to a URL, call it, say, ``true names''; then add a truename:// URL scheme, which gets relocated using the ``true names'' database to the correct URL. Integrate that scheme in every popular browser, and make it the default URL scheme. Then DNS names can become again what they are supposed to be: computer names, not resource names. Admittedly, I am only suggesting displacing the problem, but maybe the other database I mention can be better attuned to the kind of problems we have with the DNS, and which the DNS was not designed to handle.

The reference is RFC1035 (``Domain Names — Implementation and Specification'') by Mockapetris. But read it carefully: the section 2.3.1 is entitled ``Preferred name syntax'' (emphasis is mine). There is nothing illegal about names not following this convention; in fact, RFC1035 domain names can contain arbitrary characters, even binary (including the dot character, the null character, and mixed case!). The RFC essentially restates the golden rule: be liberal in what you accept and conservative in what you send (i.e. use the suggested conventions if possible when creating domain names, but be prepared to accept any kind of data when you receive a domain name). The RFC suggests the conventions you name precisely for compatibility with mail and TELNET (see the notes at the beginning of section 2.3.1), so you are putting the cart before the horses (``illegal'' names are ``illegal'' because they break TELNET, not the other way around).

A domain name is not supposed to start with a digit, but this rule is violated in the very RFC for the IN-ADDR.ARPA domain. Arguably, this is not a problem because you can't TELNET directly to an IN-ADDR.ARPA domain host (I find it rather unfortunate that I can't type telnet t.z.y.x.in-addr-arpa as a substitute for telnet x.y.z.t, I've never understood why that is disallowed).

I wonder, with all the fad on Unicode, whether Unicode characters will end up being allowed in domain names. Then every trademark-owning company would rush to register their name in every possible script. Or, worse even, get their logo added to the Unicode tables and register the <logo>.com domain. Fortunately, the Unicode Consortium has decided never to include logos in the official Unicode tables (but they might get added in the user-reserved areas if some vendor (i.e. Micro$oft) is influential enough to provide a kind of standard in this domain). Imagine people not knowing how to write any more, just choosing the company's logo in a huge table, and pasting it in the location bar of their browser...

Removed where and how? Clarifications to the DNS Specification, less than three years old, mentioned nothing of the sort. Somebody in charge of your network should have known better.

That's funny, my copy of RFC 768 is titled "User Datagram Protocol", and the word "Unix" isn't there at all.

See RFC 2550 for all the glorious details. I'll leave it to you to decide whether it is a reasonable assumption that the computer systems of today will really outlast our solar system (let alone the end of the universe) and/or still have the same system of time (24 hours, dated from 1 CE, etc) many many years from now (the RFC extends *that* far). Either way, we'll never have a rollover again if we follow the RFC.

The false perception that internetworking is something new is forcing companies to concentrate on 'position position position' instead of actually applying the tech to make a buck.

I'm sure I'm not alone, being stuck in a meeting with someone who doesn't understand the value of a network. Someone who, when describing the internet uses words like "exciting" and "new". (reminds me of the old loveboat theme:).

When you find yourself in a meeting with someone who has seen one to many .com advertisements and wants pie in the sky things out of your network, use these little tools to deflate there position and keep them grounded in reality and out of the hype high.

1) Bring several printouts of Hobbes' Internet Timeline to the meeting and let them take it home to read.

2) Use the term 'Internetworking' instead of internet to illustrate that this isn't anything new.

3) Point out this is an evolution of many high minded ideas and compromises that have evolved internetworking to where it is today.

4) Point out the many protocols that have run over IP, each proclaiming themselves to be the new new thing.

I have found these tools to be both educational and informative on many occasions, and it helps bring the discussion down to a real world level where real work can be done. So the next time you find yourself in a meeting with 'consultant-of-the-week'. I hope you find these tools useful.

_____________________________________

The false perception that internetworking is something new is forcing companies to concentrate on 'position position position' instead of actually applying the tech to make a buck.

I'm sure I'm not alone, being stuck in a meeting with someone who doesn't understand the value of a network. Someone who, when describing the internet uses words like "exciting" and "new". (reminds me of the old loveboat theme:).

When you find yourself in a meeting with someone who has seen one to many .com advertisements and wants pie in the sky things out of your network, use these little tools to deflate there position and keep them grounded in reality and out of the hype high.

1) Bring several printouts of Hobbes' Internet Timeline to the meeting and let them take it home to read.

2) Use the term 'Internetworking' instead of internet to illustrate that this isn't anything new.

3) Point out this is an evolution of many high minded ideas and compromises that have evolved internetworking to where it is today.

4) Point out the many protocols that have run over IP, each proclaiming themselves to be the new new thing.

I have found these tools to be both educational and informative on many occasions, and it helps bring the discussion down to a real world level where real work can be done. So the next time you find yourself in a meeting with 'consultant-of-the-week'. I hope you find these tools useful.

_____________________________________

...and it's called "IRC". Internet Relay Chat already provides all of the features of the various IM clients and web-based chat pages. You can share files; you can be notified when certain people leave/join channel(s); etc. Too bad there's no cutesy flower icon, or "bing-bong" every time someone /messages you, otherwise it'd be the Next Killer App(tm).

And there's even an experimental RFC (1459) that describes the protocol! You can't get more standard than the IETF!!

Multicasting utilizes IGMP to setup a 'broadcast' that is limited in scope. That is to say that users have to 'tune in' to the multicast by 'joining' the IGMP group. This is handled by routers that must be multicast aware, i.e. have a decent IGMP v2 implementaion. The commodity internet is not multicast enabled, but you can tunnel into the Mbone. Also for those of us fortunate enough to have access to vBNS or Abilene these networks are already multicast enabled.