Re: Comments surrounding draft-iab-dns-applications-01
On 04/29/2011 04:36 AM, John Levine wrote: So my advice would be to back up and write down in one or two sentences what problem this document is supposed to fix or at least describe, and then see how much of the rest of it might be salvaged. I was thinking of storing data in DNS and the document proved valuable to determine whether its a good idea or not. I mean, not whether it is technically feasible, but whether it makes sense at all. So, while the mission statement may be a bit unclear, it's definitely a useful document. Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
So my advice would be to back up and write down in one or two sentences what problem this document is supposed to fix or at least describe, and then see how much of the rest of it might be salvaged. I was thinking of storing data in DNS and the document proved valuable to determine whether its a good idea or not. I mean, not whether it is technically feasible, but whether it makes sense at all. So, while the mission statement may be a bit unclear, it's definitely a useful document. I agree that such a document would be useful, but this isn't it. Applications are poorly suited for the DNS if they need fuzzy matches, or range queries, or have query patterns that don't cache well. (IPv6 rDNS has that last problem.) You can argue about how large query and response sizes should be, although DNSSEC has forced an answer to that one. Applications that map fixed query names to (more or less) fixed responses work fine on top of the DNS, even if the query doesn't look much like a host name and the response looks nothing at all like an A record, e.g., NAPTR. A document that described the actual technical architecture of the DNS, without confusing it with the design of applications built on top of the DNS would be a good idea. I suppose I could try and write one. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
IMHO and for the record: ITU-T comments regarding this draft haven't been discussed with ITU-T but were simply ignored. No LS describing these comments' resolution was sent. Several service providers regarded this draft as not meeting their transport networks' needs. [The v03 draft was published in Feb and went to WG LC. The v04 draft addressing WG LC comments was published on the 28th June (same date as the proto write-up). When was the WG LC launched, to verify LC comments resolution?] Regards, Rui -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' draft-ietf-mpls-tp-cc-cv-rdi-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
In message alpine.bsf.2.00.1107040940090.60...@joyce.lan, John R. Levine wr ites: So my advice would be to back up and write down in one or two sentences what problem this document is supposed to fix or at least describe, and then see how much of the rest of it might be salvaged. I was thinking of storing data in DNS and the document proved valuable to determine whether its a good idea or not. I mean, not whether it is technically feasible, but whether it makes sense at all. So, while the mission statement may be a bit unclear, it's definitely a useful document. I agree that such a document would be useful, but this isn't it. Applications are poorly suited for the DNS if they need fuzzy matches, or range queries, or have query patterns that don't cache well. (IPv6 rDNS has that last problem.) You can argue about how large query and response sizes should be, although DNSSEC has forced an answer to that one. Reverse IPv6 caches well. You just can't pre-populate servers with PTR records for all 2^64 ptr records in a normal IPv6 subnet. You need to use tools that add records for nodes that actually exist. Those tools are a decade old now. Applications that map fixed query names to (more or less) fixed responses work fine on top of the DNS, even if the query doesn't look much like a host name and the response looks nothing at all like an A record, e.g., NAPTR. A document that described the actual technical architecture of the DNS, without confusing it with the design of applications built on top of the DNS would be a good idea. I suppose I could try and write one. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies , Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
Reverse IPv6 caches well. You just can't pre-populate servers with PTR records for all 2^64 ptr records in a normal IPv6 subnet. You need to use tools that add records for nodes that actually exist. Those tools are a decade old now. Over in e-mail land, we've been pondering the behavior of spammers, who will likely hop to a different IPv6 address for every spam. If you do rDNS lookups, your cache will fill up with useless entries, maybe PTR, maybe NXDOMAIN, it hardly matters. DNSBLs and DNSWLs, if done the same way as they are in IPv4, have the same problem. These issues are well known in the mail ops community, where it's now the standard advice not to try rDNS lookups on incoming IPv6 mail. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
In message alpine.bsf.2.00.1107041959400.29...@joyce.lan, John R. Levine wri tes: Reverse IPv6 caches well. You just can't pre-populate servers with PTR records for all 2^64 ptr records in a normal IPv6 subnet. You need to use tools that add records for nodes that actually exist. Those tools are a decade old now. Over in e-mail land, we've been pondering the behavior of spammers, who will likely hop to a different IPv6 address for every spam. If you do rDNS lookups, your cache will fill up with useless entries, maybe PTR, maybe NXDOMAIN, it hardly matters. DNSBLs and DNSWLs, if done the same way as they are in IPv4, have the same problem. These issues are well known in the mail ops community, where it's now the standard advice not to try rDNS lookups on incoming IPv6 mail. Or you just tune the cache retention times. For NXDOMAIN/NODATA that's 3 hours by default for named but could be tuned down to 10 minutes or lower without ill effects. RFC 2308 recommends 1-3 hours. I also don't see the point in worrying about this. Caches cope with spammers using a different From domains on each piece of email which is looked up in the DNS. The worst using a different IPv6 address per email can do is double the cache requirements for the same volume of email. LRU cleaning of the cache will cope with this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
Over in e-mail land, we've been pondering the behavior of spammers, who will likely hop to a different IPv6 address for every spam. If you do rDNS lookups, your cache will fill up with useless entries, maybe PTR, maybe NXDOMAIN, it hardly matters. DNSBLs and DNSWLs, if done the same way as they are in IPv4, have the same problem. These issues are well known in the mail ops community, where it's now the standard advice not to try rDNS lookups on incoming IPv6 mail. Or you just tune the cache retention times. For NXDOMAIN/NODATA that's 3 hours by default for named but could be tuned down to 10 minutes or lower without ill effects. RFC 2308 recommends 1-3 hours. DNSBLs already set the min pretty low, e.g. 150 sec for Spamhaus. Doesn't really matter how low it is if you have so many entries that they force out the useful ones. I also don't see the point in worrying about this. Caches cope with spammers using a different From domains on each piece of email which is looked up in the DNS. Modern spam filters don't usually look up the author domain, since it's usually a genuine address taken from the spam list so it's unrelated to the real sender. Even if they did, universe of domains that exist is a vastly smaller set than even IPv4 addresses, and one which caches pretty well since so many of them are at large sites like Yahoo and Hotmail. In any event, we can argue about how good or bad an idea it is to use IPv6 rDNS, but that's tangential to the issues of deciding what are reasonable applications for the DNS. If you're right and rDNS caches well, it's a good application for DNS. If I'm right and it doesn't cache at all, it's not such a good application. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
On Jul 4, 2011, at 8:23 PM, John R. Levine wrote: Reverse IPv6 caches well. You just can't pre-populate servers with PTR records for all 2^64 ptr records in a normal IPv6 subnet. You need to use tools that add records for nodes that actually exist. Those tools are a decade old now. Over in e-mail land, we've been pondering the behavior of spammers, who will likely hop to a different IPv6 address for every spam. If you do rDNS lookups, your cache will fill up with useless entries, maybe PTR, maybe NXDOMAIN, it hardly matters. DNSBLs and DNSWLs, if done the same way as they are in IPv4, have the same problem. These issues are well known in the mail ops community, where it's now the standard advice not to try rDNS lookups on incoming IPv6 mail. Yes, but rDNS PTR lookups always have been pretty much meaningless anyway, and will only get worse in IPv4 due to LSN. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
In message alpine.bsf.2.00.1107042151340.62...@joyce.lan, John R. Levine wri
tes:
Over in e-mail land, we've been pondering the behavior of spammers, who
will likely hop to a different IPv6 address for every spam. If you do rDNS
lookups, your cache will fill up with useless entries, maybe PTR, maybe
NXDOMAIN, it hardly matters. DNSBLs and DNSWLs, if done the same way as
they are in IPv4, have the same problem. These issues are well known in
the mail ops community, where it's now the standard advice not to try rDNS
lookups on incoming IPv6 mail.
Or you just tune the cache retention times. For NXDOMAIN/NODATA
that's 3 hours by default for named but could be tuned down to 10
minutes or lower without ill effects. RFC 2308 recommends 1-3 hours.
DNSBLs already set the min pretty low, e.g. 150 sec for Spamhaus.
Doesn't really matter how low it is if you have so many entries that they
force out the useful ones.
DNS[WB]L's are not rDNS. rDNS is designed to associate a name with
a address.
DNS[WB]L's have never been a good fit to the DNS, rather they have
not been a bad enough fit to require something better to be done.
The naive approach of reversing the address, converting to nibbles
and appending a suffix won't scale.
For IPv6 if you did the reverse of /48, /52, /56, /60 and /64
prefixes, which matches delegation patterns along with NXDOMAIN
synthesis, you would still be fine. You stop the search on NXDOMAIN
or data with perhaps a new value which says to continue searching
for white listed records. One could even start with /32 if one is
worried about spammers pretending to be ISPs.
It requires slightly more intelligence in the MTA that faking up a
address lookup. NXDOMAIN synthesis doesn't have to be done in the
DNS cache. It can be done in the application provided it keeps
track of the ranges covered by the NSEC{3} records returned with
the negative responses. DNSSEC validators that support DLV do this
sort of thing.
I also don't see the point in worrying about this. Caches cope
with spammers using a different From domains on each piece of email
which is looked up in the DNS.
Modern spam filters don't usually look up the author domain, since it's
usually a genuine address taken from the spam list so it's unrelated to
the real sender. Even if they did, universe of domains that exist is a
vastly smaller set than even IPv4 addresses, and one which caches pretty
well since so many of them are at large sites like Yahoo and Hotmail.
Both are effectively infinite compared to cache sizes.
In any event, we can argue about how good or bad an idea it is to use IPv6
rDNS, but that's tangential to the issues of deciding what are reasonable
applications for the DNS. If you're right and rDNS caches well, it's a
good application for DNS. If I'm right and it doesn't cache at all, it's
not such a good application.
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies
,
Please consider the environment before reading this e-mail. http://jl.ly
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
The naive approach of reversing the address, converting to nibbles and appending a suffix won't scale. For IPv6 if you did the reverse of /48, /52, /56, /60 and /64 prefixes, which matches delegation patterns along with NXDOMAIN synthesis, you would still be fine. You stop the search on NXDOMAIN or data with perhaps a new value which says to continue searching for white listed records. One could even start with /32 if one is worried about spammers pretending to be ISPs. I don't necessarily disagree, but now you've just upgraded the DNS (NXDOMAIN synthesis is far from universal) and layered a probing protocol on top of it. We can have a theological argument about whether that counts as using the DNS. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom 2011-2012: Third Call for Volunteers
This is the Third call for Volunteers for the 2011-12 Nomcom. We are almost through the volunteer period so if you are considering volunteering, please do so very soon. We have had a very good response to the initial call for volunteers and I am pleased to report that we have 84 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible. If you volunteered before 09:00 EDT on June 29 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 84 volunteers who have thus far been qualified by the secretariat are: Alia Atlas,Juniper Networks Lixia Zhang,UCLA Wassim Haddad ,Ericsson Glen Zorn,Network Zen Richard Barnes,BBN Technologies Stephen Kent,BBN Technologies Scott Mansfield,Ericsson Tina TSOU (Ting ZOU),FutureWei Technologies Fernando Gont,UTN/FRH Karen Seo,BBN Technologies Jie Dong,Huawei Technologies Mach Chen,Huawei Technologies Co. Ltd. Sheng Jiang,Huawei Technologies Co. Ltd. Dimitri Papadimitriou,Alcatel-Lucent Thomas D. Nadeau,CA Technologies David Meyer,Cisco Systems/University of Oregon Wesley George,Time Warner Cable Cullen Jennings,Cisco Stephen Hanna,Juniper Networks Stephan Wenger,Bidyo Inc. Keyur Patel,Cisco Systems Michael (Mike) Hamilton,BreakingPoint Systems Behcet Sarikaya,Huawei USA Mark Townsley,Cisco Systems Fred Baker,Cisco Systems Brian Trammell,ETH Z�rich Sam Hartman,Painless Security Chris Griffiths,Comcast George Michaelson,APNIC Jiankang Yao,CNNIC Sohel Khan,Comcast Dacheng Zhang,Huawei Lianshu Zheng,Huawei Technologies Hui Deng,China Mobile Gang Chen,China Mobile Mirja K�hlewind,University of Stuttgart IKR John E Drake,Juniper Networks Matt Lepinski,BBN Technologies Subir Das,Telcordia Technologies Inc Yi Zhao,Huawei John Scudder,Juniper Networks Christer Holmberg,LM Ericsson Teemu Savolainen,Nokia Samita Chakrabarti,Ericsson Jaap Akkerhuis,NLnet labs Jason Weil,Time Warner Cable Randy Bush,Internet Initiative Japan Christian Schmidt,Nokia Siemens Networks Sean Shen,CNNIC Lou Berger,LabN Consulting L.L.C. Donald Eastlake,Huawei Xiaohu Xu,Huawei Technologies co. Ltd. B�rje Ohlman,Ericsson Deborah Brungard,ATT Magnus Westerlund,Ericsson Zhen Cao,China Mobile Hadriel Kaplan,Acme Packet Lilla Dovner,Ericsson John Jason Brzozowski,Comcast Jonne Soininen,Renesas Mobile Javier Ubillos,Swedish Institute of Computer Science Eric Gray,Ericsson Thomas Herbst,Silver Spring Networks Ning Zong,Huawei Technologies Haibin Song,Huawei Technologies Yingjie Gu,Huawei Technologies Hongyu Li,Huawei Technologies Terry Manderson,ICANN Ari Keranen,Ericsson Jouni Korhonen,Nokia Siemens Networks Bhumip Khasnabish,ZTE USA Inc. Dapeng Liu,China Mobile Fangwei Hu,ZTE Corporation Ole Troan,Cisco Pascal Thubert,Cisco Wojciech Dec,Cisco Gunter Van de Velde,Cisco Ning So,Verizon Inc./University of Texas at Dallas Guoman liu,ZTE Simon Pietro Romano,Meetecho/University of Napoli Luca Martini,Cisco Bill VerSteeg,Cisco Toerless Eckert,Cisco Systems Joseph Salowey,Cisco Systems The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krish...@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this
