Re: Early implementers motivations [was Re: Running Code]
Marc Petit-Huguenin a écrit : OK, so nearly everybody seems to think that I misunderstood the motivations of early implementation contributors, so let's ask them directly. 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. For the purpose of this exercise, an early implementation is an implementation of an IETF protocol under development as an Internet-Draft. I did early implementations in the Mobile IPv6 space. First, AH protection of MIP6 signalling. Then an implementation of 'BAKE', a very early other-person proposal for what later became RR tests for RO. That was a good exercice to understand the landscape, but unfortunately none got into an RFC. I felt it a bit disappointing and I decided to never ever again implement anything until it's an RFC at least Proposed Standard. I thus later did larger implementation effort of Mobile IPv6 RFC Proposed Standard, of MUST features but which were not used by anybody else... and even later suggested for deprecation. That's even more disappointing. Usually, when I do early implementation my motivation has to do with competitivity: first let self impressed by an IETF great new feature, then be there first before the others, claim ownership, etc. Unfortunately it can easily be _too_ early implementation :-) Generally in the WGs where I participate, I find it very encouraging whenever implementers do talk. Alex ___ 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
The NTP issue is rather specific and affected ntpd when you had server pool.ntp.org server pool.ntp.org server pool.ntp.org in your configuration. And some those mirrors I mentioned are affected by *deterministic* reordering. They don't care if traffic hits the closest instance, they want to spread the load (security.debian.org, for instance, is difficult to serve from a single node from time to time). thanks for explaining that. and the nameserver examples you gave are all subject to rdns RTT sorting. If you follow Rule 9, you haven't got that many RTTs to sort by: Rule 10 ensures that there is a single IP address you should use as long as the service on it is reachable. Unless you cheat, deviate from Rule 9, contact additional servers, and gather additional RTTs--but you have to cheat to get that data. i don't know any recursive nameservers that follow RFC 3483 for authority server selection? (your example here was of authority nameservers.) and they have to use drastically low TTL's to prevent mobility from breaking their assumptions. and they have no way to cope with opendns or any other global or semi-coherent caching layer. and even when they use TTL=0 and happen to be talking to an rdns who shares topology with the stub, they're making an educated guess without knowing what kinds of wormholes the stub may have access to, whether VPN, private interconnects that don't show up in global BGP, or whatever. Well, if it's not a good idea, why are most large web sites served this way? nobody ever got fired for buying $whatever. so: great marketing trumps any kind of engineering whether good or bad. I suspect there is currently no better way to distribute initial client requests than to play DNS tricks. since the web protocols support both permanent and temporary redirects, i've always preferred approaches like IBM's over approaches like akamai's. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: jim bound
I'll add my voice as another former DEC colleague who was saddened by this news. Jim never shied away from a challenging or contentious job. For example, the work on enterprise networks in RFCs 4852, 4057 could only have been done by someone with Jim's fortitude. I believe we are all better off for having known Jim, and I will miss him. Fred fred.l.temp...@boeing.com -Original Message- From: Paul Vixie [mailto:vi...@isc.org] Sent: Friday, March 06, 2009 11:25 PM To: ietf@ietf.org Subject: jim bound i shared the news with some coworkers from DEC (where jim and i both worked back in the early 1990's). one of them said: Wow, sorry to hear it. Jim treated networking like he was still in 'Nam and beauracracy was Charlie. He always took the hill. another added: I would only add that he never left any behind. jim will be missed, both sorely and otherwise, by me and by many others. ___ 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: [IAB] SAVI/SHARA/BEHAVE/AUTOCONF/LISP conflicts (Was: Re: 74th IETF - Agenda)
On Mar 5, 2009, at 12:47 PM, Dave Thaler wrote: I would expect a big overlap in interest in SHARA vs V6OPS too (for example I need to be in both). So even if you move any one of SHARA/V6OPS/SAVI, there'll still be issues. scheduling is hard... if I could get my wishes: I wish to resolve the overlap between 6AI and GROW, both are scheduled Thu 9-11:30AM at this time. -Original Message- From: iab-boun...@iab.org [mailto:iab-boun...@iab.org] On Behalf Of Fred Baker Sent: Wednesday, March 04, 2009 12:42 AM To: Jari Arkko Cc: wgcha...@ietf.org; i...@isi.edu; Autoconf Chairs; bofcha...@ietf.org; Behave Chairs; IETF Agenda; savi- cha...@tools.ietf.org Subject: Re: [IAB] SAVI/SHARA/BEHAVE/AUTOCONF/LISP conflicts (Was: Re: 74th IETF - Agenda) SAVI/v6ops on Monday is also a problem. I chair one and am a draft author in the other. On Mar 3, 2009, at 5:53 AM, Jari Arkko wrote: Monday: SAVI and SHARA conflict is bad from my perspective, but I could live with it by skipping SAVI :-( if needed. However, Marcelo is the key author of SAVI, and also a chair of SHARA. This conflict needs to be resolved... Tuesday: AUTOCONF and BEHAVE is bad from my perspective, but I can live with it if the BEHAVE IPv4-IPv6 work is not in this slot. Wednesday: LISP and BEHAVE are in the same slot. I'm the AD for LISP, and if the Behave guys are discussing IPv4-IPv6 in this slot, that's bad. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
So the answer to your question is that Experimental RFCs are different from Standards Track ones because, among other things, there is no implicit IETF recommendation of implementation and deployment of the technology and because part of the purpose of publication is educational. If a proposed standard is not freely implementable, in general it should not be accorded any status beyond a mere proposal. I do see one possible exception. It is ok for the proposal to start moving along the path towards becoming a standard if it can't possibly reach that point before the patents expire. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
But an experimental RFC is not a Proposed Standard, a proposed standard, a document that is in the process of being considered for standardization, or any other sort of standard or prestandard. There are people who propose this as a standard; in factual terms, that makes it a proposed standard. Whether or not the fact of publication as an experimental RFC would make it one, it is one already. If publication as an experimental RFC entails any sort of approval, such approval is what a patented proposed software standard should not get. ___ 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 wrote: 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. i'm not sure we're in the same discussion. pool.ntp.org is using short ttl and silent truncation and round robin. there's no geo-ip stability that could be hurt by client-side reordering or rerandomizing. and the nameserver examples you gave are all subject to rdns RTT sorting. the large RRset approach works just fine, and is not related to Rule 9. pool.ntp.org divides itself up into subdomains (okay they are really hostnames) for each country-code so that you get addresses in that country code. NTP in the future will take advantage of the fact that it gets back multiple addresses and will use more than just one of them to find NTP servers. The order does not really matter and it's better that there be no particular order so that we do not overload any one server. Danny ___ 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
On Mar 8, 2009, at 21:24, Danny Mayer wrote: i'm not sure we're in the same discussion. pool.ntp.org is using short ttl and silent truncation and round robin. there's no geo-ip stability that could be hurt by client-side reordering or rerandomizing. and the nameserver examples you gave are all subject to rdns RTT sorting. the large RRset approach works just fine, and is not related to Rule 9. pool.ntp.org divides itself up into subdomains (okay they are really hostnames) for each country-code so that you get addresses in that country code. NTP in the future will take advantage of the fact that it gets back multiple addresses and will use more than just one of them to find NTP servers. The order does not really matter and it's better that there be no particular order so that we do not overload any one server. Hi everyone, Funny the NTP Pool was brought up as an example. I'm looking after pool.ntp.org and I actually subscribed earlier in the week to comment on the round robin issue. :-) It's a little more complicated than what Paul described above (although it worked like that until ~2005 when I took over maintaining the system). When you query pool.ntp.org (or 1.pool.ntp.org etc), the DNS server does the IP to geo-location thing to automatically select the sub- zone. You can also explicitly ask for the sub-zone with 0.us.pool.ntp.org, 0.north-america.pool.ntp.org, etc. Paul is right that there's no problems with geo-stability because the DNS server will generally just give you servers from one area anyway; but we can get hurt by dumb re-ordering. For distributing the load[1] we depend on clients making mostly random picks when receiving multiple A records. Within each zone we have anywhere from a dozen to 1000+ servers[2]. The DNS server will return a list of A records weighted by the bandwidth the server administrator have told us they have. This is absolutely crucial. Before I implemented the current system, we just used a frequently updated zone with rotating A records and once or twice a day server operators with a small pipe (say a T1) or a small scale router would get overloaded enough that they'd leave the pool. It's critical to the longevity and the geographic diversity of the pool that small operators are able to contribute; even if they handle much less traffic than others. If RFC 3484 section 6 rule 9 really is implemented with matching prefixes all the way up to /2, I'd worry that could mess up the weighting we do and cause operators on unlucky IP addresses to have to stop offering their service. Since the DNS server does most of the weighting by giving just a few records from a usually much larger set, I could just return fewer A records to force my choice. But returning ~5 A records is valuable - some NTP servers knows how to use multiple A records from one lookup (ntpd in the future being one of them, as Danny pointed out). Having the client be smart would be absolutely unhelpful. Someone was arguing that the client might have useful network knowledge to apply. I don't know of any actual implementations of that whereas there are lots of deployed implementations with the DNS server being smart and/or deliberate about the records returned. - ask [1] The NTP Pool is used a lot. You'd have an unlikely network to not have some local users. It's the default in for example most Linux distributions and many consumer devices. Practically none of the manufacturers contribute anything back; but the whole point of the NTP Pool is to preserve NTP as a useful public resource, so better us than some poor overloaded NIST server! I don't know how many clients we have; but the name servers do about 20m requests a day; and that's basically only counting dumb ntp clients because the long running daemons generally just do one set of lookups on startup. It also, obviously, doesn't count the effects of local caches. In any case: It's a lot of users. [2] There are ~1743 active server in the pool right now distributed around the world: http://www.pool.ntp.org/zone - about 1000 in Europe and just under 600 in North America, http://www.pool.ntp.org/zone/ europe and http://www.pool.ntp.org/zone/north-america -- http://develooper.com/ - http://askask.com/ ___ 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: 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. i'm not sure we're in the same discussion. pool.ntp.org is using short ttl and silent truncation and round robin. there's no geo-ip stability that could be hurt by client-side reordering or rerandomizing. The NTP issue is rather specific and affected ntpd when you had server pool.ntp.org server pool.ntp.org server pool.ntp.org in your configuration. And some those mirrors I mentioned are affected by *deterministic* reordering. They don't care if traffic hits the closest instance, they want to spread the load (security.debian.org, for instance, is difficult to serve from a single node from time to time). and the nameserver examples you gave are all subject to rdns RTT sorting. If you follow Rule 9, you haven't got that many RTTs to sort by: Rule 10 ensures that there is a single IP address you should use as long as the service on it is reachable. Unless you cheat, deviate from Rule 9, contact additional servers, and gather additional RTTs--but you have to cheat to get that data. and they have to use drastically low TTL's to prevent mobility from breaking their assumptions. and they have no way to cope with opendns or any other global or semi-coherent caching layer. and even when they use TTL=0 and happen to be talking to an rdns who shares topology with the stub, they're making an educated guess without knowing what kinds of wormholes the stub may have access to, whether VPN, private interconnects that don't show up in global BGP, or whatever. Well, if it's not a good idea, why are most large web sites served this way? I suspect there is currently no better way to distribute initial client requests than to play DNS tricks. -- 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: Reverse IPv6 DNS checks on ietf MXs?
On Fri, Mar 06, 2009 at 04:42:29PM -0800, Doug Otis wrote: When there is to be reverse namespace, it should be ensured to work. In reality, this is not always the case. That is either an impossible goal, or else a meaningless requirement. In some sense, the reverse tree always works: you send a query in, and you get the answer that the global distributed database can give you (one of which is, dunno -- I didn't get an answer in time, so I gave up). What you might asking for with ensured to work is what the reverse-mapping-considerations draft calls existing reverse data. The idea is roughly that, for any address-type answer from a forward zone, if you query that address in the reverse zone you get some positive answer (e.g. you get a PTR record). What I suspect you're asking for with ensured to work is what the reverse-mapping-considerations draft calls matching reverse data. The idea here is roughly that the PTR record you eventually get corresponds to the name you originally queried. Regardless of which of the latter two you want, however, the fact is that the reverse tree is only ever going to be as operative as the operators of those reverse trees make it. Since we have plenty of examples of bizarrely broken behaviour in a forward zone, there's no reason to imagine that the reverse is somehow special and more likely to work. Therefore, I say the goal is impossible. Reverse namespace is often used to determine, by the nature of the PTR labels, whether an IP address might be dynamically assigned before deciding to accept email from a specific IP address. That very practice is one of the more contentious pieces around the draft. If you want to discuss this further, I encourage you to take the discussion to DNSOP, where the draft was last considered, since that's the WG that will have to be persuaded to send the document along if it is to go anywhere. Best, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
At 15:12 08-03-2009, Richard M Stallman wrote: But an experimental RFC is not a Proposed Standard, a proposed standard, a document that is in the process of being considered for standardization, or any other sort of standard or prestandard. There are people who propose this as a standard; in factual terms, that makes it a proposed standard. Whether or not the fact of publication as an experimental RFC would make it one, it is one already. In IETF terms: Internet specifications go through stages of development, testing, and acceptance. Within the Internet Standards Process, these stages are formally labeled maturity levels. The entry-level maturity for the standards track is Proposed Standard. A specific action by the IESG is required to move a specification onto the standards track at the Proposed Standard level. As the draft was not approved by the IESG as a Proposed Standard, the fact is that most people in the IETF community would not consider it as a proposed standard. The Experimental designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process. Publication as an Experimental RFC does make a document a standard. The Status of This Memo which is prominently displayed on the first page of the RFC mentions that: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
On Mon, 09 Mar 2009 11:07:10 -0700 SM s...@resistor.net wrote: As the draft was not approved by the IESG as a Proposed Standard, the fact is that most people in the IETF community would not consider it as a proposed standard. The Experimental designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process. Publication as an Experimental RFC does make a document a standard. The Status of This Memo which is prominently displayed on the first page of the RFC mentions that: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Put another way, an Experimental RFC is no more an IETF standard than a conference or journal publication. Someone has done something that is perceived to be of enough interest to the community to publish as an RFC, but it is manifestly *not* an IETF standard of any kind. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
At 11:14 09-03-2009, Steven M. Bellovin wrote: Put another way, an Experimental RFC is no more an IETF standard than a conference or journal publication. Someone has done something that is perceived to be of enough interest to the community to publish as an RFC, but it is manifestly *not* an IETF standard of any kind. You said it better than me. There was a mistake in my previous message. A not was omitted. The correct sentence is: Publication as an Experimental RFC does not make a document a standard. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call for draft-housley-tls-authz
1) Patents happen, get over it. Under the current patent system a company that does not apply for patents risks finding that a patent troll has applied for their idea. This is perjury, it should be prosecuted. But it is not. And fighting that type of lawsuit has cost comapnies involved in IETF $5 million or more to have a completely ridiculous claim thrown out. So nobody should be appologizing for applying for patents. It is simply a necessary concern for any major company. 2) Very few patents are so essential that they are worth more than interoperability. In the communications world the value lies in the ability to connect. There are very few technologies that are so compelling that the value of the enhancement to communication that they bring is greater than the cost of a smaller communications network. The only example I can think of in the history of the Internet is public key cryptography and the original Diffie Hellman/RSA patents. 3) It follows that the only allowable patents are on non-essential aspects If someone wants to use a proprietary encryption cipher with SMTP, let them. And make sure that the standard specifies how to do so in order that unencumbered implementations can take advantage of the feature when it becomes available. 4) In rare instances a standard can turn a worthless patent into a valuable one. But only if the exercise of the patent is made essential to the communications role. As in the audio and video codecs that became essential due to being required for DVD. Sometimes groups try to spring a patent by surprise. That is irritating. But it happens much less now that patent applications are no longer secret in the US. There is definitely a problem with IETF rules in this area. In my view the IPR regime is a part of the requirements for the spec. 5) Blanket rules give purported patent claims too much power Most US patents are completely worthless as far as enforcement goes. The main use of patents is to persuade Venture Capital to part with funds and some small time trolls extort license fees. But if the IETF were to adopt a hard rule that said that it would adopt no standard with a proprietary claim then people will quickly start claiming a proprietary interest in technologies that they don't want to happen for whatever reason. There is no practical means for the IETF to adjuicate on such claims. Its easy enough to propose forming a board, but who would sit on it? Who would have the legal and technical skills and want to accept the liability? The IPR working group turned into a farce because the two principal sides that showed up were (1) the companies with big patent portfolios that they would rather not have to think about, still less search for potential claims and (2) professional expert witnesses in patent cases. Ob. Disclosure: Yes, I do offer consulting and expert witness services in IPR disputes. This started as a dodge I learned from Alan Shiffman, once you announce you are offering services as an expert witness in an area, you are less likely to be dragged into somebody else's patent dispute as has happend from time to time, or at least if you do get dragged in you at least get paid. From: ietf-boun...@ietf.org on behalf of Richard M Stallman Sent: Sun 3/8/2009 6:12 PM To: John C Klensin Cc: jorge.contre...@wilmerhale.com; ietf@ietf.org Subject: Re: Consensus Call for draft-housley-tls-authz But an experimental RFC is not a Proposed Standard, a proposed standard, a document that is in the process of being considered for standardization, or any other sort of standard or prestandard. There are people who propose this as a standard; in factual terms, that makes it a proposed standard. Whether or not the fact of publication as an experimental RFC would make it one, it is one already. If publication as an experimental RFC entails any sort of approval, such approval is what a patented proposed software standard should not get. ___ 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: Consensus Call for draft-housley-tls-authz
Steve, Endorsment of a standard implies two (separable) assertions: 1) Do 'X'. 2) If you are going to do 'X', then do it by doing 'Y' An experimental specification on the other hand contains the assertions 1) It might be desirable to do 'X' 2) It might be possible to do 'X' by doing 'Y' So an experimental RFC does go part way towards a standard. But where it falls short is precisely the area where issues such as IPR come in. In particular the question of whether the need for 'X' justifies the IPR encumbrance. If the market, of its own accord suddenly goes off and starts implementing Y, it becomes pretty clear that there is a need. But offhand, I can really think of no example other than public key crypto where this was the case. From: ietf-boun...@ietf.org on behalf of Steven M. Bellovin Sent: Mon 3/9/2009 2:14 PM To: SM Cc: r...@gnu.org; ietf@ietf.org Subject: Re: Consensus Call for draft-housley-tls-authz On Mon, 09 Mar 2009 11:07:10 -0700 SM s...@resistor.net wrote: As the draft was not approved by the IESG as a Proposed Standard, the fact is that most people in the IETF community would not consider it as a proposed standard. The Experimental designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process. Publication as an Experimental RFC does make a document a standard. The Status of This Memo which is prominently displayed on the first page of the RFC mentions that: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Put another way, an Experimental RFC is no more an IETF standard than a conference or journal publication. Someone has done something that is perceived to be of enough interest to the community to publish as an RFC, but it is manifestly *not* an IETF standard of any kind. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ 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
Reminder: Tools codesprint at IETF74
If you are planning to join the codesprint at IETF74, please add yourself to the wiki page at http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF74SprintSignUp to help us build a rough idea of how many folks will be present. More information about this sprint can be found at http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF74Sprint If you can't work with the wiki for some reason, please drop me a note. Thanks, RjS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
On 3/9/09 11:14 AM, Steven M. Bellovin s...@cs.columbia.edu wrote: On Mon, 09 Mar 2009 11:07:10 -0700 SM s...@resistor.net wrote: As the draft was not approved by the IESG as a Proposed Standard, the fact is that most people in the IETF community would not consider it as a proposed standard. The Experimental designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process. Publication as an Experimental RFC does make a document a standard. The Status of This Memo which is prominently displayed on the first page of the RFC mentions that: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Put another way, an Experimental RFC is no more an IETF standard than a conference or journal publication. Someone has done something that is perceived to be of enough interest to the community to publish as an RFC, but it is manifestly *not* an IETF standard of any kind. The IETF might view it this way. Large parts of the (standardization) world does not. One example in my field of work is FLUTE, and the surrounding infrastructure of frameworks and FEC codes. To the best of my recollection, these specifications were originally issued as Experimental RFCs, for reasons of congestion control worries. (They are also heavily encumbered, but that was not really an issue according to my recollection.) The Experimental status did not stop 3GPP and other SDOs to normatively reference them, and treat them just like any other IETF RFC. Note that 3GPP could NOT do that with a journal publication... I could name more examples, both when it comes to referencing SDOs and referenced RFC types (including normative references to at least Historic, Obsolete, Informational). Stephan --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ 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: Consensus Call for draft-housley-tls-authz
On Mon, 09 Mar 2009 15:35:31 -0700 Stephan Wenger st...@stewe.org wrote: The IETF might view it this way. Large parts of the (standardization) world does not. One example in my field of work is FLUTE, and the surrounding infrastructure of frameworks and FEC codes. To the best of my recollection, these specifications were originally issued as Experimental RFCs, for reasons of congestion control worries. (They are also heavily encumbered, but that was not really an issue according to my recollection.) The Experimental status did not stop 3GPP and other SDOs to normatively reference them, and treat them just like any other IETF RFC. Note that 3GPP could NOT do that with a journal publication... I could name more examples, both when it comes to referencing SDOs and referenced RFC types (including normative references to at least Historic, Obsolete, Informational). This is, I think, the second- or third-most-common topic on the IETF list: should we rename the document series to prevent that... (#1 is non-ASCII formats for RFCs; #2 -- by volume of postings, rather than frequency of discussion -- might be IPR.) Other than giving up the RFC label for Experimental documents, it's hard to see what the IETF can do. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call for draft-housley-tls-authz
When British Leyland shut down the assembly line for the Triumph TR7 they found a note that said, 'Your proposal to prime and paint the TR7 bodyshells before moving them a hundred miles in open rail cars to the assembly plant has been made before. If only stopping rust was so simple'. The fact that a proposal has been made before and ignored does not diminish its value. How frequently does a sensible proposal have to be made to receive a susbstantive response? From: ietf-boun...@ietf.org on behalf of Steven M. Bellovin Sent: Mon 3/9/2009 6:40 PM To: Stephan Wenger Cc: SM; r...@gnu.org; ietf@ietf.org Subject: Re: Consensus Call for draft-housley-tls-authz On Mon, 09 Mar 2009 15:35:31 -0700 Stephan Wenger st...@stewe.org wrote: The IETF might view it this way. Large parts of the (standardization) world does not. One example in my field of work is FLUTE, and the surrounding infrastructure of frameworks and FEC codes. To the best of my recollection, these specifications were originally issued as Experimental RFCs, for reasons of congestion control worries. (They are also heavily encumbered, but that was not really an issue according to my recollection.) The Experimental status did not stop 3GPP and other SDOs to normatively reference them, and treat them just like any other IETF RFC. Note that 3GPP could NOT do that with a journal publication... I could name more examples, both when it comes to referencing SDOs and referenced RFC types (including normative references to at least Historic, Obsolete, Informational). This is, I think, the second- or third-most-common topic on the IETF list: should we rename the document series to prevent that... (#1 is non-ASCII formats for RFCs; #2 -- by volume of postings, rather than frequency of discussion -- might be IPR.) Other than giving up the RFC label for Experimental documents, it's hard to see what the IETF can do. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ 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
Last Call: draft-atlas-icmp-unnumbered (Extending ICMP for Interface and Next-hop Identification) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Extending ICMP for Interface and Next-hop Identification ' draft-atlas-icmp-unnumbered-06.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 i...@ietf.org mailing lists by 2009-04-06. 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. This is a second IETF Last Call for this document. In January 2009, the document was sent back to the WG due to an IPR disclosure that appeared late in the process. After a revised IPR disclosure was posted in February, there were no objections in a new WGLC and this draft can again move forward. The file can be obtained via http://www.ietf.org/internet-drafts/draft-atlas-icmp-unnumbered-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14094rfc_flag=0 The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1065/ https://datatracker.ietf.org/ipr/1089/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-radext-design (RADIUS Design Guidelines) to BCP
The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'RADIUS Design Guidelines ' draft-ietf-radext-design-07.txt as a BCP 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 i...@ietf.org mailing lists by 2009-03-23. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-design-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16426rfc_flag=0 The following IPR Declarations may be related to this I-D: ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dime-mip6-split (Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction) to Proposed Standard
The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction ' draft-ietf-dime-mip6-split-16.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 i...@ietf.org mailing lists by 2009-03-23. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-16.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14871rfc_flag=0 The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/964/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-netlmm-grekey-option (GRE Key Option for Proxy Mobile IPv6) to Proposed Standard
The IESG has received a request from the Network-based Localized Mobility Management WG (netlmm) to consider the following document: - 'GRE Key Option for Proxy Mobile IPv6 ' draft-ietf-netlmm-grekey-option-06.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 i...@ietf.org mailing lists by 2009-03-23. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-netlmm-grekey-option-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17665rfc_flag=0 The following IPR Declarations may be related to this I-D: ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
