Re: SPF deployment by Oct. 1 ?
Thank you gentlemen. > try the marid working group... > > http://www.ietf.org/html.charters/marid-charter.html John B
Network Solutions, Inc. Registrar (R122-LRMS) Status: INACTIVE ?
Hey Folks, It appears that NSI isn't talking to the GTLD, got any ideas? Sponsoring Registrar: Network Solutions, Inc. Registrar (R122-LRMS) Status: INACTIVE ? Status: OK All the best, Peter Schroebel
Re: SPF deployment by Oct. 1 ?
try the marid working group... http://www.ietf.org/html.charters/marid-charter.html On Sat, 24 Jul 2004, John Bittenbender wrote: http://www.infoworld.com/article/04/07/22/HNmicrosoftid_1.html As a side note, I notice that the article mentions a submission to the IETF but I haven't seen any RFC's related, if there is one out there can someone please point it out for me? I didn't see anything obvious here: http://www.ietf.org/html.charters/dnsop-charter.html or here: http://darkwing.uoregon.edu/~llynch/dnsop/ Looking in the wrong place? John Bittenbender P.S. If I missed a mail about this somewhere along the path please disregard or edjamacate me off-list. -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: SPF deployment by Oct. 1 ?
On Sat, Jul 24, 2004 at 09:49:41PM -0400, John Bittenbender wrote: > > http://www.infoworld.com/article/04/07/22/HNmicrosoftid_1.html > > As a side note, I notice that the article mentions a submission to the > IETF but I haven't seen any RFC's related, if there is one out there > can someone please point it out for me? http://www.ietf.org/html.charters/marid-charter.html http://spf.pobox.com/ - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
SPF deployment by Oct. 1 ?
http://www.infoworld.com/article/04/07/22/HNmicrosoftid_1.html As a side note, I notice that the article mentions a submission to the IETF but I haven't seen any RFC's related, if there is one out there can someone please point it out for me? I didn't see anything obvious here: http://www.ietf.org/html.charters/dnsop-charter.html or here: http://darkwing.uoregon.edu/~llynch/dnsop/ Looking in the wrong place? John Bittenbender P.S. If I missed a mail about this somewhere along the path please disregard or edjamacate me off-list.
Re: VeriSign's rapid DNS updates in .com/.net
Randy Bush <[EMAIL PROTECTED]> writes: > > I'm not talking about intended beneficiaries. I agree with your statement > > when applied to intended beneficiaries. I'm talking about the character > > of the preponderance of actual beneficiaries, whether measured by number > > of domain registration events per unit time, or number of dollars of income > > enabled by the speediness of the "fast update" VeriSign is now announcing. > > paying net customers want quick adds/updates/deletes. verisign's > competitors offer this. versign will offer this. get over it. Nothing wrong with showing the last 30 days worth of changes via whois; it would address Paul's concerns and make it painfully obvious when someone is monkeying around. ---Rob
Re: VeriSign's rapid DNS updates in .com/.net
> I'm not talking about intended beneficiaries. I agree with your statement > when applied to intended beneficiaries. I'm talking about the character > of the preponderance of actual beneficiaries, whether measured by number > of domain registration events per unit time, or number of dollars of income > enabled by the speediness of the "fast update" VeriSign is now announcing. paying net customers want quick adds/updates/deletes. verisign's competitors offer this. versign will offer this. get over it. randy
Re: VeriSign's rapid DNS updates in .com/.net
> > the primary beneficiaries of this new functionality are spammers and > > other malfeasants > > ... The primary beneficiaries are all ^ intended > current and future .com/.net domain holders: I'm not talking about intended beneficiaries. I agree with your statement when applied to intended beneficiaries. I'm talking about the character of the preponderance of actual beneficiaries, whether measured by number of domain registration events per unit time, or number of dollars of income enabled by the speediness of the "fast update" VeriSign is now announcing. > ... I also stated in that message that VeriSign has no intention of > changing the current 48-hour TTL on delegation NS RRsets in .com/.net. Right. And I hope you are able to stick to that plan in the face of what I think will be gigantic pressure, from both registrants and competitors, to lower it. > I agree with Daniel's earlier statement that this is an education > issue. Does anyone want to co-author an Internet-Draft on the topic > of choosing appropriate TTLs? I can't think of anyone who could do it better than you could, Matt. I know I offered to help a while back, but we never really got started on it, and after being named as a "sitefinder co-conspirator" in your lawsuit against ICANN, I think I'll hold off on co-authoring anything with any VeriSign employee for the time being.
RE: T1 short-haul vs. long-haul - jack terminology
> [EMAIL PROTECTED] wrote: > I've seen where STP (shielded twisted-pair cabling) purists have > succeeded in having shielded cabling used, only to screw it up by > mis-applying the necessary grounding connections causing more > problems than they solved. I have also seen funny issues with RJ48C or RJ48X UTP, where the 7-8 pair is used for grounding. Same as STP when the shielding and/or the equipment are not properly grounded, it can be a lot of fun. Makes a real good antenna, to begin with. > At one point the vendor's rep pointed to the fine print in the > operator's manual. It stipulated that the only cabling that would > be supported between the gateway and the telco demarc was > individually shielded twisted pairs. When it was discovered that > the client had chosen to use UTP patch cords to extend their T1 > demarcs some fifteen or so feet, the vendor would not even begin > to diagnose the problem further in depth until the client replaced > those cables with shielded ones. Which emphasizes the need of having the demarc extended to the same room where the equipment is, as replacing fifteen footers is easy, when replacing a 300-ft run over ten floors is another story. > as much as it is the significance of abiding by vendor warranty > conditions (if you've agreed to them initially, even tacitly, in > your contracts and SLAs) when selecting a T1 cabling solution. Indeed. Michel.
RE: T1 short-haul vs. long-haul
>> Michel Py wrote: >> I stopped by a T1 MPOE on my way home and took a few photos. > Michael Loftis wrote: > hate to say it but what is pictured is not a smart jack, > it is as you say a glorified patch. Care to post a photo of what you think a smartjack is? > a *TRUE* smart jack DOES have the tiny bit of circuitry > necess'y to cause it to loop the line back when nothing > is connected to it, some can do it via line signaling as well. This feature is part of the NIU. What makes the jack smart is that it's connected to a smart NIU (the older full-height type 400 were not smart). Michel.
RE: T1 short-haul vs. long-haul - jack terminology
> Forrest W. Christian wrote: > In Qwest land, NIU, Smart Jack, and Demarc (unless > "extended") are all in the same physical rack. > When you get a T1, qwest installs an appropriately > sized shelf. This shelf holds the adtran and > westell devices shown in earlier posts. For example, > we have one site with quite a few T1's, which they > installed a rack like the one pictured at: > http://www.westell.com/images/osp/dsawm214.jpg > Note the RJ45's on the bottom. These are the demarc > point for the circuit. When qwest says "insert a > loopback plug at the smartjack" or "unplug from the > smartjack" or whatever, they mean this device. Thanks for posting the photo. A few comments: This all-in-one unit is mechanically different but electrically equivalent to the split NIU/smartjack photos I posted before; the smartjack part which is the lower part labeled "customer interface" is a dumb PCB no smarter than the Hyperedge glorified patch panel I posted a photo of. An interesting feature of this chassis is that the rightmost card (which appears to be a full-height one) seems to be a channel bank. A channel bank is an HDSL card same as the general-purpose NIU but also demuxes the 24 TDM DS0s in that T1 and outputs them as individual phone lines, which could be the purpose of these 50-pin Centronics connectors on the smartjack part, on the right of the RJ-48 jacks. > Qwest can loop or unloop and do other tests to > this device. Indeed. As I said earlier, the brain of the smartjack is the NIU card. For antique equipment, here's an RJ48 T1 loopback plug: +-+ ++-++ ! | | | | | | | | ! ! | | | | | | | | ! ! 1 2 3 4 5 6 7 8 ! ! | | | |! ! | | | |! ! | | | |! +--|-|---|-|+ | | | | +-)---+ | | | +-+ > On the newer HDSL cards, they can also plug a laptop > in to get performance data, and I believe they can > also get this data from the CO end. All depending on the age and feature set of the NIU card. > Older ones have RJ45's on the right side and the > cards are thicker - a lot thicker. Yes. As well as the photos I posted earlier, these are "half-height" type 400 NIU cards. The older ones were twice as big due in part to the size of then-manufactured large capacitors. > Also of note, I haven't seen qwest deploy anything but > HDSL2 cards for quite a while. This basically means a > full duplex, full-speed T1 over a single pair of copper > with a quarter of the repeaters (12K wire feet without > a repeater). In California my guess is that the current strategy is to leave the existing dual-spans in place and deploy fiber, single-spans being for residential use. At home I am 10kft from the CO and I get 3meg aDSL over the good old pair. Recently I had a customer order a frac-DS3 (12 mb/s) from Sprint; when you do the math it's only 8 T1s, not that much after all and will easily fit into the chassis you pictured. Instead of copper the LEC (SBC) brought in a SONET OC-12 ring and extended the demarc in the customers data room (including the optical platform, they spliced the fiber at the MPOE), which is great if the customer wants to crank up the volume. Michel.
Re: T1 short-haul vs. long-haul - jack terminology
On the matter of the type of cabling to be used between the Telco Demarc and the CPE, I have found this to be one of the most shrouded of all areas in telecom standards. The jabber and deliberations that have taken place over this issue border on folk lore and hijinx, and could fill a plant man's notebook in no time flat. Prior to metallic T1s being made available to end users by the incumbent carriers (this is going back some tweny years or so), the carrier itself extended cabling to the point of the customer's CPE/DTE. Reportedly (and in fact, most of the time), they used individually shielded pairs, actually comprising two separate cables - one for each direction. The standard that was used in the latter case was the ancestor of today's ANSI 401.1 and it applied to the "telco's" EMI/RFI compliance responsibilities, not the customer's. Later on, the EIA/TIA drew up a set of commercial building wiring standards in the way of TIA568, but neglected to include the T1 niche in its writings, relegating it to an orphan state. Consequently, there has been much confusion amongst enterprise IT staff and Telco guidelines, not to mention the list of different recommendations that manufacturers of CSUs and DSUs place in their glossies. I've seen where STP (shielded twisted-pair cabling) purists have succeeded in having shielded cabling used, only to screw it up by mis-applying the necessary grounding connections causing more problems than they solved. And I've seen where wall fields of T1 demarcs in an MDF room have successfully been deployed using nothing more than Cat3 UTP between spaces that were thirty stories apart. Through all of this, the one area that is often overlooked is the area where vendors of network hardware stipulate what type of cabling they will support and will _not_ support, with pair shielding used as a determining factor. About two years ago, after a client successfully deploying several shelves of T1s for most normal enterprise purposes, they found that one certain VoIP gateway was encountering excessive errors. After all self tests came up negative, as did an end to end test on the T1, and after swapping out those T1s and their respective patch cables, the problem persisted. At one point the vendor's rep pointed to the fine print in the operator's manual. It stipulated that the only cabling that would be supported between the gateway and the telco demarc was individually shielded twisted pairs. When it was discovered that the client had chosen to use UTP patch cords to extend their T1 demarcs some fifteen or so feet, the vendor would not even begin to diagnose the problem further in depth until the client replaced those cables with shielded ones. Once replaced, the problem appeared to subside as evidenced by a lower incidence of errored seconds initially (but still unacceptable from my view), only to resurface at a later time to the same state of impairment that it was before. But the salient point here isn't whether or not the problem was solved, as much as it is the significance of abiding by vendor warranty conditions (if you've agreed to them initially, even tacitly, in your contracts and SLAs) when selecting a T1 cabling solution. If anyone on this list has a more authoritative source that stipulates the type of cabling to be used for the section in question (between the demarc and the CPE), perhaps something that has been written more recently than the experience I cited above, it would be appreciated. [EMAIL PROTECTED] -- On Fri, 23 Jul 2004 23:52 , 'Forrest W. Christian' <[EMAIL PROTECTED]> sent: > >On Fri, 23 Jul 2004, Christopher Woodfield wrote: > >> OK, from my reading in Newton's Telecom Dictionary, it appears that NIU >> is a generic term for "whatever the customer plugs their cable into", >> be it a powered or a dumb device. Mea culpa. >... >> "...installed on the premises as a semi-intelligent demarcation >> point, >> the smart jack is completely passive until activated remotely by a >> digital code, typically something like 'FACILITY 2', sent down the T-1. >> This code activates a relay [that loops the circuit]." >> >> That may not accurately define the Adtran and Westell devices that are >> pictured (they appear to have additional features beyond this), but >> it's a good guess they provide the remote loopback function described >> above in addition to the monitor points and management console port. I >> also doubt that the Hyperedge unit pictured does so, although I can't >> seem to find any online documentation on the unit (it is, as you >> described it, a 'glorified patch panel'). Feel free to correct me. > >In Qwest land, NIU, Smart Jack, and Demarc (unless "extended") are all in >the same physical rack. > >When you get a T1, qwest installs an appropriately sized shelf. This >shelf holds the adtran and westell devices shown in earlier posts. For >example, we have one site with quite a few T1's, which t
Re: Campus size Wireless LAN
At 02:01 PM 7/21/2004, Eric Brown wrote: Anyone have experience with Proxim's tsunami quickbridge for wireless connectivity between buildings at line of site distances under 1 mile? It's cheaper than Cisco and looks good on paper. Looking for the good bad and ugly. Thanks in advance! Cheaper than Cisco? Doesn't take much! ;) Is this point to point or point to multipoint? One link, or multiple links? There's plenty of products to do campus WLAN's, and the Quickbridges are pretty good. Proxim also has the MP11 and MP11a line, which I believe is cheaper than the Quickbridges, but uses the same spectrum. Probably has slightly lower throughput, but don't know if that's as important. The Quickbridge is an older product, and as someone said, the interface shows it. The newer products (AP600, AP2500, AP4000, and the MP11/MP11a's) all have a very similar web interface that's fairly intuitive. All of it will work (especially at <1mile LOS), it's a question of what other features you're expecting/looking for. Rob Nelson [EMAIL PROTECTED]
Re: DNC service providers
> http://www.thebostonchannel.com/news/3561756/detail.html > > The event monitor gives all the agencies instant access to any event to > local police, fire officials, the FBI and dozens of law enforcement > representatives working with utility providers. "Public safety officials > from our carriers -- Verizon, Nextel, AT&T, NSTAR, Keyspan," said Perro. There's a related article in this morning's Boston Globe that talks about the role of some private businesses. Here are the first few paragraphs... State firms form groups for disaster response http://www.boston.com/business/globe/articles/2004/07/24/state_firms_form_groups_for_disaster_response/ If disaster strikes at next week's Democratic National Convention, Boston-area businesses will have an unprecedented new seat at the emergency response command center -- and tens of millions of dollars in material and services lined up to help respond... After months of discussions, the imminent arrival of 35,000 delegates, journalists, and politicos has spurred more than 20 area corporations to form a new Massachusetts Business Response Network. It inventories everything from warehouse space and hazardous-materials suits to excavators and portable generators -- and executives with skills suitable for crisis response -- that businesses are prepared to make available to public safety officials in the event of a terrorist strike or other disaster. The network, whose backers include EMC Corp., Genzyme Corp., Partners HealthCare, Raytheon Co., and Shawmut Design and Construction Inc., is modeled on a similar New Jersey effort completed last year. That sought to avoid, in the case of a disaster, a repeat of the logistical snarls as hundreds of businesses volunteered people, equipment, and goods to respond to the Sept. 11, 2001 terrorist attacks on the World Trade Center. The Democratic convention is also driving another unprecedented example of coordination between area businesses and public safety. As state emergency management officials open a command center in an underground bunker in Framingham, representatives from a business group called the New England Disaster Recovery Information Exchange will for the first time have a designated seat alongside agencies like the State Police, Massachusetts National Guard, US Coast Guard, and the state Department of Public Health. ...
Re: that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net ) (longish)
On 23.07 22:30, Simon Waters wrote: > > The abstract doesn't mention that the TTL on NS records is found to be > important for scalability of the DNS. Sic! And it is the *child* TTL that counts for most implementations.
