Re: IETF speed -- was Re: Running Code
Hi, On 2009-3-4, at 15:39, a...@tr-sys.de wrote: I do not want to blame anybody, but in the TSV area I am aware of documents in at least two different WGs that describe common (and recommended) _existing_ implementation practice and have not even been submitted to the IESG after more than 4 years of consideration. I'd be interested to learn which IDs you refer to. Thanks, Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 3484 section 6 rule 9 causing more operational problems
6MAN WG is working on this. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 3484 section 6 rule 9 causing more operational problems
On Wed, Mar 04, 2009 at 02:09:22PM +, Tony Finch wrote: It seems that Vista implements RFC 3484 address selection, including the requirement to sort IP addresses. This breaks a great deal of operational dependence on DNS-based load balancing, as well as being based on an incorrect understanding of how IP addresses are allocated. RFC 3484 needs to be updated to delete this rule, so that the order returned from the DNS is honoured when the client has no better knowledge about which address is appropriate. See http://drplokta.livejournal.com/109267.html http://www.ietf.org/mail-archive/web/ietf/current/msg51874.html http://www.ietf.org/mail-archive/web/discuss/current/msg01035.html http://www.ietf.org/mail-archive/web/dnsop/current/msg05847.html http://lists.debian.org/debian-ctte/2007/11/msg00029.html The issue is mentioned in: http://www.watersprings.org/pub/id/draft-arifumi-6man-rfc3484-revise-00.txt 2.5. To disable or restrict RFC 3484 Section 6 Rule 9 There was a discussion at v6ops and ietf@ietf.org mailing lists that the rule 9 of the destination address selection has a serious adverse effect on the round robin DNS technique However the above has expired. Perhaps Arifumi will issue a new version before the upcoming cutoff. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
TSG tglassey at earthlink dot net wrote: Then the template has to be changed. Will the IETF still continue to accept documents formatted the old way or will it mandate this change everywhere - and gee - that could be our own little stimulus package - we may have to hire someone to move the (c) in all of the existing documents to the end pages with the licensing info. It would surprise me if changing all of the existing documents was considered part of the scope of this suggestion. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Early implementers motivations [was Re: Running Code]
Marc Petit-Huguenin petithug at acm dot org wrote: If you did contribute an early implementation or did think of contributing but finally didn't, please respond to this email with your story. Interesting points are why you did (or not) the early implementation, will you do more, what would motivate you to do more early implementations, etc... You can send your responses directly to me if you do not want to respond publicly - I will keep them confidential and post just a summary of the responses. I did an early implementation of RFC 4646 while it was in draft form, and updated it for draft-4646bis. Indeed, the work that ultimately became RFC 4645 and the initial IANA Language Subtag Registry started as a prototype. I did this solely to help flesh out the ideas being discussed in the LTRU WG and as a smoke test against the group's output, not because of any expectation of monetary gain or tangible, widespread recognition -- which is a darned good thing since I haven't received either one, though I did get an Acknowledgement in 4646. Other people inside and outside the WG have built their own validators for both 4646 and 4646bis. Having to list all of these implementations in the drafts would have made a slow review and approval process even slower. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Abstract on Page 1?
I doubt that this is a huge tool-builder issue. Lets not go looking for problems. I think moving the boilerplate is a good idea, particularly for people who are still reading the TXT versions of the docs. The only piece I would keep on the front page is the bit that says where comments should go. -Original Message- From: ietf-boun...@ietf.org on behalf of Andrew Sullivan Sent: Wed 3/4/2009 10:55 AM To: ietf@ietf.org Subject: Re: Abstract on Page 1? On Wed, Mar 04, 2009 at 04:50:19PM +0100, Julian Reschke wrote: The following text must be included on the first page of each IETF Document as specified below: Some of us may regard the requirement of standard legal boilerplate taking precedence over technical content to be a symptom of a problem, rather than something to be accepted quietly. (But I have a great deal of sympathy for the toolbuilders, and think that maybe just now is not a good time to be making more changes. Perhaps the next time one is required anyway, though?) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Reverse IPv6 DNS checks on ietf MXs?
On Thu Mar 5 13:00:55 2009, Tim Chown wrote: Just an observation, I don't know whether its been changed or applied recently, but we had some mails to various IETF lists soft rejected overnight due to failure of the receiving MX to perform a successful reverse DNS lookup on the IPv6 sender address. That's been the case for ages, and is why I now firewall outgoing IPv6 connections to the IETF's mailserver. (I could go off and pay for IPv6 reverse DNS hosting, but I'm not *that* keen on IPv6). Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Reverse IPv6 DNS checks on ietf MXs?
On Thu, Mar 05, 2009 at 01:00:55PM +, Tim Chown wrote: Hi, Just an observation, I don't know whether its been changed or applied recently, but we had some mails to various IETF lists soft rejected overnight due to failure of the receiving MX to perform a successful reverse DNS lookup on the IPv6 sender address. Note that there has been work in DNSOP suggesting that rejecting on the failure of reverse DNS lookup is not always a good idea. So if IETF lists are in fact doing that, perhaps the operators of the servers want to ask for the advice of the DNSOP participants. (Be prepared for a lot of mail.) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
my error here - Paul said DNS does no ordering... he did not specify ordering of what. we now return you to your rant. --bill On Wed, Mar 04, 2009 at 07:54:37PM +, Chris Thompson wrote: On Mar 4 2009, OndEej SurC= wrote: On Wed, Mar 4, 2009 at 6:57 PM, bmann...@vacation.karoshi.com wrote: [...] DNSSEC does reorder RRSets within a zone. Which is a new feature. When we started talking about order of RRSets? This is purely discussion about order of RRs in RRSet. Order of RRSets in zone is irrelevant before DNSSEC and also after DNSSEC. Nothing depends on order of RRSets at least in my best knowledge. I took Bill to mean DNSSEC does reorder RRs within an RRset anyway, as I don't know in what other sense DNSSEC is relevant at all. But the canonical ordering of RRs within an RRset for signing purposes says nothing about the presentation order in the answers to DNS queries. And in fact a certain well-known nameserver implementation not unassociated with Paul still supports all the rrset-order and sortlist controls, which work for secured zones as well as unsecured ones. -- Chris Thompson Email: c...@cam.ac.uk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
On Mar 4 2009, Ondřej Surý wrote: On Wed, Mar 4, 2009 at 6:57 PM, bmann...@vacation.karoshi.com wrote: [...] DNSSEC does reorder RRSets within a zone. Which is a new feature. When we started talking about order of RRSets? This is purely discussion about order of RRs in RRSet. Order of RRSets in zone is irrelevant before DNSSEC and also after DNSSEC. Nothing depends on order of RRSets at least in my best knowledge. I took Bill to mean DNSSEC does reorder RRs within an RRset anyway, as I don't know in what other sense DNSSEC is relevant at all. But the canonical ordering of RRs within an RRset for signing purposes says nothing about the presentation order in the answers to DNS queries. And in fact a certain well-known nameserver implementation not unassociated with Paul still supports all the rrset-order and sortlist controls, which work for secured zones as well as unsecured ones. -- Chris Thompson Email: c...@cam.ac.uk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
* Paul Vixie: neither a client or a server can be guaranteed topology-aware. dns leaves ordering deliberately undefined and encourages applications to use their own best judgement. The leaves undefined part is at odds with your previous statement that RFC 3484 is correct. It is compliant with the rest of the protocol zoo, but the order of records, as seen by applications, is no longer undefined. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
* Christian Huitema: The order of5C records in a DNS response is, at best, a hint. Relying on it as if it were a mandate to clients is a gamble. When you run RRset-based load balancing, you don't rely on servers preserving order, or reordering responses. It is completely sufficient that there is a certain amount of variation among resolver and application address selection. It has been repeatedly and independently observed that Rule 9 does not provide sufficient variance, in contrast to previous behavior. Rule 9 is also unfortunate because it means that after renumbering, server loads change in ways the operator cannot influence (except by requesting addresses with certain bit patterns, but I don't think anybody wants vanity IP addresses). -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] Re: RFC 3484 section 6 rule 9 causing more operational problems
* Paul Vixie: Large numbers of sites have been depending on this behaviour for over 15 years, so it was wrong of RFC 3484 to break it. some number of vendors have depended on revenue from selling this feature but i'd say that only a small number of sites ever saw any benefit from it. pool.ntp.org, security.debian.org, rsync.gentoo.org, [a-o].ns.spamhaus.org, [a-n].surbl.org. In general the large RRset approach is used by those who do not buy special DNS appliance to serve their zones, I think. Many CDNs also serve multiple addresses selected from a larger pool, probably based on network topology and server load/availability. Those folks can mitigate Rule 9 impact by carefully tuning the address set in each response. But those who rely on IETF protocols to distribute and publish their DNS data are out of luck. (Another approach to deal with the Rule 9 fallout is to put all your servers into a dedicated prefix, but I don't think this is a good idea in general.) -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
On Wed, Mar 4, 2009 at 6:57 PM, bmann...@vacation.karoshi.com wrote: On Wed, Mar 04, 2009 at 05:11:47PM +, Paul Vixie wrote: i disagree. dns-based load balancing is an unfortunate overloading and should never be done. RFC 3484 is correct as it is. Why is it right for topology-ignorant clients to override topology-aware DNS servers based on wishful thinking about RIR address allocation policies? neither a client or a server can be guaranteed topology-aware. dns leaves ordering deliberately undefined and encourages applications to use their own best judgement. DNSSEC does reorder RRSets within a zone. Which is a new feature. When we started talking about order of RRSets? This is purely discussion about order of RRs in RRSet. Order of RRSets in zone is irrelevant before DNSSEC and also after DNSSEC. Nothing depends on order of RRSets at least in my best knowledge. Ondrej. -- Ondrej Sury technicky reditel/Chief Technical Officer - CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.s...@nic.cz http://nic.cz/ sip:ondrej.s...@nic.cz sip%3aondrej.s...@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
On Wed, Mar 4, 2009 at 9:04 PM, bmann...@vacation.karoshi.com wrote: we now return you to your rant. Sorry, if I sounded too harsh. my error here - Paul said DNS does no ordering... he did not specify ordering of what. Order of RRs in zone file is not relevant for the order on the wire. DNS (as in DNS protocol) does no ordering. Ondrej. --bill On Wed, Mar 04, 2009 at 07:54:37PM +, Chris Thompson wrote: On Mar 4 2009, OndE ej SurC= wrote: On Wed, Mar 4, 2009 at 6:57 PM, bmann...@vacation.karoshi.com wrote: [...] DNSSEC does reorder RRSets within a zone. Which is a new feature. When we started talking about order of RRSets? This is purely discussion about order of RRs in RRSet. Order of RRSets in zone is irrelevant before DNSSEC and also after DNSSEC. Nothing depends on order of RRSets at least in my best knowledge. I took Bill to mean DNSSEC does reorder RRs within an RRset anyway, as I don't know in what other sense DNSSEC is relevant at all. But the canonical ordering of RRs within an RRset for signing purposes says nothing about the presentation order in the answers to DNS queries. And in fact a certain well-known nameserver implementation not unassociated with Paul still supports all the rrset-order and sortlist controls, which work for secured zones as well as unsecured ones. -- Chris Thompson Email: c...@cam.ac.uk -- Ondrej Sury technicky reditel/Chief Technical Officer - CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.s...@nic.cz http://nic.cz/ sip:ondrej.s...@nic.cz sip%3aondrej.s...@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
RFC 3484 is correct as it is. Here I don't. The idea behind is good, the implementation is not. Client would have to know BGP path to DA + DB and decide on basis of routing protocol. Selection based on longest matching prefix will work in only very small percent of case, all other cases are based on pure luck. random tends to be best, honestly. but if there's an alternative that's in the same /24 or /16 with you then this will be a useful optimization. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] Re: RFC 3484 section 6 rule 9 causing more operational problems
you'll see roundrobin and lifo, among others, in many caches including stub caches. Large numbers of sites have been depending on this behaviour for over 15 years, so it was wrong of RFC 3484 to break it. some number of vendors have depended on revenue from selling this feature but i'd say that only a small number of sites ever saw any benefit from it. we've been lifo'ing and round robin'ing dns data in caches and stubs for a lot longer than 15 years, and the original dns rfc's said specifically that rrset ordering was not guaranteed in the protocol, so anyone who depended on it was getting screwed a long time before RFC 3484 came around. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Reverse IPv6 DNS checks on ietf MXs?
Andrew Sullivan wrote: On Thu, Mar 05, 2009 at 10:32:28AM -0800, Doug Otis wrote: Note that there has been work in DNSOP suggesting that rejecting on the failure of reverse DNS lookup is not always a good idea. Agreed. Just to be clear: I am not sure I agree with those who think reverse DNS should not be maintained, but there were strong currents in the WG that led to the text of that I-D as it stands. It isn't clear to me where the I-D stands in its progression (if there is to be any) from the WG, so I have no idea what the Chairs will say was consensus. But there was a WGLC in which at least some people suggested the text of draft-ietf-dnsop-reverse-mapping-considerations-06.txt still contained too much endorsement of the reverse tree. My personal interpretation of those remarks is that there will always be a hard core of operators who regard the reverse tree as an insupportable burden (without consideration for the v4/v6 differences). I think it's hard to argue that it isn't a greater burden in ipv6, whether it is insupportable is a question of degree... obviously one can simply use wildcards in zones to generate responses whether tha produces a level of congruence between forward and reverse or even any actual meaning that's useful is another question entirely. A ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Abstract on Page 1?
--On Thursday, March 05, 2009 10:37 -0800 Paul Hoffman paul.hoff...@vpnc.org wrote: At 1:14 PM -0500 3/5/09, John C Klensin wrote: I'd like to be sure that the people proposing this are all actually proposing the same thing... versus the possibility that they have different things in mind. Fully agree. The proposed IAB document, draft-iab-streams-headers-boilerplates, This thread, until your message, was about Internet Drafts; yours is about RFCs. The issues are quite different. As you might remember if you followed my many comments on this list about the IAB document, I think that separating the two --creating formats that are significantly different-- is looking for all sorts of trouble. IMO, one of our big breakthroughs of the last few years has been the ability of authors and the RFC Editor to work in xml2rfc format, doing clean diffs on the relationship between an I-D and the final working (AUTH48) drafts of RFCs. I'm also concerned about the burdens on tool-builders and tools, especially those less sophisticated than xml2rfc, if we end up needing references from boilerplate in the front of documents to sections or pages near the end (or buried in the middle). So, to me at least, move status and copyright to the end gets a lot less attractive if that is ...end of I-D but not RFCs rather than both. It also leads me to wonder about alternate solutions if the problem to be solved is really abstract on page 1. For example, if we are talking about I-Ds, maybe the length of the Status section needs serious review. In particular, I would guess that -- The second paragraph could be shortened significantly or dropped; I don't know what it accomplishes. -- While I'm one of the few remaining fans of the valid for only six months rule, it has been diluted sufficiently that perhaps we should be having a discussion about whether that paragraph, or at least the first half of the first sentence, is useful enough to justify the space any more, especially with the requirement for an expiration date on the document. -- The two The list of... paragraphs have almost certainly become noise. The shadow list is not complete and still refers to FTP archives and 1id-abstracts.txt no longer contains the information that the sentence suggests it does. Apparently no one has complained to the Secretariat or Tools Team about either, which is probably a hint about how useful they are. By my count, that would get rid of at least nine lines, or at least eleven if we concluded that we don't need a This Internet-Draft will expire statement in the Status if it appears in page footers. In addition, no matter what requirements exist about placement of copyright notices, I can imagine no possible reason why the order of Status and Abstract cannot simply be switched (in both RFCs and I-Ds) other than whatever energy it takes to make the decision. Since the Status section is 22 lines long in its most common current form (and without the workaround text) and the RFC Editor strongly discourages abstracts longer than about a dozen lines, just making that switch (even without the Status trimming I suggest above) would get the Abstracts onto the first page, always. So, just as I'd like to understand what people are advocating moving, I'd like to see if we can separate an objective (e.g., get the Abstract onto Page 1) from a mechanism (e.g., move the boilerplate to the end). john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 202 messages in the last 7 days. script run at: Fri Mar 6 00:53:02 EST 2009 Messages | Bytes| Who +--++--+ 4.95% | 10 | 4.29% |53786 | petit...@acm.org 4.95% | 10 | 3.76% |47110 | d...@dotat.at 3.96% |8 | 4.14% |51887 | john-i...@jck.com 3.96% |8 | 3.66% |45834 | d...@dcrocker.net 2.48% |5 | 4.52% |56649 | pba...@verisign.com 3.47% |7 | 3.52% |44169 | hannes.tschofe...@gmx.net 3.47% |7 | 3.05% |38279 | ned+i...@mauve.mrochek.com 2.48% |5 | 2.66% |33383 | tglas...@earthlink.net 2.48% |5 | 2.59% |32456 | joe...@bogus.com 1.49% |3 | 3.39% |42504 | stpe...@stpeter.im 2.48% |5 | 1.75% |21910 | a...@shinkuro.com 1.98% |4 | 2.18% |27310 | brian.e.carpen...@gmail.com 1.98% |4 | 2.00% |25041 | ves...@tana.it 1.98% |4 | 1.84% |23020 | s...@resistor.net 1.49% |3 | 2.32% |29092 | p...@cisco.com 1.49% |3 | 2.24% |28117 | ondrej.s...@nic.cz 1.98% |4 | 1.52% |19072 | fwei...@bfk.de 1.98% |4 | 1.46% |18285 | vi...@isc.org 1.98% |4 | 1.43% |17955 | paul.hoff...@vpnc.org 0.99% |2 | 1.87% |23446 | do...@mail-abuse.org 1.49% |3 | 1.36% |17090 | chris.dearl...@baesystems.com 1.49% |3 | 1.36% |17023 | msh...@cisco.com 1.49% |3 | 1.33% |16663 | h...@cs.columbia.edu 1.49% |3 | 1.20% |14993 | mark_andr...@isc.org 1.49% |3 | 1.13% |14180 | d...@cridland.net 0.99% |2 | 1.48% |18489 | st.am...@isoc.org 0.99% |2 | 1.42% |17831 | texte...@xencraft.com 0.99% |2 | 1.33% |16663 | lars.egg...@nokia.com 0.99% |2 | 1.20% |15030 | randy_pres...@mindspring.com 0.99% |2 | 1.01% |12634 | hsan...@santronics.com 0.99% |2 | 0.97% |12148 | t...@ecs.soton.ac.uk 0.50% |1 | 1.43% |17900 | addi...@amazon.com 0.99% |2 | 0.91% |11406 | amor...@amsl.com 0.99% |2 | 0.87% |10858 | dcroc...@bbiw.net 0.99% |2 | 0.84% |10547 | o...@nlnetlabs.nl 0.99% |2 | 0.82% |10268 | lly...@civil-tongue.net 0.99% |2 | 0.81% |10161 | d...@ewellic.org 0.99% |2 | 0.81% |10130 | jari.ar...@piuha.net 0.99% |2 | 0.79% | 9887 | a...@netconfcentral.com 0.99% |2 | 0.78% | 9798 | dean.wil...@softarmor.com 0.99% |2 | 0.78% | 9793 | a...@oryx.com 0.99% |2 | 0.72% | 9048 | mo...@necom830.hpcl.titech.ac.jp 0.99% |2 | 0.72% | 9000 | s...@cs.columbia.edu 0.99% |2 | 0.67% | 8388 | hous...@vigilsec.com 0.99% |2 | 0.64% | 8045 | m...@lilacglade.org 0.50% |1 | 0.92% |11588 | jef...@jefsey.com 0.50% |1 | 0.88% |11077 | hsinn...@adobe.com 0.50% |1 | 0.84% |10530 | ebur...@standardstrack.com 0.50% |1 | 0.82% |10307 | jmp...@cisco.com 0.50% |1 | 0.73% | 9164 | les...@thinkingcat.com 0.50% |1 | 0.57% | 7144 | rpellet...@isoc.org 0.50% |1 | 0.55% | 6892 | l...@cisco.com 0.50% |1 | 0.54% | 6813 | sc...@kitterman.com 0.50% |1 | 0.54% | 6734 | doug.mtv...@gmail.com 0.50% |1 | 0.53% | 6622 | presn...@qualcomm.com 0.50% |1 | 0.53% | 6598 | p...@nesser.com 0.50% |1 | 0.52% | 6544 | d...@dcrocker.net 0.50% |1 | 0.51% | 6423 | nar...@us.ibm.com 0.50% |1 | 0.50% | 6268 | jer...@unfix.org 0.50% |1 | 0.49% | 6132 | elw...@dial.pipex.com 0.50% |1 | 0.46% | 5800 | c...@cam.ac.uk 0.50% |1 | 0.46% | 5750 | nwea...@icsi.berkeley.edu 0.50% |1 | 0.46% | 5738 | michelle.cot...@icann.org 0.50% |1 | 0.45% | 5634 | t...@att.com 0.50% |1 | 0.44% | 5565 | josh.howl...@ja.net 0.50% |1 | 0.44% | 5467 | stbry...@cisco.com 0.50% |1 | 0.43% | 5381 | huit...@windows.microsoft.com 0.50% |1 | 0.42% | 5319 | bmann...@vacation.karoshi.com 0.50% |1 | 0.42% | 5215 | a...@tr-sys.de 0.50% |1 | 0.41% | 5192 | rbar...@bbn.com 0.50% |1 | 0.40% | 5052 | e...@hueniverse.com 0.50% |1 | 0.40% | 5048 | mdo...@att.com 0.50% |1 | 0.39% | 4939 | wei...@watson.org 0.50% |1 | 0.39% | 4914 | g...@rellim.com 0.50% |1 | 0.38% | 4814 | tb...@textuality.com 0.50% |1 | 0.38% | 4788 | jason_living...@cable.comcast.com 0.50% |1 | 0.38% | 4780 | t...@multicasttech.com 0.50% |1 | 0.38% | 4743 | g...@apnic.net 0.50% |1 | 0.37% | 4687 | remi.desp...@free.fr 0.50% |1 | 0.37% | 4645 | julian.resc...@gmx.de 0.50% |1 | 0.36% | 4561 | har...@alvestrand.no 0.50% |1 | 0.36% | 4535 | e...@networkresonance.com 0.50% |1 | 0.35% | 4381 | d.b.nel...@comcast.net 0.50% |1 | 0.34% | 4318 |
Protocol Action: 'RPC: Remote Procedure Call Protocol Specification Version 2' to Draft Standard
The IESG has approved the following document: - 'RPC: Remote Procedure Call Protocol Specification Version 2 ' draft-ietf-nfsv4-rfc1831bis-13.txt as a Draft Standard This document is the product of the Network File System Version 4 Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rfc1831bis-13.txt Technical Summary This document is intended to replace RFC 1831 as the authoritative document describing RPC, without introducing any over-the-wire protocol changes. The update includes transition of the RPC program and authentication registries to IANA along with appropriate rules for new entry requests. It also provides additional discussion the the security considerations section based on experience with strong security flavors. Working Group Summary There is a long implementation history of this protocol and the main intent of this document update is to move the RPC RFC to Draft Standard. There has been strong support of this within the RPC community and specifically within the working group. Document Quality Given the review time, the numerous implementations in existence and the updates that have been done, the quality of this document is high. Personnel Spencer Shepler (spencer.shep...@gmail.com) is the Document Shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed this document for the IESG. Note to RFC Editor Please make the following substitution in section 14: OLD AUTH_DH as mentioned in sections 8.2 and 13.4.2 is considered obsolete and insecure; see [RFC2695]. AUTH_SYS SHOULD NOT be used for services which permit clients to modify data. AUTH_DH MUST NOT be specified as RECOMMENDED or REQUIRED for any standards-track RPC service. NEW AUTH_DH as mentioned in sections 8.2 and 13.4.2 is considered obsolete and insecure; see [RFC2695]. AUTH_DH SHOULD NOT be used ^^ for services which permit clients to modify data. AUTH_DH MUST NOT be specified as RECOMMENDED or REQUIRED for any standards-track RPC service. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5415 on Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification
A new Request for Comments is now available in online RFC libraries. RFC 5415 Title: Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification Author: P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed. Status: Standards Track Date: March 2009 Mailbox:pcalh...@cisco.com, mmontemu...@rim.com, dstan...@arubanetworks.com Pages: 155 Characters: 345381 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-capwap-protocol-specification-15.txt URL:http://www.rfc-editor.org/rfc/rfc5415.txt This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. [STANDARDS TRACK] This document is a product of the Control And Provisioning of Wireless Access Points Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5416 on Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11
A new Request for Comments is now available in online RFC libraries. RFC 5416 Title: Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11 Author: P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed. Status: Standards Track Date: March 2009 Mailbox:pcalh...@cisco.com, mmontemu...@rim.com, dstan...@arubanetworks.com Pages: 76 Characters: 175870 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-capwap-protocol-binding-ieee80211-12.txt URL:http://www.rfc-editor.org/rfc/rfc5416.txt Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. [STANDARDS TRACK] This document is a product of the Control And Provisioning of Wireless Access Points Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5417 on Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option
A new Request for Comments is now available in online RFC libraries. RFC 5417 Title: Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option Author: P. Calhoun Status: Standards Track Date: March 2009 Mailbox:pcalh...@cisco.com Pages: 6 Characters: 11551 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-capwap-dhc-ac-option-02.txt URL:http://www.rfc-editor.org/rfc/rfc5417.txt The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers to which it is to connect. This document describes the DHCP options to be used by the CAPWAP Protocol. [STANDARDS TRACK] This document is a product of the Control And Provisioning of Wireless Access Points Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5418 on Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments
A new Request for Comments is now available in online RFC libraries. RFC 5418 Title: Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments Author: S. Kelly, T. Clancy Status: Informational Date: March 2009 Mailbox:sc...@hyperthought.com, cla...@ltsnet.net Pages: 34 Characters: 74169 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-capwap-threat-analysis-04.txt URL:http://www.rfc-editor.org/rfc/rfc5418.txt Early Wireless Local Area Network (WLAN) deployments feature a fat Access Point (AP), which serves as a %stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. This memo provides information for the Internet community. This document is a product of the Control And Provisioning of Wireless Access Points Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5478 on IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces
A new Request for Comments is now available in online RFC libraries. RFC 5478 Title: IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces Author: J. Polk Status: Standards Track Date: March 2009 Mailbox:jmp...@cisco.com Pages: 6 Characters: 12810 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sip-rph-new-namespaces-04.txt URL:http://www.rfc-editor.org/rfc/rfc5478.txt This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
