Re: [Ietf] New .mobi, .xxx, ... TLDs?
In message [EMAIL PROTECTED], Dean Ande rson writes: On Mon, 26 Apr 2004, Stephen Sprunk wrote: You're confusing URI methods, protocols, and TLDs disastrously. I think it is you who is reading too much into the .tel and .mobi TLD. These are not proposals to put URI method functionality into domain names, Sure there are. Here's a direct quote from the .mobi proposal: Businesses and consumers that utilise mobile devices will be able to take advantage of a wide range of Internet services and content under the mTLD that have been specifically tailored for access and use by mobile devices. The sponsored TLD provides a clearly recognisable mobile label to the services and content, indicating that they will be easy and convenient to use with mobile devices. By choice of suitable mobile-specific technologies, the service offering can be adapted to mobile-specific characteristics, such as the limitations of mobile networks and devices (throughput, temporary signal loss, etc), which will result in a better user experience for those services. I find it hard to interpret that text in any other fashion -- they want to describe end-to-end protocols by DNS name. There are two proposals for .tel; here's text from one of them: Sub-domains of .tel may not be arbitrarily defined; rather they are defined in accordance with the ITU E.164 standard. A valid e164 domain name under the .tel TLD is defined as follows: Start with a telephone number: 1-212-332-1234. Remove all non-numeric characters: 12123321234. Reverse the order of the number: 43212332121. Separate by dots: 4.3.2.1.2.3.3.2.1.2.1. Add the sTLD: 4.3.2.1.2.3.3.2.1.2.1.tel. That looks like an ENUM competitor to me. (The other .tel proposal looks like a generic TLD at first reading.) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
% There are two proposals for .tel; here's text from one of them: % % Sub-domains of .tel may not be arbitrarily defined; rather % they are defined in accordance with the ITU E.164 standard. % A valid e164 domain name under the .tel TLD is defined % as follows: % % Start with a telephone number: 1-212-332-1234. % % Remove all non-numeric characters: 12123321234. % % Reverse the order of the number: 43212332121. % % Separate by dots: 4.3.2.1.2.3.3.2.1.2.1. % % Add the sTLD: 4.3.2.1.2.3.3.2.1.2.1.tel. % % That looks like an ENUM competitor to me. (The other .tel proposal % looks like a generic TLD at first reading.) Those who do not learn from history are doomed to repeat it. This is -exactly- the tpc.int. model, the e164.int. model, the e164.arpa. model... in a phrase... lacks traction --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Wed, 28 Apr 2004, Markus Stumpf wrote: No new TLD helps for the overcrowding, as all owners of trademarks have to and will register their name and enforce delegation of the name by law. This isn't true. No one is required by law to register their trademark as a domain name. So at best a new TLD is something like a license to print money for the registrar. Ok. What's wrong with that? If sponsoring organizations are willing to pay, they should be sold what they want. Sounds like you are against commercialization. So far, I still haven't heard a _technical_ reason against these TLD's. ** What is one thing that will break if these are granted? ** Better, what is the complete list of things that will break? --Dean ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
ext Steven M. Bellovin wrote: Sure there are. Here's a direct quote from the .mobi proposal: Businesses and consumers that utilise mobile devices will be able to take advantage of a wide range of Internet services and content under the mTLD that have been specifically tailored for access and use by mobile devices. The sponsored TLD provides a clearly recognisable mobile label to the services and content, indicating that they will be easy and convenient to use with mobile devices. By choice of suitable mobile-specific technologies, the service offering can be adapted to mobile-specific characteristics, such as the limitations of mobile networks and devices (throughput, temporary signal loss, etc), which will result in a better user experience for those services. I find it hard to interpret that text in any other fashion -- they want to describe end-to-end protocols by DNS name. I don't quite see what the difference here is to .edu for example. Isn't this indeed very similar to how the .edu provides a clearly recognisable label for educational services and content? Cheers, Aki ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
[Ietf] Last call comment on 'AES Encryption for Kerberos 5'
The document [1] specify a mode of encryption that has not, to my knowledge, been used anywhere else: CBC-CTS with IV-carry. The document does not reference any standard work that define it, so it appears the document authors are not aware of prior use of it either. There is no analysis of the security of the mode in the document. The CFRG has not commented on the mode. The security consideration does not mention that the document define or use a non-standard mode. Considering all this, I believe it would be only prudent to reflect those facts in the security consideration, to help people form an opinion about it. Here is a proposed paragraph for inclusion: The encryption mode used in this document, CBC with Cipher Text Stealing with IV carry between messages, has to our knowledge not been studied extensively, or even at all, in the available literature. Thanks, Simon [1] http://www.ietf.org/internet-drafts/draft-raeburn-krb-rijndael-krb-06.txt ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: [Ietf] New .mobi, .xxx, ... TLDs?
I don't think there was any lack of capability for traction for the earlier proposals, there just wasn't a surface to grip against. The news (good or bad depending on your biases) is that the telcos have some larger roles in the Internet now a days. When it was decided to open up TLDs, one should have expected that large multi-national bodies would want to be represented at that level, and for a variety of purposes. I would not be surprised if .tel and .mobi may only be the beginning. Some could certainly argue that there should be namespace injection points into the DNS for .itu and .gsm, ... Much like established names get inserted into multiple TLDs (e.g. company_name.com, company_name.fr, company_name.net, ...), I will be surprised if we don't end up with multiple injections of the fundamental telco naming space (e.164) into the DNS. for your consideration, peterf From: [EMAIL PROTECTED] on behalf of Bill Manning Sent: Thu 4/29/2004 6:21 AM To: Steven M. Bellovin Cc: Dean Anderson; Stephen Sprunk; jfcm; Tim Chown; [EMAIL PROTECTED] Subject: Re: [Ietf] New .mobi, .xxx, ... TLDs? % There are two proposals for .tel; here's text from one of them: % % Sub-domains of .tel may not be arbitrarily defined; rather % they are defined in accordance with the ITU E.164 standard. % A valid e164 domain name under the .tel TLD is defined % as follows: % % Start with a telephone number: 1-212-332-1234. % % Remove all non-numeric characters: 12123321234. % % Reverse the order of the number: 43212332121. % % Separate by dots: 4.3.2.1.2.3.3.2.1.2.1. % % Add the sTLD: 4.3.2.1.2.3.3.2.1.2.1.tel. % % That looks like an ENUM competitor to me. (The other .tel proposal % looks like a generic TLD at first reading.) Those who do not learn from history are doomed to repeat it. This is -exactly- the tpc.int. model, the e164.int. model, the e164.arpa. model... in a phrase... lacks traction --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: [Ietf] New .mobi, .xxx, ... TLDs?
Dean Anderson wrote: On Wed, 28 Apr 2004, Markus Stumpf wrote: No new TLD helps for the overcrowding, as all owners of trademarks have to and will register their name and enforce delegation of the name by law. This isn't true. No one is required by law to register their trademark as a domain name. IANAL, but in my discussions with lawyers focused on trademark law, in effect they are required. The perception that they are not defending their rights effectively means they abandon them. So at best a new TLD is something like a license to print money for the registrar. Ok. What's wrong with that? If sponsoring organizations are willing to pay, they should be sold what they want. Sounds like you are against commercialization. So far, I still haven't heard a _technical_ reason against these TLD's. The technical argument here is flattening of the name space with the associated concentration higher up the tree. There is nothing specific about these strings, but why do they have any more rights than any other string? Why shouldn't trademark owners be able to register the name 'yourtrademarkhere.', or anyone register 'yourpersonalfavoritestring.'? Do you really think the root is the right place for all names? If not, what technical characteristic differentiates strings that should vs. not? /flame-suit-on/ Rather than granting new TLDs, there should be an effort to deprecate the existing non-cc TLDs and move everyone out within 3 years. The historical artifact of a failed experiment is no reason to continue down that path. Tony ** What is one thing that will break if these are granted? ** Better, what is the complete list of things that will break? --Dean ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Thu, Apr 29, 2004 at 06:21:20AM -0700, Bill Manning wrote: Those who do not learn from history are doomed to repeat it. This is -exactly- the tpc.int. model, the e164.int. model, the e164.arpa. model... in a phrase... lacks traction So, place your bets on which slippery slopes ICANN takes us down... I'm not convinced of a good argument for any of the proposed new TLDs to be granted. But I'm sure some/many will. More money for ICANN... This is the sort of thing ISOC should speak out on. Tim ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
This is the sort of thing ISOC should speak out on. doh! ISOC can't as they are the major benefactor from the .org divestature from verisign. sorry, try again. -rick ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On 29-apr-04, at 21:18, Tony Hain wrote: This isn't true. No one is required by law to register their trademark as a domain name. IANAL, but in my discussions with lawyers focused on trademark law, in effect they are required. The perception that they are not defending their rights effectively means they abandon them. Defending their trademark doesn't necessarily mean registering every possible domain with the trademark in it, but it does usually mean going after other people who register a domain with the trademark in it. (Although there is always the slight problem that domain names are globally unique while very few trademarks are.) So far, I still haven't heard a _technical_ reason against these TLD's. The technical argument here is flattening of the name space with the associated concentration higher up the tree. So what angle hierarchy is desirable? Obviously a completely flat space isn't good because the zones get too large, but a very deep space isn't either as it takes more time to recurse through. /flame-suit-on/ Rather than granting new TLDs, there should be an effort to deprecate the existing non-cc TLDs and move everyone out within 3 years. The historical artifact of a failed experiment is no reason to continue down that path. So what is the rationale for organizing ourselves based on our respective countries? If I may borrow your suit for a minute, I have another suggestion: no hard limits on TLDs, but every organization only gets to have a domain name in one TLD. So the practice of registering domain.* would have to end. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
So, place your bets on which slippery slopes ICANN takes us down... ICANN loves these sponsored TLDs. It's the only kind they are presently considering. Sponsors generally have the cash needed to cover ICANN's application fee (which is typically on the order of $35,000 to $50,000, and is non-refundable even if the application is turned down or left in an indefinite limbo of being neither accepted nor rejected) and any ongoing tithes. (Remember, ICANN's budget is growing towards $10,000,000USD per year and that money has to come from somewhere.) And the sponsors generally have well a behaved and limited membership and are thus less likely to burden ICANN staff with work and are less likely to get into disputes (and lawsuits) with ICANN. I personally find many of the proposed uses for these sponsored TLDs rather silly and non-innovative - and they could well be done further down the DNS hierarchy and their only reason to be at the top level is for the prestige (and image marketing value) of having top level domain status. There are a couple of things about this situation: First, is that some of the TLD proposals before ICANN, such as .mobi, might contain some seeds of technical harm to the net. For example, if the .mobi folks don't use their own intermediate caching resolvers and rather allow all those mobile devices to go directly to the roots then there could be an increase in the traffic going to root and other servers. This could be exacerbated if those devices are frequently power cycled and lose their DNS caches. The .mobi folks haven't said that they are going to do this, but then again they haven't said that they are aware of this potential issue. Second, the idea that a TLD categorizes all of the resource records of all types found under that TLD seems to me to be wrong. For instance, assume there's a TLD called blue. if an A record found under a.b.c.blue leads me to an IP address on an interface, it is unreasonable to believe that the only services delivered via that address are of a blue nature. I suspect that many people who want these TLDs think of the net only in the limited sense of the world wide web. Third is that, as Tony Hain mentioned, there is trademark pressure that will eventually suggest to every big trademark holder that they ought to be a TLD. This may or not come to pass, but we can guess that at least some of the big trademark folks will give it a try, particularly after some of ICANN's sponsored TLDs ossify over time into de facto marks and thus blaze a trail that trademark owners might want to follow. And where one trademark owner goes, the herd is sure to follow. My own view is that we ought to be trying to shape the DNS tree so that it is well shaped in terms of width and depth of the hierarchy. I don't know the metrics of that shape. Have there been studies regarding the how the efficiency of DNS and DNS caching vary with DNS label depth and zone width? As for uses of TLDs - my own view is that as long as they are allocated only rarely then the few awards should go to those uses that contain the maximum innovation, maximimum flexibility, and give the greatest value to the users of the net. But I don't see why allocation of new TLDs needs to be a rare event. Personally, I want a lot of new TLDs, so that folks who have silly ideas and silly business models can try em out and be given a chance to flop - but this means that there needs to be a criteria to determine flopness and to reap the failed TLDs so they don't become dead zones in the DNS hierarchy. And I think it ought to be a requirement that any idea proposed for a TLD first be prototyped somewhere down the DNS hierarchy. Anybody who wants a new TLD should have to pledge allegance to the end-to-end principle (i.e. no new sitefinders) and promise to adhere to applicable internet technical standards and practices. I also would like to start to break the semantic implications of TLD names - I'd prefer that any new ones have names that are meaningless in any language, like ts4-0k7m. Yeah this has been gone over many times - but I still have this hope that with some nudging people will stop using DNS as a directory. --karl-- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: [Ietf] New .mobi, .xxx, ... TLDs?
Iljitsch van Beijnum wrote: On 29-apr-04, at 21:18, Tony Hain wrote: This isn't true. No one is required by law to register their trademark as a domain name. IANAL, but in my discussions with lawyers focused on trademark law, in effect they are required. The perception that they are not defending their rights effectively means they abandon them. Defending their trademark doesn't necessarily mean registering every possible domain with the trademark in it, but it does usually mean going after other people who register a domain with the trademark in it. Agreed, but given the reality of legal fees the cheapest way to defend a trademark is to register it in every domain. (Although there is always the slight problem that domain names are globally unique while very few trademarks are.) While they are unique within the context of each registered country. So far, I still haven't heard a _technical_ reason against these TLD's. The technical argument here is flattening of the name space with the associated concentration higher up the tree. So what angle hierarchy is desirable? Obviously a completely flat space isn't good because the zones get too large, but a very deep space isn't either as it takes more time to recurse through. A good research topic ;) gut feel says 3-5, but YMMV /flame-suit-on/ Rather than granting new TLDs, there should be an effort to deprecate the existing non-cc TLDs and move everyone out within 3 years. The historical artifact of a failed experiment is no reason to continue down that path. So what is the rationale for organizing ourselves based on our respective countries? Trademark law is already aligned that way. If I may borrow your suit for a minute, I have another suggestion: no hard limits on TLDs, but every organization only gets to have a domain name in one TLD. So the practice of registering domain.* would have to end. And nobody can register more than one domain per year. This would have the side effect of slowing down the benefactors of the spammers. Tony ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
[Ietf] TLDs a thing not to do
Karl A said: Anybody who wants a new TLD should have to pledge allegance to the end-to-end principle (i.e. no new sitefinders) and promise to adhere to applicable internet technical standards and practices. Dan K says: The idea of harvesting bad DNS accesses as a business plan never occured to be until I saw it done. Not a really obvious thing. Anyway, Static, a little dynamic, or real time reconfigurable... DNS URL's should for sure regard this end-to-end thing seriously. Problem is, creativity can probably generate a lot of border cases, partially legit dynamic reallocations. Obviously, the idea the people involved are the arbiters is the real test. It would be interesting if somebody (ex. grad student working on a Masters in economics), would try to root thru the DNS issues from first principles. As an example, a read the Japanese TLD doesn't recycle domain names. When illigitimate, they get parked forever? Anyway, reducing the incentive to Cyber squatting, without needing a quasi-judicial system... that sort of thing; would be interesting as a thesis or three. But, well, I do thing a .XXX one thats expensive (pun intended), like sin would be useful. Of course, if the uptake rate was lousy... that would prove a lot. Its occurred to me multiplying TLD's has this odd divide by N issue to it. If you have X.foo you often want X.bar as well. So, if the DNS forced each fixed IP to be bound only to zero or one DNS, this would allow TLD's to be added with less moaning. interesting. Dan ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
Hi. While this discussion on the IETF list has been very interesting, it is probably worth noting that the odds of ICANN staff following the IETF list to the extent needed to pull out this thread and make use of it are not high. Instructions for making comments that they, and presumably the evaluators, will see are at http://www.icann.org/tlds/stld-apps-19mar04/stld-public-comments.htm That page contains both addresses for making general comments and addresses for specific comments on each proposal, along with pointers to archives of comments made so far. The comment period on the specific applications and forms closes on 30 April (see http://www.icann.org/tlds/new-stld-rfp/new-stld-application-parta-15dec03.htm ). If those of you who have been carrying on this debate want even a chance that your positions will be carefully considered, I suggest going over to ICANN's site and posting appropriate summaries. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RFC 3720 on Internet Small Computer Systems Interface (iSCSI)
A new Request for Comments is now available in online RFC libraries. RFC 3720 Title: Internet Small Computer Systems Interface (iSCSI) Author(s): J. Satran, K. Meth, C. Sapuntzakis, M. Chadalapaka, E. Zeidner Status: Standards Track Date: April 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 257 Characters: 578468 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-ips-iscsi-20.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3720.txt This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model. SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to carry SCSI. This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3720.txt
Last Call: 'State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator' to Informational RFC
The IESG has received a request from the Extensible Authentication Protocol WG to consider the following document: - 'State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator ' draft-ietf-eap-statemachine-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-05-13. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
