Re: If you have nothing to hide
At 06:31 AM 8/4/2002 -0400, Sean Donelan wrote:
I encourage network operators (or IX operators, DNS operators, etc) to let the government know what you think. Mr. Clarke's crew is writing the plan, and taking input from many sources. If you think RPF (or some other source address validation) is a solution let them know. If you think S-BGP is a solution, let them know. If you think network operator managed firewalls on every DSL/Cable modem is a solution, let them know. On the other hand, if to think some of those things are not a solution (or a really bad idea), tell them that.
These are technical operations matters. Seems like there might be some benefit in formulating consensus views within the technical operations community. Any chance that an IETF BCP would be possible and helpful? Diverse input to a government process can be good for learning about choices, but consensus views should be helpful for making them. d ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850
On Sun, 4 Aug 2002, Dave Crocker wrote:
These are technical operations matters. Seems like there might be some benefit in formulating consensus views within the technical operations community.
Any chance that an IETF BCP would be possible and helpful?
There is a difference between technical/operational matters and policy matters. I respectfully disagree this can be treated as a technical problem. For example, Bellcore wrote the technical standard for Caller-ID, but Caller-ID policy varies widely throughout the telephone system. Ever notice how telemarketers never seem to have valid Caller-ID. That is not a really technical problem. Likewise Internet source address validation has a technical part, and a policy part. For the technical parts the IETF has RFC2827. The policy questions are how should it be enforced, by whom? Since the end of "connected status" there hasn't really been a way to control who can use what addresses to connect to the Internet. One issues is the RFCs aren't written as regulations. It would be a bad idea to attempt to enforce them as written. They are useful as guidance to network operators, but as anyone who has ever tried to write a TCP/IP stack from scratch using nothing but the RFCs (yes, people have tried), it doesn't work.
Diverse input to a government process can be good for learning about choices, but consensus views should be helpful for making them.
What group is the best forum for developing consensus views on Internet operation policy issues? One of the Mr. Clarke's complaints in his speech was there is no group the government can go to find out what the consensus view of Internet operators is. IETF doesn't appear to want to take on that role. NANOG isn't structured to develop policies for ISPs. IOPS, ICANN, ISPSEC, etc have issues. ATIS, ITU, NRIC, NSTAC would love to take on the role. The National Cybersecurity Plan (or whatever the final name ends up) will be announced in September. The next NANOG meeting is October 27-29. The next IETF meeting is November 17-21.
On Sun, 4 Aug 2002, Sean Donelan wrote: [snip] : > Diverse input to a government process can be good for learning about : > choices, but consensus views should be helpful for making them. : : What group is the best forum for developing consensus views on : Internet operation policy issues? : : One of the Mr. Clarke's complaints in his speech was there is no group : the government can go to find out what the consensus view of Internet : operators is. IETF doesn't appear to want to take on that role. NANOG : isn't structured to develop policies for ISPs. IOPS, ICANN, ISPSEC, etc : have issues. ATIS, ITU, NRIC, NSTAC would love to take on the role. : : The National Cybersecurity Plan (or whatever the final name ends up) will : be announced in September. The next NANOG meeting is October 27-29. The : next IETF meeting is November 17-21. Invite him and/or members of his team to NANOG... scott
participants (3)
-
Dave Crocker
-
Scott Weeks
-
Sean Donelan