ZOOM://IETF.Fact.Check "Improving HTTP starts with speed."
ZOOM://IETF.Fact.Check http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-00 "Improving HTTP starts with speed." Improving the Inter.NET starts with speed. "HTTP Speed+Mobility," Locator-ID Separation ? Locator (60) + ID (68) 60-bit Symmetric Addressing in the IPv4 160-bit Header 68-bit Symmetric Addressing in the IPv16 320-bit Header with Data DNS ~ 60+68 ~ VRHL+000.T1.111+PORT12+ASN30+FRAG6 + LAN4+60+CPE4 "The proposal starts from both the Google SPDY protocol and the work the IETF has done around WebSockets." If you start with a HAMMER everything may look like a NAIL. Improving the Inter.NET starts with speed. A Comprehensive (Modern) Architecture may be better than the old Hammer and Nails? Removing TCP may help. Re-Tooling UDP for Peer-2-Peer may help. [The 12-bit Port value also rides in the old Identification Field in the IP Header - are three copies needed?] 2 Protocol Bits frees up 6 bits for addressing 4 TTL Bits encourages less hops and frees up addressing bits Less.is.More may result in Speed IPv6 is not built for Speed - Yet people sure are trying to sell it - Do consumers want it ? They may prefer a Net.Work as opposed to a Not.Work ZOOM://IETF.Fact.Check "Improving HTTP starts with speed."
ZOOM://IETF.Fact.Check ? 2012 State of the Art according to the ISOC ?
ZOOM://IETF.Fact.Check ? 2012 State of the Art according to the ISOC ? http://www.internetsociety.org/events/internet-society-panel-openid-and-oauth-ietf-83 Internet Society Panel on OpenID and OAuth @ IETF 83 Date: 27 March 2012 - 11:45am Location: Le Palais des Congres, Paris, France, Room 242B Time: 11:45 - 12:45 local time ZOOM://IETF.Fact.Check
Re: Meetecho support fot Plenary session
Hi again, the full recording (synchronized video, audio, slides and jabber room) of the Operations and Administration Plenary session at IETF-83 is available. You can watch it by directly accessing the following URL: http://ietf83.conf.meetecho.com/index.php/Recorded_Sessions#ADMIN_PLENARY_IETF83 For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to t...@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com Il 28/03/2012 16:38, Meetecho IETF support ha scritto: Hi all, we made a last minute arrangement and we're supporting the Operations and Administrations Plenary through Meetecho! To participate: http://srv137.conf.meetecho.com/WebLite/login.jsp?ietf=plenary Regards, the Meetecho team
IETF.FACT.CHECK ....839 new Top Level Domains or more...plus the DIRTY.BIT
ZOOM://IETF.Fact.Check The Latest Number of TLD Application System Registrants "As of 25 March 2012 the number of registered users in the online TLD Application System (TAS) stands at 839. However, this number does not necessarily represent the total number of applications since each registrant can apply for up to 50 new generic Top-Level Domains." http://newgtlds.icann.org/en/program-status/statistics Only the TOP 4096 TLDs will be carried in the new DNS http://archive.icann.org/en/comments-mail/icann-current/msg00342.html That used to be called Best.of.Breed. Check out the TLDs leaked on the screens in this video from Music.Night and the DIRTY.BIT** (aka the Evil.Bit) http://www.youtube.com/watch?v=vpTEtM_SXrU&feature=player_embedded Domainers have much better parties than the ISOC and IETF - and Domainers have 3D and Avatars and web-cams and Peer-2-Peer http://ZOOM.NAME The DIRTY.BIT is set in the packet header after the Source and Destination fields change places as the One-Way packet routes the second half of the 60-bit path. ZOOM://IETF.Fact.Check
IETF.Fact.Check on the ZOOM://BOX Protocol(s)
IETF.Fact.Check on the ZOOM://BOX Protocol(s) ZOOM://Protocols There are two dominant header sizes 160-bits and 320-bits It takes three 160-bit headers to form a 480-bit DHT*** Key or a 160-bit header and a 320-bit header The first 4 bits of the 160-bit header are SDSD for Source and Destination Addressing A VVRR view is also used for Version and Ring A legacy value of 0100 is Version 01 and Ring 0 to Ring 0 - Source 0 Destination 0 a value of 0011 is Version 00 and Ring 1 to Ring 1 - Source 1 Destination 1 - used behind the first 10/100 firewall 100/8 ...other values of the 4 bits are left as an exercise for the reader... Your stand-alone ZOOM://BOX has all the details and documentation and NO back-haul connection - Mules carry the messages - sometimes very slowly and long distances... http://WheresGeorge.com === ***DHT - Distributed Hash Table "The Network IS the Registry" A Virtual Disk Drive with 480-bit Sector Addresses (KEY) 1024 Byte DATA Blocks 4 Bitt TIME Setting (Day | Week | Month | Year) Two Simple Operations PUT(KEY,DATA,TIME) GET(KEY) The global network stores the DATA via the KEY for the period of TIME. The DATA is returned when the proper KEY is provided via GET(KEY). ACID - Atomic, Coherent, Isolated & Durable apply. It all just works, like magic. Replication of DATA, KEY management, etc. is handled via the Peer-2-Peer Network of Nodes. THERE IS NO CLOUD. FOG would be a better description. Each user contributes part of their server and power capacity. The maximum TIME is one Year + one Month + one Week + one Day (). A TIME of () specifies the default BIT Throttle - Genesis BITT Block Chain. Applications build on top of the DHT to provide other virtual services, such as the DNS - Domain Name System. The 480-bit KEY can be encoded via an 80 Symbol ZOOM.NAME. Three 160-bit BITT Addresses can be combined to form a unique 480-bit KEY. Operations are THROTTLED by BITTs (and Peer-2-Peer Stooges)
IETF.Fact.Check on the ZOOM:// Scheme and ZOOM://BOX Architecture and the Inter.NOT
ZOOM://IETF.Fact.Check IETF.Fact.Check on the ZOOM:// Scheme and ZOOM://BOX Architecture ZOOM:// is a Scheme not a Protocol The ZOOM://BOX Architecture as No Back-Haul connection to the Legacy Inter.NET When you deploy your free open-source ZOOM://BOX and invite wireless users they connect to the Inter.NOT NOTE: the .NOT Top.Level.Domain is "Confusingly Similar" to the .NET Top.Level.Domain so you are banned from using it The ZOOM://BOX Architecture uses modern Peer-2-Peer and MULE Technology (aka Sneaker.Net) Users are the MULES and they carry Objects from place to place ZOOM=15.3.3.13 or 0xF33D = P2P Port 62,269 The Official ZOOM://DNS 4-bit Alphabet "ETAO^NRIS^HDLF^CMUZ" "0123^4567^89AB^CDEF" Note: The Letter "Z" is a WildCard (.-X*) Use ZNZ for .NZ or ZOOM://NZ ZOOM=15.3.3.13 or 0xF33D = P2P Port 62,269 ZOOM://DNS on Port 62,269 COM=12.3.13 or 0xC3D = P2P Port 3133 NET=4.0.1 or 0x401 = P2P Port 1025 ZNZ=15.4.15 or 0xF4F = P2P Port 3919 There is no "G" for .ORG or "B" for .BIZ NO $$.IANA.$$ is needed to hand-select Ports EXPLORE://BLOCK0 http://blockexplorer.com/b/0 === 10/100 Ethernet 10/8 100/8 http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt There are 10 kinds of people in the world those that understand binary and those that do not There are 100 kinds of people in the world those that see 100 as 4 and 99 others Migrating to Binary prefixes with IPv4 addresses can be interesting. 10.9.8.7.6 it takes 2 bits to store 10 How many bits does it take to store 100 ?
Re: IETF.Fact.Check - .COM .NET .ORG Legacy DNS vs Peer-2-Peer DNS
On 28/03/2012 20:21, Jim Fleming wrote: > ZOOM://IETF.Fact.Check What I'd like to know is whether the ZOOM:// protocol is IPv8 compatible. Nick
IETF.Fact.Check - .COM .NET .ORG Legacy DNS vs Peer-2-Peer DNS
ZOOM://IETF.Fact.Check IETF.Fact.Check - .COM .NET .ORG Legacy DNS vs Peer-2-Peer DNS 1. The .COM .NET .ORG ICANN (IANA) U.S. Department of Commerce contracts are coming up for renewal.[1] 2. The Legacy Client-Server DNS is OUT-DATED and highly monetized for Meat.Space.Mammals 3. Netizens clearly prefer True.Internet.Technology with a Peer-2-Peer Architecture 4. Peer-2-Peer DNS and Virtual Currency are finally gaining market-share with BitCoin and NameCoin using Bit.Throttles.[2] 5. Migration of existing .COM and .NET owners to Peer-2-Peer DNS negates the need for .COM and .NET contract renewals. 6. Migration of existing .ORG owners to Peer-2-Peer DNS appears to be a waste of time. 7. Peer-2-Peer DNS begins with Digital.Wallets and many companies are working on variations and services.[3] ZOOM://IETF.Fact.Check - It does not appear that the IETF has any current interest in Peer-2-Peer DNS ZOOM://IETF.Fact.Check - The .ORG contract renewal could impact the ISOC (IETF) and a $34,000,000 annual donation from the PIR (set up by the ISOC). People with $600,000 annual non-profit compensation packages may oppose any changes. SEARCH://BITCOIN http://bitcoin.org/ SEARCH://NAMECOIN https://en.bitcoin.it/wiki/Namecoin [1] http://www.icann.org/en/news/announcements/announcement-27mar12-en.htm [2] http://bittco.yolasite.com [3] http://code.google.com/p/bitcoin-wallet/
response set assertions and extensions
3.1. Assertions The "email-id" reputation application recognizes the following assertions: ... 3.2. Vocabulary Extensions The "email-id" reputation application recognizes the following OPTIONAL extensions to the basic vocabulary defined in [I-D.REPUTE-MODEL]: Reflecting on these two sections and especially the reference to vocabulary (response set) in -model: Somehow I didn't find a base response set (vocabulary) or base assertions in the model document. I'd expected to have found a core set of information types that would be common across all uses of Repute. Did I miss what is actually in -model? If not, shouldn't there be a base response set (and maybe assertions)? d/ ps. i hope it's obvious i'm not wearing a hat, but i'm also just asking questions... -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IAB responds to ICANN questions concerning "The interpretation of rules in the ICANN gTLD applicant guidelines"
Please be advised that this page does not print correctly using IE8 on XP/SP3 ... this is the sort of thing I reserve for study when I'm not online or trying to give my eyes a break. On Wed, 28 Mar 2012, IAB Chair wrote: > The IAB has responded to ICANN questions concerning "The interpretation of > rules in the ICANN gTLD applicant guidebook": > > https://www.iab.org/documents/correspondence-reports-documents/2012-2/response-to-icann-questions-concerning-the-interpretation-of-rules-in-the-icann-gtld-applicant-guidebook/ >
Meetecho support fot Plenary session
Hi all, we made a last minute arrangement and we're supporting the Operations and Administrations Plenary through Meetecho! To participate: http://srv137.conf.meetecho.com/WebLite/login.jsp?ietf=plenary Regards, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com
Re: IPv6 Zone Identifiers Considered Hateful
Francis Dupont wrote: In your previous mail you wrote: Looking at the link-local address, it appears to be constructed from the interface's MAC address, and basically nothing else. ^^^ => note the IEEE spec says device MAC address and if the common interpretation is device == NIC there is at least one vendor where device == machine, i.e., you get the same MAC address so same link-local address on all the 10 interfaces of a 10 interface box! Regards francis.dup...@fdupont.fr PS: I maintain my opinion: zone identifiers don't suck, link-local addresses used where they should not definitely suck. Maybe link local addresses are erroneously used where one should use RFC4193 (Unique Local IPv6 Unicast Addresses) with L=1? (I mean where link local addresses are inconvenient but not necessary.) I.e. something like FDxx::::id where xx:: is 40 random bits that you pick-up as you wish, is a subnet id for your (local) routing scheme id is the 64 bits interface ID ... It's a suggestion. I guess the trouble of assigning addresses in this way is much smaller than tracking link local addresses derived from hardware serial numbers. The interface ID assignment strategy/tools with RFC4193 is deemed to be close to the strategy/tools useful for globally routable addresses. Is this well explained in the IPv6 tutorials? Regards, -- - Thierry Moreau
Re: IPv6 Zone Identifiers Considered Hateful
In your previous mail you wrote: > Looking at the link-local address, it appears to be constructed from > the interface's MAC address, and basically nothing else. ^^^ => note the IEEE spec says device MAC address and if the common interpretation is device == NIC there is at least one vendor where device == machine, i.e., you get the same MAC address so same link-local address on all the 10 interfaces of a 10 interface box! Regards francis.dup...@fdupont.fr PS: I maintain my opinion: zone identifiers don't suck, link-local addresses used where they should not definitely suck.
