Another Bogus DNS wildcard ??
If I ping an invalid host name everything points to: host152.theplanet.com (216.234.246.152) However only from some subnets on the internet and only some of the time. Is this on purpose ?? Is someone getting ready to do a DNS catch all again like (whoever it was) a few months ago ? Its really odd: foo.dom.com exists and dom.com does not exist as a host name. Yet when I ping dom.com it points to and pings the above IP. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Voting (again)
From: Hallam-Baker, Phillip [EMAIL PROTECTED] Because they only get to do it once and have no expectation of repeating. One would think that would make them more likely to make changes, not less. The *whole point* of the NomComm is for it to have roughly the same views as the IETF as a whole, except in a smaller body. The people whoe wrote the constitution certainly thought that there would be a difference. Otherwise they would have done it the obvious way. You clearly are not paying attention to the words smaller body, with the manifold advantages that brings. As I said, ignoring the 2,500 years of experience since that date. Moreover the Athenian constitution was not exactly a success, they murdered Socrates, got whacked in the Peleponesian war and finaly got whacked by the Romans. Given the fragmentary nature of classical accounts I find it astonishing that you would think that you could understand the dynamics of the organizations at all, let alone whether they were satisfactory. Most of the accounts were written by the people whose interests were served by those arrangements. The one dissenting voice, Plato provides a critique so devastating that the same experiment is not tried again for two millenia. Alas, much as pointing out the numerous errors above would interest me, it's a bit far afield for this list. (I'm particularly amused by your calling on Plato for support - he was profoundly anti-democratic.) Let me stay somewhat on topic by pointing out that the US Founding Fathers found the systems of the Greeks (and Romans) worthy of study and inspiration - so there's at least one group of relatively modern political geniuses who disagree with your valuation. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting (again)
Dave, Brian, Er, yes, I think it's known as collective responsibility in some circles. When it is used well, yes. When it is used to reflect the personal preferences of the AD -- no matter the history of the working group -- then it is known as something else, and it happens with some regularity. Perhaps the IETF traditional motto, rough consensus and working code should be revised to make it clear that the rough consensus goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Voting (again)
This discussion shows at least that we should try to build on experience and produce an RFC on the way an intergovernance works. The Internet, and the e-society has changed a lot since the inception of the NIC and IETF (this is what I pointed in referring to Doug Engelbart). Noel can call smaller body what he called boostraps. I think what has changed is them to be not only central, but trying to be exclusive, like in a centralised network, to protect their survival when confronted to decentralisation. And becoming sometime aggressive when facing a distributed problematic. With the NIC, Doug provided the first container for the RFC content (please [re]read RFC 82). IETF then came and shared in the content building lead by Steve Crocker's individual/bootstrap documents. I am not sure all this still matches the global evolution of the network and its today distributed nature. What Phillip seems to document is the difficulty to adapt to the today's demand without some independence, some coopetitivity. Instead of a hierarchical structure for the IETF, inherited from a central NIC and a central IAB with its central IESG, and its unique Truth and its Appeal system, could it not be interesting to have coopetition between various Technical Interest Groups proposing possibly different models and solutions, making practice decide, or dialoguing together when they find a way to converge? I work on distributed Context Reference Centers. They cannot depend on a single culture since they document cultures, yet they should be interoperable. There may not be a single root file (cf. ICANN ICP-3), but we advisably need a single structured root matrix. We need the same kind of hyperlink approach/support. XML is may be a good way to build and negotiate common infos, but it is not a good vector for sharing them (all the more in different scripts and languages). We do not want a fragmentation, but we do not want either (a) rigid domination (-s, as actually there is a not much innovative culture but many different camarilla). IMHO a technical and RD intergovernance where various independently governed visions can work and mutually benefit from each others, should be the adequate solution. This is actually what we do today, but not documented. DNS, NAT, VoIP, GRID, P2P, ML.ML... where not invented in using the Internet standard process. I know that the American langage makes no difference between federating and confederating. This may be one of the problem of IETF. For those who make a difference, I submit that the IETF and the Internet standard process suffer from federalism, and would bluntly develop from confederalism, leading to a stable broader variety of compatible, awaited and innovative deliveries. My 2 euro cents. jfc At 14:48 19/04/2005, Noel Chiappa wrote: From: Hallam-Baker, Phillip [EMAIL PROTECTED] Because they only get to do it once and have no expectation of repeating. One would think that would make them more likely to make changes, not less. The *whole point* of the NomComm is for it to have roughly the same views as the IETF as a whole, except in a smaller body. The people whoe wrote the constitution certainly thought that there would be a difference. Otherwise they would have done it the obvious way. You clearly are not paying attention to the words smaller body, with the manifold advantages that brings. As I said, ignoring the 2,500 years of experience since that date. Moreover the Athenian constitution was not exactly a success, they murdered Socrates, got whacked in the Peleponesian war and finaly got whacked by the Romans. Given the fragmentary nature of classical accounts I find it astonishing that you would think that you could understand the dynamics of the organizations at all, let alone whether they were satisfactory. Most of the accounts were written by the people whose interests were served by those arrangements. The one dissenting voice, Plato provides a critique so devastating that the same experiment is not tried again for two millenia. Alas, much as pointing out the numerous errors above would interest me, it's a bit far afield for this list. (I'm particularly amused by your calling on Plato for support - he was profoundly anti-democratic.) Let me stay somewhat on topic by pointing out that the US Founding Fathers found the systems of the Greeks (and Romans) worthy of study and inspiration - so there's at least one group of relatively modern political geniuses who disagree with your valuation. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Voting (again)
Perhaps the IETF traditional motto, rough consensus and working code should be revised to make it clear that the rough consensus goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. Is there still an appeal process on the books by which a WG can challenge an IESG AD decision/direction by appealing to the IAB? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Voting (again)
* With the NIC, Doug provided the first container for the RFC content (please * [re]read RFC 82). It's best not to let ourselves be confused by facts; such mythological history is in turn with the times. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Another Bogus DNS wildcard ??
Date: 2005-04-19 02:11 From: Doug Royer [EMAIL PROTECTED] Message was signed with key 0x72007B99C34AA62D. Status: Bad signature. If I ping an invalid host name everything points to: host152.theplanet.com (216.234.246.152) However only from some subnets on the internet and only some of the time. Is this on purpose ?? Is someone getting ready to do a DNS catch all again like (whoever it was) a few months ago ? Unless there was a recent incident, I think you mean a year and a half ago. See SSAC Report: Redirection in the Com and Net Domains, A Report From the ICANN Security and Stability Advisory Committee (SSAC), 9 July 2004 http://secsac.icann.org/ Its really odd: foo.dom.com exists and dom.com does not exist as a host name. Yet when I ping dom.com it points to and pings the above IP. I'm not seeing that here: # nslookup -type=any dom.com Server: 192.168.1.1 Address:192.168.1.1#53 Non-authoritative answer: dom.com nameserver = ns2.dom.com. dom.com nameserver = ns1.dom.com. Authoritative answers can be found from: dom.com nameserver = ns1.dom.com. dom.com nameserver = ns2.dom.com. # nslookup -type=any dom.com ns1.dom.com Server: ns1.dom.com Address:158.106.50.124#53 dom.com mail exchanger = 10 innm02.dom.com. dom.com mail exchanger = 10 pghm02.dom.com. dom.com mail exchanger = 10 innm01.dom.com. dom.com mail exchanger = 10 pghm01.dom.com. Name: dom.com Address: 158.106.49.17 dom.com nameserver = ns1.dom.com. dom.com nameserver = ns2.dom.com. dom.com origin = ns1.dom.com mail addr = Postmaster.eaoweb.dom.com serial = 2005041305 refresh = 10800 retry = 3600 expire = 604800 minimum = 86400 # whois dom.com Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Domain Name: DOM.COM Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: NS1.DOM.COM Name Server: NS2.DOM.COM Status: REGISTRAR-LOCK Updated Date: 20-oct-2004 Creation Date: 22-jul-1998 Expiration Date: 21-jul-2007 Last update of whois database: Tue, 19 Apr 2005 08:35:25 EDT [...] Registrant: Dominion Resources Services Inc. (DOM34-DOM) P.O. Box 26532 Richmond, VA 23261 US Domain Name: DOM.COM Administrative Contact, Technical Contact: Leigh, James (28863335I) [EMAIL PROTECTED] Dominion Resources Services Inc. P. O. Box 2 Richmond, VA 23261 US (804) 771-4636 fax: (804) 273-2181 Record expires on 21-Jul-2007. Record created on 22-Jul-1998. Database last updated on 19-Apr-2005 12:46:32 EDT. Domain servers in listed order: NS1.DOM.COM 158.106.50.124 NS2.DOM.COM 158.106.45.7 Perhaps there are some bogus and/or stale DNS cache entries (positive and negative). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting (again)
Yakov, Perhaps the IETF traditional motto, rough consensus and working code should be revised to make it clear that the rough consensus goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. You and I were both in the room when the Ethernet-MIB WG LOUDLY objected to Jon Postel having tweaked the Ethernet-MIB to properly align definitions with what the IEEE counters were. The WG chair was rip roaring upset. Here you had rough consensus and running code. How dare others interfere! Of course it was a broken spec, but nevermind that! The WG knew better. Good thing *someone* was minding the store. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting (again)
On Tue, 19 Apr 2005, Eliot Lear wrote: Yakov, Perhaps the IETF traditional motto, rough consensus and working code should be revised to make it clear that the rough consensus goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. You and I were both in the room when the Ethernet-MIB WG LOUDLY objected to Jon Postel having tweaked the Ethernet-MIB to properly align definitions with what the IEEE counters were. The WG chair was rip roaring upset. Here you had rough consensus and running code. How dare others interfere! Of course it was a broken spec, but nevermind that! The WG knew better. Good thing *someone* was minding the store. At the same time reverse is not true, i.e. I do not think IESG should be allowed to make a decision on document on its own if there is no consensus. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting Idea?
Pekka FWIW, I personally prefer humming because my belief is that Pekka unless the rough consensus is sufficiently strong (so that Pekka it's clear no matter which part of the room you stand), the Pekka WG should probably be better off seeking better consensus Strongly agree. me too. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting (again)
An individual has the ability to write a draft. The IESG has the ability to gauge consensus as to whether that draft should become a standard. So in essence they have the capability today. The fact that it is rarely used is a testament to the good judgement these good people display. In other words, at least this part ain't broke. Eliot william(at)elan.net wrote: On Tue, 19 Apr 2005, Eliot Lear wrote: Yakov, Perhaps the IETF traditional motto, rough consensus and working code should be revised to make it clear that the rough consensus goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. You and I were both in the room when the Ethernet-MIB WG LOUDLY objected to Jon Postel having tweaked the Ethernet-MIB to properly align definitions with what the IEEE counters were. The WG chair was rip roaring upset. Here you had rough consensus and running code. How dare others interfere! Of course it was a broken spec, but nevermind that! The WG knew better. Good thing *someone* was minding the store. At the same time reverse is not true, i.e. I do not think IESG should be allowed to make a decision on document on its own if there is no consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting (again)
On Tue, 19 Apr 2005, Eliot Lear wrote: At the same time reverse is not true, i.e. I do not think IESG should be allowed to make a decision on document on its own if there is no consensus. An individual has the ability to write a draft. The IESG has the ability to gauge consensus as to whether that draft should become a standard. Yes and sometimes they have to take a guess if the number of comments in regards to the draft is too few. I'm however talking about situation where there would be enough comments on the it ... So in essence they have the capability today. The fact that it is rarely used is a testament to the good judgement these good people display. In other words, at least this part ain't broke. I did not say it is. I think its quite clear that decision for document to become a standard should be based on BOTH consensus AND agreement of IESG. --- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Voting (again)
Alas, much as pointing out the numerous errors above would interest me, it's a bit far afield for this list. (I'm particularly amused by your calling on Plato for support - he was profoundly anti-democratic.) That is exactly the type of dishonest rhetorical tactic that has caused so many people to become very disillusioned with the IETF: 'I could explain the numerous mistakes you make to you sonny, but I am too important to bother'. Plato was anti-democratic with good reason. The Athenian 'democracy' that was cited as the exemplar degenerated into mob rule and the judicial murder of Socrates. It is in any case a somewhat strange idea to hold to a city state run by a slave owning elite as an exemplar of democratic processes or traditions. Even the Roman Republic allowed the plebs to elect a Tribune. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Voting (again)
From: Hallam-Baker, Phillip [EMAIL PROTECTED] Alas, much as pointing out the numerous errors above would interest me, it's a bit far afield for this list. That is exactly the type of dishonest rhetorical tactic that has caused so many people to become very disillusioned with the IETF: 'I could explain the numerous mistakes you make to you sonny, but I am too important to bother'. Exactly which part of it's a bit far afield for this list did you not comprehend? Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)' to Proposed Standard
The IESG has approved the following document: - 'Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA) ' draft-ietf-sigtran-m2pa-13.txt as a Proposed Standard This document is the product of the Signaling Transport Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. Technical Summary This document provides an IP-based surrogate for MTP2, a link-layer protocol used in SS7 networks, in order to enable IP-based telephony signaling points t use MTP3 over IP networks in the same fashion that they use MTP3 over MTP2 in SS7 networks. The MTP2 User Peer-to-Peer Adaption Layer (M2PA) runs over SCTP, and relies on SCTP assocations to simulate SS7 links. This protocol would be used by signaling gateways that interwork between SS7 and IP networks, or possibly native IP replications of SS7 endpoints. Working Group Summary The SIGTRAN working group supported the advancement of the document, and provided significant inputs in the final stages of its development. Protocol Quality This specification was reviewed for the IESG by Jon Peterson. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
