Re: DNS pollution

2006-10-13 Thread Olaf M. Kolkman
On 11Oct 2006, at 7:03 PM, Keith Moore wrote: In the past month or so I've run across two separate ISPs that are apparently polluting the DNS by returning A records in cases where the authoritative server would either return NXDOMAIN or no answers. The A records generally point to an

Re: I understand that there is an ISO MOU with the IETF - I want to see it...

2006-10-13 Thread Brian E Carpenter
I apologise for this message having reached the list, since the person who sent it is currently supposed to have his posting rights suspended. An administrative issue. Brian ___ Ietf mailing list Ietf@ietf.org

Re: DNS pollution

2006-10-13 Thread Frank Ellermann
Olaf M. Kolkman wrote: I think it may be a good idea to also create an IAB document that documents all these DNS issues that have to do with namespace tricks. The IAB comment on Sitefinder [1] could act as the core of that document. I'd be happy to work with a few volunteers to make that fly.

Re: I understand that there is an ISO MOU with the IETF - I want to see it...

2006-10-13 Thread Harald Alvestrand
todd glassey wrote: Thats what I thought John but when Verisign's Corporate-Government Liaison, who is a very reputable attorney, pops up and says there is one I have to ask. Google searching seems to indicate that this role belongs to Michael Aisenberg. I suggest that anyone who cares to

Re: I understand that there is an ISO MOU with the IETF- ...

2006-10-13 Thread Brian E Carpenter
Of course, see (2) above. But the question was about a formal agreement with ISO, and I am reasonably certain that no such agreement exists. Certainly it did not exist in the mid-, or even late-, 90s. It never existed. Liaison letters with a few JTC1 SCs were signed around 1992. Brian

Re: I understand that there is an ISO MOU with the IETF - I want to see it...

2006-10-13 Thread Theodore Tso
On Fri, Oct 13, 2006 at 01:50:46AM -0700, Harald Alvestrand wrote: (Note - there is an ITU-T Recommendation that talks about almost exactly what is being described. It is documented in RFC 3356, which is shared text with ITU-T A-Series Supplement 3. This is, however, not an MOU; it's an ITU

Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)

2006-10-13 Thread Alan DeKok
Brian E Carpenter [EMAIL PROTECTED] wrote: What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? Yes, that's a problem with NEA. No, it's not a problem for

RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)

2006-10-13 Thread Frank Yeh Jr
Greetings, Both of the existing flavors of NEA-type protocols (Cisco NAC and TNC) provide some mechanisms for integrity checking after the admission process has completed and removing an endpoint's privileged access if it falls out of compliance. So IMHO, support for post-admission integrity

Re:[Nea] WG Review: Network Endpoint Assessment (nea)

2006-10-13 Thread yinhan 34728
I have a very basic fear that this working group is getting chartered with a bunch of aims added by people who will not take on the task of doing the work. After private discussion with folks involved, my sense is that the very core of this work is a perceived need to be able to pass

Re: [Nea] WG Review: Network Endpoint Assessment (nea)

2006-10-13 Thread Frank Yeh Jr
Ted Hardie [EMAIL PROTECTED] wrote on 10/08/2006 11:45:37 PM: [snip] my sense is that the very core of this work is a perceived need to be able to pass opaque strings between a host and the network prior to the host attaching. Yes, that is the essence of this work which is what we need

Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)

2006-10-13 Thread Arnt Gulbrandsen
Alan DeKok writes: The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the

Re: draft-kolkman-appeal-support

2006-10-13 Thread David W. Hankins
On Fri, Oct 13, 2006 at 10:31:57AM +0200, Frank Ellermann wrote: http://tools.ietf.org/html/draft-kolkman-appeal-support ...it's just wrong. I think he's got a good idea. It maybe could use some tweaking. The IETF should stop doing things that are not relevant to its constituency and serve

Re: draft-kolkman-appeal-support

2006-10-13 Thread Keith Moore
yeah, I sympathize with the desire to be less vulnerable to asymmetric attacks, and also with the general notion that if your appeal has sufficient merit to sway the iesg, iab, etc then you can probably find some people outside those bodies who think your appeal has merit. I also believe that

Re: Last Call: 'Extensible Provisioning Protocol (EPP)' to Draft Standard (draft-hollenbeck-epp-rfc3730bis)

2006-10-13 Thread Sam Hartman
Hi. RFC 3967 is not applicable in cases where the appropriate solution is to advance the normative downreference on the standards track. In each case where you have a normative down reference, to a PS, please explain why advancing that document is not the appropriate solution. It is my opinion

Re: draft-kolkman-appeal-support

2006-10-13 Thread David W. Hankins
On Fri, Oct 13, 2006 at 01:16:53PM -0400, Keith Moore wrote: I just don't think that IETF meeting attendance is an appropriate way to decide who is a nutcase and who isn't. Appropriate or not, it's not an effective way to distinguish nuts, as it should not surprise you to learn that most of

Re: draft-kolkman-appeal-support

2006-10-13 Thread David W. Hankins
On Fri, Oct 13, 2006 at 10:03:39AM -0700, David W. Hankins wrote: One perfectly acceptable tactic, which Olafur has codified in this s/Olafur/Olaf/g How embarrassing. Sorry, Olaf. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP.

Re: draft-kolkman-appeal-support

2006-10-13 Thread Stephen Farrell
Keith Moore wrote: I just don't think that IETF meeting attendance is an appropriate way to decide who is a nutcase and who isn't. Me too. That'd be a move towards paid membership IMO and as was shown with the recent NomCom selection, the record keeping involved can lead to disputes. If we

Re: draft-kolkman-appeal-support

2006-10-13 Thread Ned Freed
On Fri, Oct 13, 2006 at 10:31:57AM +0200, Frank Ellermann wrote: http://tools.ietf.org/html/draft-kolkman-appeal-support ...it's just wrong. I think he's got a good idea. It maybe could use some tweaking. A lot of tweaking is needed IMO. I have no problem with the idea of requiring some

Re: I understand that there is an ISO MOU with the IETF - I want to see it...

2006-10-13 Thread John C Klensin
--On Friday, 13 October, 2006 13:37 -0400 Dean Anderson [EMAIL PROTECTED] wrote: On Thu, 12 Oct 2006, John C Klensin wrote: And please see my earlier comments about your rights in these issues generally and to make this type of demand, even if the agreement and documents did exist. I

Re: [Nea] WG Review: Network Endpoint Assessment (nea)

2006-10-13 Thread Sam Hartman
Frank == Frank Yeh [EMAIL PROTECTED] writes: Frank Standardized VS vendor-specific attributes is not something that needs to be Frank solved today. Solutions can start with vendor-specific and migrate toward a Frank standard, if one develops, without changing the protocol. The

Re: I understand that there is an ISO MOU with the IETF - I want to see it...

2006-10-13 Thread Dave Crocker
John C Klensin wrote: You are not a member of the IETF. Todd is not a member of the IETF. I am not a member of the IETF. Jorge isn't a member of the IETF either. The IETF has no members. Not only are you right, but per se, the IETF is not a non-profit. Further most people who participate

Non-profit IETF (was RE: I understand that there is an ISO MOU with the IETF...)

2006-10-13 Thread Eastlake III Donald-LDE008
Of course the IETF is a non-profit entity. For-profit entities are entities whose purpose is for the operations of the entity itself to produce profits which accrue to its owners/proprietors/partners/... Non-profit entities are entities with any other purposes. Note that these definitions have

Re: Non-profit IETF (was RE: I understand that there is an ISO MOU with the IETF...)

2006-10-13 Thread Dave Crocker
Eastlake III Donald-LDE008 wrote: Of course the IETF is a non-profit entity. Don, I think you lost the thread of this thread. The operative phrase that triggered my comment was ...by law, Members of a non-profit By law. So this was about the legal construct of a member of a

Re: I understand that there is an ISO MOU with the IETF - I want to see it...

2006-10-13 Thread Theodore Tso
On Fri, Oct 13, 2006 at 01:08:42PM -0700, Dave Crocker wrote: At base, I cannot figure out why anyone keeps feeding such trollish topics, I thought it might at least be amusing to comment on the term member. Note that at this point Dean and Todd have been banned from the IETF list. While this

Re: draft-kolkman-appeal-support

2006-10-13 Thread Frank Ellermann
David W. Hankins wrote: The definitions in Olafur's draft for qualified supporters shouldn't be considered exclusionary. That's precisely how I understand them, and it's not hard to guess which cases this tries to address. It's also not hard to guess which _unrelated_ 3.5 appeals I have in

Joyce Reynolds graduates from USC/ISI

2006-10-13 Thread Bob Braden
To the Internet community: The RFC Editor is saddened by the imminent departure of Joyce Reynolds from the RFC Editor staff. She is leaving ISI to take on a new and challenging job assignment elsewhere. The brass ring came by, and she grabbed it! Over many years, Joyce has made major

RFC 4609 on Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements

2006-10-13 Thread rfc-editor
A new Request for Comments is now available in online RFC libraries. RFC 4609 Title: Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements Author: P. Savola,

RFC 4593 on Generic Threats to Routing Protocols

2006-10-13 Thread rfc-editor
A new Request for Comments is now available in online RFC libraries. RFC 4593 Title: Generic Threats to Routing Protocols Author: A. Barbir, S. Murphy, Y. Yang Status: Informational Date: October 2006