Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
In many countries service providers are required to track which user behind a NAT mapped to what IP/port the used. NAT != privacy. -- Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See http://www.standardstrack.com/ietf/lemonade/ On Jun 7, 2014, at 9:20 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hi Dan, On 07/06/14 02:38, Dan Wing wrote: Stephen, It seems NAPT has become IETF's privacy feature of 2014 because multiple users are sharing one identifier (IP address and presumably randomized ports [RFC6056], although many NAPT deployments use address ranges because of fear of compressing log files). As a former co-chair of BEHAVE it is refreshing to see the IETF embracing NAPT as a desirable feature. Embracing seems like significant overstatement to me, but maybe that's understandable given how calmly NAT is generally debated. NATs have both good and bad properties. The slightly better privacy is one of the good ones. Recognising that reality is neither embracing nor refreshing IMO, nor does it mean NAPT is (un)desirable overall. (That's an argument I only ever watch from the side-lines thanks:-) However, if NAPT provides privacy and NAT Reveal removes it, where does that leave a host's IPv6 source address with respect to BCP188? Afterall, an IPv6 address is quite traceable, even with IPv6 privacy addresses (especially as IPv6 privacy addresses are currently deployed which only obtain a new IPv6 privacy address every 24 hours or when attaching to a new network). If BCP188 does not prevent deployment of IPv6, I would like to understand the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of IPv6+privacy_address. I'm frankly amazed that that's not crystal clear to anyone who has read all 2.5 non-boilerplate pages of the BCP. Or even just the last two words of the 1-line abstract (hint: those say where possible.) Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Adding new identifiers with privacy impact, as proposed here, is quite different. S. PS: If someone wants to propose what they think is a practical way to mitigate the privacy issues with source addresses, please write a draft first and then start a separate thread somewhere. -d ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: Regarding call Chinese names
I kept my maiden name, too. Another Western option, hyphenation, was not for us. Who wants to be a Spear-Burger? Unless you want a Pepsi and chips with that. See http://en.wikipedia.org/wiki/Olympia_Cafe On Jul 10, 2013, at 9:00 PM, Ida ida_le...@yahoo.com wrote: Sent from my iPad On 2013-07-10, at 8:59 PM, Ida ida_le...@yahoo.com wrote: One comment: I think most of the Chinese women don't change to our husband's last name. So, my husband is not Mr Leung. We love to keep our own last name. ...Ida Sent from my iPad On 2013-07-10, at 8:04 PM, Hui Deng denghu...@gmail.com wrote: Hello all We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 Feel free to let us know if you have any other issues? Best regards, -Hui Deng signature.asc Description: Message signed with OpenPGP using GPGMail
Re: IETF Meeting in South America
Riiight. That is why one never has to attend an IETF meeting in person to serve on NOMCOM, one does not need travel support from one's employer to be on the IESG, and why people who never come to IETF meetings are the rule and not the exception with respect to getting documents adopted and published. Oops - I got my sense wrong there…. On May 28, 2013, at 2:29 AM, Dave Crocker d...@dcrocker.net wrote: On 5/27/2013 11:38 PM, Christian O'Flaherty wrote: I would like to follow up on this proposal. Having a meeting in South America scheduled two or three years in advance will let us engage local organisations and individuals on a project. We did several activities in the region trying to encourage IETF participation, but we're going to be much more effective if they're part of a plan with a strong commitment (and effort) from the IETF community. Such a project sounds like an excellent idea and it could be interesting to pursue it with coordination from the IETF community. One point worth noting is that the primary work of the IETF is conducted over email. Consequently, the project does not require an in-person meeting with the IETF community. In fact, relying on an in-person meeting for the effort is counter-productive training for being effective in the IETF. I don't mean that such meetings aren't useful, but that I believe they are secondary to the work that is done over the rest of the time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)
Works for me. -- Sent from my mobile device. Thanks be to lemonade! http://www.standardstrack.com/ietf/lemonade/ -Original message- From: Alexey Melnikov alexey.melni...@isode.com To: Burger Eric ebur...@cs.georgetown.edu Cc: Robert Sparks rjspa...@nostrum.com, ietf@ietf.org Sent: Tue, Apr 2, 2013 09:53:39 GMT+00:00 Subject: Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt) Hi Eric, I am sorry if I sound pedantic below, but I think your suggestion can be misinterpreted and thus needs improving: On 28/03/2013 12:13, Burger Eric wrote: Rather than guessing all of the bad things that could happen, I would offer it would be better to say what we mean, like: The IMAP interface MUST NOT provide any IMAP facilities that modify the underlying message and message metadata, such as mailbox, flags, marking for deletion, etc. If the client is authenticated and authorized, the IMAP interface MUST provide per-user marking of the underlying message as read or flagged. One way to implement this is in an IMAP server is to always fail commands for modifying message metadata. Another way of implementing this is to allow them, but ignore (don't persist) results. Both ways were used in the past and they have different effect on IMAP clients. I hope the requirement is intended to allow for either. Another thing to consider is that for IMAP servers that implement IMAP ACL, the easiest way to meet the intended requirement is by not allowing unauthorized users to access some commands on a mailbox. Again, a possible reading of your suggested text is that that is not allowed. So, my suggestion is to change MUST NOT provide any IMAP facilities ... to MUST disallow any IMAP facilities
Re: Less Corporate Diversity
Quite the contrary. I am interpreting a few of the 'diversity' posts as saying the IETF has fewer companies participating and much fewer smaller companies participating. And I am interpreting those posts as implying some nefarious plot on the part of large, Western, White-European-Male-Dominated companies to make it that way. I was just positing that the IETF might be reflective of the networking industry as a whole. My thesis, not at all proven and one I am not married to, is there are fewer *companies* out there. With fewer companies, we should not be surprised there are fewer companies participating. On the big side, a ton of major players either merged or left the business. On the small side, a bunch of companies either got acquired or went bankrupt. Fred Baker and Keith Moore have it right: we need to attract new blood. On Mar 21, 2013, at 1:01 AM, Hector Santos hsan...@isdg.net wrote: On 3/20/2013 3:18 PM, Eric Burger wrote: How much is the concentration of corporate participation in the IETF a result of market forces, like consolidation and bankruptcy, as opposed to nefarious forces, like a company hiring all of the I* leadership? We have mechanisms to deal with the latter, but there is not much we can do about the former. I am not catching the question. Are you concern there is an increasing potential for a conflict of interest loophole the IETF may no longer afford to manage and control? We will always have Cooperative Competition. The IETF damage can only be to sanction the standardization of a problematic method or technology and/or the straggle hold of a market direction. Generally, the market will speak for itself. We need the market and technology leaders for the rest to follow, but the IETF role should continue to be the gatekeeper and watchdog for open and public domain standards. -- HLS
Re: Diversity of IETF Leadership
Going a bit over-the-top: is there an interaction between sex and sexual orientation? Can one count as the other? On Mar 20, 2013, at 8:10 AM, Riccardo Bernardini framefri...@gmail.com wrote: On Wed, Mar 20, 2013 at 11:53 AM, Margaret Wasserman m...@lilacglade.org wrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. I am not suggesting that we start collecting or publishing this information, just saying that it makes it hard to tell whether our leadership is reasonably representative of the community in some of these areas. I would say that in this case we are almost surely automatically fair: while one can suspect that gender or geographical origin could add a bias (even an unwanted one), if I do not know the, say, sexual orientation of a candidate, I cannot discriminate (even on a subconscious level) using that information. Also, I think there are some area where diversity is important to the IETF that are not on this list, like geographic location, corporate affiliation and industry segment (vendor, operator, researcher, etc.). Margaret
Less Corporate Diversity
How much is the concentration of corporate participation in the IETF a result of market forces, like consolidation and bankruptcy, as opposed to nefarious forces, like a company hiring all of the I* leadership? We have mechanisms to deal with the latter, but there is not much we can do about the former. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: IPR view (Re: Internet Draft Final Submission Cut-Off Today )
I do but don't care. With my IETF hat on, the whole point of the cut-off is to enforce a physical barrier to ensure we do not ever hear, I posted this draft yesterday, let's talk about it in a work group. With my legal services hat on, with the US joining the rest of the world with first-to-file, those few weeks of publication could mean the difference between a free and open standard and a NPE swooping in and attempting to tax the industry. On Mar 7, 2013, at 5:56 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 03/07/2013 09:34 AM, Carsten Bormann wrote: Oh, and one more data point: The Internet-Draft archive also functions as a timestamped signed public archival record of our inventions. (Which are often trivial, but triviality won't stop patenting of copycats, while a good priority more likely will.) FWIW, I think that's an incidental good side-effect but shouldn't drive what we do here. My take is that I don't care about this, so long as drafts that are discussed at meetings are posted early enough to allow folks a chance to read them. The current rule achieves that well enough, as could a less coarse-grained rule. I've not seen a worked out proposal for such a less coarse-grained rule that achieves that yet. S This function is effectively suspended for six weeks a year. Grüße, Carsten PS.: (If that sounds like I'm contradicting myself that's only because we haven't found the right solution yet.) On Feb 27, 2013, at 19:49, Carsten Bormann c...@tzi.org wrote: On Feb 27, 2013, at 19:18, ned+i...@mauve.mrochek.com wrote: routing around obstacles It turns out for most people the easiest route around is submitting in time. That is actually what counts here: how does the rule influence the behavior of people. Chair hat: WORKSFORME. (And, if I could decide it, WONTFIX.) Grüße, Carsten
Re: Orlando time for human language draft discussion
Confirmed? Venue? On Mar 9, 2013, at 11:35 AM, Peter Saint-Andre stpe...@stpeter.im wrote: I replied, sorry about the delay. It looks like Thursday lunch would work well. On 3/5/13 4:47 AM, Randall Gellens wrote: Hi all, I created a Doodle poll to see if we can find a time in Orlando to meet face to face. Doodle poll for time at Orlando to discuss open issues and moving forward with Human Language Negotiation: http://doodle.com/uwedikez6etwsf39 Link to current version (-02) of draft: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt
Re: Appointment of a Transport Area Director
Dave said what I was thinking, but with many more words. *We* have put ourselves in a box. If we work the way we worked when we published 100 RFC's a year, we are sure to fail. As a side note, there are over 100 drafts in the RFC Editor queue this instant. As Dave and Hannes have pointed out, the IESG has effectively created the unwritten requirement, must work for a very large company. Look at the current IESG. Two thirds are directly employed by large companies. Of the five remaining, two have their IETF participation paid for by the US government and one has their participation paid for by the EU. One AD looks like he comes from academia, but really works in their FFRDC, which is a fancy term for a large company owned by a university. So, out of 15 Area Directors, we have precisely one who comes from a company or organization with less than $1B in revenues or direct government support. As has been pointed out numerous times, the 50% effort figure rapidly approaches 100%. That means we are telling the community that only people for whom their day job is being on the IESG are eligible to apply. Note my careful use of the word 'eligible.' How many people have been passed over for an AD nomination because they were unsure of where they would be working in a year or if they had employer support? The answer is a substantial number. I will say it again - the IETF is organized by us. Therefore, this situation is created by us. We have the power to fix it. We have to want to fix it. Saying there is nothing we can do because this is the way it is is the same as saying we do not WANT to fix it. On Mar 4, 2013, at 5:45 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: The time commitment is a very good point, Dave. If we want to also involve people who do not work for big corporations (or get otherwise sponsored by big organizations) then the idea of having ADs review every document may need to get a bit relaxed. Today, almost all of the ADs (and IAB members) work for major enterprises. In companies managers typically do not get involved in every little technical detail but rather need to ensure that the work gets done. Maybe ADs could delegate more tasks to directorates, as it is done in the security area already. This also avoids the problem that an AD becomes the bottleneck in understanding the work that working groups produce. This happened in the past as well. Ciao Hannes On Mar 3, 2013, at 6:14 PM, Dave Crocker wrote: On 3/3/2013 4:56 AM, Eric Burger wrote: The 50% time commitment is an IESG-imposed requirement. If that is really the problem, we have had areas with more than two ADs. Finding qualified Transport ADs has been a continuing problem for a number of years. This year's impasse was inevitable. Whatever the problem, it's deep-seated.[*] While the problem for Transport is extreme, it's generally difficult to find a good range of qualified candidates for AD. A major barrier is the time commitment to the job. And it's not really a 50% slot; the reality for most ADs seemed to be in the 75-100% range. This is a massive cost to their employer, both in raw dollars and opportunity cost -- ADs are typically senior contributors. That means removing a strategic resource from the company's main activities. To take a senior contributor away usually requires that the company be very large and have a very deep bench of talent. That's an onerous burden, in my view, and significantly reduces the pool of available candidates. The IESG needs to decide that the job is a 25% job -- an actual terms -- and then decide what tasks are essential to perform within that amount of time. This will require a significant change in the way ADs do their work. Reducing the real, budgeted time for an ADs job should significantly increase the pool of available candidates. As a side benefit, it should also significantly improve the diversity of the pool, along most parameters. As an obvious example of what to change, it means that ADs need to change their paradigm for document review. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Appointment of a Transport Area Director
There is obviously no easy fix. If there was, we would have fixed it, obviously. What I find interesting is after saying there is nothing we can do, you go on to make a few concrete proposals, like bringing the directorates more into the process. It is thinking like that, how to do things different, that will get us out of the bind we have made for ourselves. Note that I am not married to the idea of expanding the role of directorates. I am married to the idea that we can think ourselves outside of the box. On Mar 4, 2013, at 8:07 AM, Eggert, Lars l...@netapp.com wrote: Hi, On Mar 4, 2013, at 13:18, Eric Burger ebur...@standardstrack.com wrote: I will say it again - the IETF is organized by us. Therefore, this situation is created by us. We have the power to fix it. We have to want to fix it. Saying there is nothing we can do because this is the way it is is the same as saying we do not WANT to fix it. what is the fix? The IETF is set up so that the top level leadership requires technical expertise. It is not only a management job. This is a key differentiator to other SDOs, and IMO it shows in the quality of the output we produce. The reason the RFCs are typically of very good quality is that the same eyeballs go over all documents before they go out. This creates a level of uniformity that is otherwise difficult to achieve. But it requires technical expertise on the top, and it requires a significant investment of time. I don't see how we can maintain the quality of our output if we turn the AD position into a management job. Especially when technical expertise is delegated to bodies that rely on volunteers. Don't get me wrong, the work done in the various directorates is awesome, but it's often difficult to get them to apply a uniform measure when reviewing, and it's also difficult to get them to stick to deadlines. They're volunteers, after all. And, as Joel said earlier, unless we delegate the right to raise and clear discusses to the directorates as well, the AD still needs to be able to understand and defend a technical argument on behalf of a reviewer. If there is a controversy, the time for that involvement dwarfs the time needed for the initial review. There is no easy fix. Well, maybe the WGs could stop wanting to publish so many documents... Lars
Re: Appointment of a Transport Area Director
There are two other interpretations of this situation, neither of which I think is true, but we should consider the possibility. The first is the TSV is too narrow a field to support an area director and as such should be folded in with another area. The second is if all of the qualified people have moved on and no one is interested in building the expertise the IESG feels is lacking, then industry and academia have voted with their feet: the TSV is irrelevant and should be closed. Since I believe neither is the case, it sounds like the IESG requirements are too tight. On Mar 3, 2013, at 4:15 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Brian, you are essentially saying that the Nomcom should ignore the requirements. I believe we would attract more candidates right from the beginning if we lower the requirements. The transport area has historically had a this strong emphasis on congestion control expertise for at least one of the serving transport ADs and this requirement seems to reduce the pool of available candidates quite severely. Ciao Hannes On Mar 3, 2013, at 9:53 AM, Brian E Carpenter wrote: On 03/03/2013 05:00, IETF Chair wrote: ... advance. Since this discussion could lead to a change in the IESG requirements, the IESG encourages the community to take part in this discussion so that any changes are based on broad community input. When there is a choice between nominating nobody, and nominating someone with excellent IETF experience and management skills, but who is not a recognised specialist in the narrow technical area concerned, I believe that standing advice to the NomCom should be to appoint such a candidate. Also the standing advice to the confirming body should be to confirm such a nominee. We are too hung up on our narrow specialisations in the IETF. Brian smime.p7s Description: S/MIME cryptographic signature
Re: Appointment of a Transport Area Director
The 50% time commitment is an IESG-imposed requirement. If that is really the problem, we have had areas with more than two ADs. On Mar 3, 2013, at 7:50 AM, Eggert, Lars l...@netapp.com wrote: On Mar 3, 2013, at 13:37, Eric Burger ebur...@standardstrack.com wrote: There are two other interpretations of this situation, neither of which I think is true, but we should consider the possibility. The first is the TSV is too narrow a field to support an area director and as such should be folded in with another area. The second is if all of the qualified people have moved on and no one is interested in building the expertise the IESG feels is lacking, then industry and academia have voted with their feet: the TSV is irrelevant and should be closed. Since I believe neither is the case, it sounds like the IESG requirements are too tight. I don't believe the requirements are too tight. *Someone* one the IESG needs to understand congestion control. The likely possibility is that many qualified people failed to get sufficient employer support to be able to volunteer. It's at least a 50% time committment. Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [ietf-privacy] Comment: 'Privacy Considerations for Internet Protocols'
So what if we just said Security Considerations must include what some people call privacy considerations? If we cannot agree on a concise definition of security vs. privacy, what is the typical draft author going to do? -- Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See http://www.standardstrack.com/ietf/lemonade/ On Feb 26, 2013, at 3:08 PM, David Singer sin...@apple.com wrote: On Feb 26, 2013, at 14:42 , Claudia Diaz claudia.d...@esat.kuleuven.be wrote: On 26 Feb 2013, at 23:19:15, David Singer wrote: On Feb 26, 2013, at 14:11 , Claudia Diaz claudia.d...@esat.kuleuven.be wrote: On 26 Feb 2013, at 09:45:38, SM wrote: At 13:15 25-02-2013, Claudia Diaz wrote: If that entity is a gov/commercial organization, then security is the term likely to be used for the properties you want to achieve, while for those same properties privacy is the usual term when the entity is a private individual. There is currently a security considerations section in every IETF RFC. The draft recommends having a privacy considerations section too. The question which can arise is in which section the perspective should be covered. In other words it is about how to disambiguate between security and privacy. It's a tough one: I am not sure you can fully disambiguate the two terms if you are considering general-purpose protocols. For the purposes of debate, I am going to try. Security problem: something unintended happened which gave an attacker/opponent access to data, systems, or capability which was not an expected part of the identified system/protocol. Privacy problem: operation of the system/protocol gives undesirable exposure of private information not strictly needed for the operation desired. If you combine them, then indeed the privacy problem may well get worse. So, for example, the fact that on the internet your IP address is exposed as part of the protocol also gives your respondent probable knowledge of your location, and hence time of day. No rules were broken to see your IP address or draw conclusions from it - there was no 'break-in' or security hole that was taken advantage of. That's an interesting distinction. Translating it to concrete scenarios would make us however have to change how we usually use the terms. This can be counterintuitive in some cases: - If I browse to a website and my IP is exposed, then it is a privacy problem. If I browse to the same website over Tor and my IP is exposed because Tor is attacked, then it is a security problem. To be precise, there was a security breach (your IP address was exposed when the design of the protocol and your expectations said it would not be), and that resulted in a privacy problem. Many security problems indeed result in privacy issues (not surprisingly). - If the passwords to access the confidential information at the embassy are sent in clear (because nobody bothered to encrypt them), it is a privacy problem, and not a security problem. Agreed. The protocol was being operated in its expected way, and no protocol violation or break-in was needed. (It was the wrong protocol to use.) If someone manages to get my facebook password, then it is a security problem, and not a privacy problem (because it was not exposed by default). If they broke in, they took advantage of a security issue of some sort. The result was, again, a privacy violation. - If the gov listens to my encrypted conversations (eg, by reconstructing the conversation from the traffic), it is a security problem. If the minister of interior talks over an unencrypted line about his plans to catch terrorists, then it is a privacy problem. I think we are on the same page. Security breaches often result in privacy problems, but not always, and privacy issues don't always happen as a result of security breaches -- and it is the ones that don't that I think we should focus on. (Once the 'lock is broken' we can't say much about privacy, I fear -- we're into limiting damage). The famous CSS link-visited issue is a privacy issue, pure and simple. It's possible to write a script that finds out what links a user has recently visited, using public APIs in their intended way. Exploring what the privacy implications of using a specification in its normal way I think is way overdue. We can *also* think about specifying prudent steps to take such that if there is *also* a security break-in, the resulting privacy impact is minimized (e.g. keep as little private data as you for only as long as you need it, so if you have a data loss/leak/break-in, the impact is minimized). But that's secondary. David Singer Multimedia and Software Standards, Apple Inc. ___ ietf-privacy mailing list ietf-privacy@ietf.org
Re: The IETF is coming to New Delhi!
They've got us beat by 10 years. Hope they didn't register the trademark. On Feb 16, 2013, at 8:17 PM, Ole Jacobsen o...@cisco.com wrote: Sorry about the late announcement: http://www.ietfindia.in/ ... looks like it ends today, oh well. :-) Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo
Re: The RFC Acknowledgement
Abduussalam - You probably have seen many responses to your message talking about who goes into the Acknowledgements section. However, I am not sure your original question was answered. In short, it is the document editor that puts the acknowledgments section in. In most cases it will be obvious who gets listed there. That is the substance of the other messages on this thread. In rare cases a work group chair may get involved. As you are new, if you are a document editor, you can always ask your work group chair for guidance. Conversely, if you feel you should be in an acknowledgements section for your contributions, feel free to talk with the document editor (first) and work group chair (second) - Eric On Feb 8, 2013, at 10:11 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi folks, I am wondering how author/ietf-editor fill in the acknowledgement section in the RFCs or I-Ds. Does it make sense in IETF, or left for author opinion? I am getting requests from IETF WGs, IESG, and IAB for comments. My question is do you *make acknowledgements* in I-Ds or just *take comments* for I-Ds? IMO we get last call request for comments because RFC production is all about getting volunteering comments from Internet community to make I-Ds better, so does all I-Ds acknowledge (ACK) to any input comment before the last call and after or it is only before last call?, and if it gets submitted to IESG/IAB, and we comment does that have no ACK in I-D? I sometimes feel discouraged to participate in any world work if the process does not involve my existance, just used with ignoring ACK of the reviewers. IMO any comment has value to the authors (e.g. some think only experts' comments are important to ACK) and to IETF, otherwise, we may delete valuable ACKs in IETF, which is not right. Best Regards AB A participant that still did not complete a year working for IETF, but trying to continue :)
Re: I-D affects another or work in ietf groups
As well, if there is a conflict, it will certainly come out in IESG review or IETF Last Call. On Feb 8, 2013, at 11:27 PM, Fred Baker (fred) f...@cisco.com wrote: Speaking for myself, I would say that an internet draft is relevant to work in a working group if and only if it is covered by the charter of the working group. Anyone can claim anything to dodge the requirement that they ask relevant groups to review it. That doesn't make the claim true. In the event that you need a ruling, I would suggest discussing it with the relevant chairs and, if necessary, ADs. Generally speaking, they will have no axe to grind and can give you a reasonably objective answer. On Feb 8, 2013, at 7:56 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi folks, Related to one discussion with a participant about I-Ds affecting WGs, I have a question after reading two real incidents. The following two work process examples are to show the I-Ds/RFCs affects from participants point of view; 1) I got an understanding from one expert participant that his I-D is not related to one RFC, even though it does involve similar objectives and use-case, which was strange to me. So I understood from him that his I-D is not affected by that RFC, even though his I-D does not mention to exclude that RFC. IMO, I disagree with such producing I-D by separate review-approach unaffected by other related RFCs (i.e. not mentioned RFCs). 2) While I was discussing within a WG about an I-D which is a second version of one IETF prorocol, some participants thought that the I-D obsolete the old version even if not mentioned in the I-D. It then was requested to update and mention that it does not obsolete the older version. New versions are related and can affect each other, or affect people understanding, which requires more careful presentation for such I-D. I beleive that we have one source of producing RFCs, so all I-Ds and RFCs are related some how, and they affect each other. So when I review an item, I always like to consider all RFCs as much as I can to make Internet better. Is that approach right for review? please advise, AB
Re: Standards-essential patents under RAND licensing
Absolutely nothing. We're screwed. That's why one has to laugh out loud when we charter a work group to produce a royalty-free version of foo, because there are encumbered versions of foo out there. Unless the people with the rights to foo are participating and have offered their rights as part of the standardization process, what will be produced will almost certainly not be royalty-free, unless an active, conscious effort is made to ensure the encumbrances in the existing foos are not present in the new foo. On Jan 10, 2013, at 5:04 PM, tglassey tglas...@earthlink.net wrote: On 1/10/2013 1:22 PM, Dale R. Worley wrote: Recent actions by the US Department of Justice, the US Patent Office, the US Federal Trade Commission (which handles antitrust and consumer protection matters), and the US International Trade Commission (which has the power to exclude imports which violate US patents) suggest that US officials are starting to understand the proper way to handle standards-essential patents, that is, patented inventions which are incorporated into standards and the patent owner has promised to license under reasonable and non-discriminatory terms. It seems that in some cases, patent owners have not followed through to issue the required licenses, and then prosecuted other standard-users based on patent infringement. In particular (from the New York Times article linked below): Over the years [...] companies took Motorola at its word and developed products assuming they could routinely license Motorola's patents. But Motorola later refused to license its standard-essential patents and sought court injunctions to stop shipment of rival products. After Google purchased Motorola [...] it continued these same abusive practices. In recent months, the F.T.C. has issued position papers and filed friend-of-the-court briefs, opposing the motions for injunctions using standard patents. The Justice Department and European regulators have echoed the commission's stance. Justice Department and Patent Office Issue Policy Statement on Patents http://bits.blogs.nytimes.com/2013/01/08/justice-department-and-patent-office-issue-policy-statement-on-patents/ On Google, F.T.C. Set Rules of War Over Patents http://www.nytimes.com/2013/01/05/technology/in-google-patent-case-ftc-set-rules-of-engagement-for-battles.html?_r=0 United States Department of Justice and United States Patent Trademark Office Policy Statement on Remedies for Standards-Essential Patents Subject to Voluntary F/RAND Commitments http://www.justice.gov/atr/public/guidelines/290994.pdf Dale What do you do where a patent predates any standards use of the IP. I understand the issues of developing IP but what about IP that already existed before the standards processes incorporated it into their work product? Todd -- Regards TSG Ex-Cruce-Leo //Confidential Mailing - Please destroy this if you are not the intended recipient.
Re: IESG Considering a Revision to NOTE WELL
Way too simple, straightforward, and easy to understand. Can't we play lawyer-on-the-list and make it a full page again? -- Sent from my mobile device. Thanks be to lemonade! http://www.standardstrack.com/ietf/lemonade/ -Original message- From: IETF Chair ch...@ietf.org To: IETF Announce ietf-annou...@ietf.org Cc: IETF ietf@ietf.org Sent: Tue, Nov 6, 2012 15:01:59 GMT+00:00 Subject: IESG Considering a Revision to NOTE WELL The IESG is considering a revision to the NOTE WELL text. Please review and comment. Russ === Proposed Revised NOTE WELL Text === Note Well This summary is only meant to point you in the right direction, and doesn't have all the nuances. The IETF's IPR Policy is set forth in BCP 79; please read it carefully. The brief summary: - By participating with the IETF, you agree to follow IETF processes. - If you are aware that a contribution of yours (something you write, say, or discuss in any IETF context) is covered by patents or patent applications, you need to disclose that fact. - You understand that meetings might be recorded, broadcast, and publicly archived. For further information: Talk to a chair, ask an Area Director, or review BCP 9 (on the Internet Standards Process), BCP 25 (on the Working Group processes), BCP 78 (on the IETF Trust), and BCP 79 (on Intellectual Property Rights in the IETF).
Re: [RFC 3777 Update for Vacancies]
Sounds reasonable to me. On Oct 29, 2012, at 9:58 AM, John C Klensin wrote: --On Monday, October 29, 2012 14:06 +0100 Eliot Lear l...@cisco.com wrote: Bob, everyone, As I've mentioned, I'd prefer an alternative to what the authors have written. Call this the let's program ourselves out of a paper bag option, when we all agree. This may be a rule we would wish to generalize. Here is the basis for what I propose: 1. We have existing procedures to resolve contested removals – the recall process. 2. Uncontested essentially means that we as a community are in unanimous agreement that the position is vacant. That means that by definition, any no votes from a body means it's contested. 3. The least amount of power should be delegated to our bodies as is necessary for the organization's smooth operation. 4. Procedural arguments on the IETF list are tiresome, when we all agree on the right outcome ;-) With that in mind, I've attempted to reduce changes to a more simplified form, as follows: ... NEW: When an IETF body unanimously believes that a position on that body has been vacated, they may request confirmation of this by the community through an Extended Last Call with their reasoning. Should no objections be received during that period, the position is said to be vacant. Eliot, I generally like the general direction in which you are headed. On other other hand, your specific proposal creates an opportunity for a single individual, perhaps even one who follows the mailing list but who is not an active participant in the IETF or who just doesn't like the procedure, to disrupt things and throw us back on recalls. Given the number of occasionally-grumpy people in the extended community, that does not seem wise. Quick thought and strawman suggestion: how about we take your general model, but instead of using the absence of any objections as the not vacant, requires recall trigger, perhaps we could borrow a little bit from the recall model. For example, we might say that deciding that the procedure doesn't apply when the body thinks the position is vacant requires a petition endorsed by some number of people. The 20 of the recall procedure seems a bit high to me, but you get the general idea. One person claiming the position isn't really vacant could be just a grump; ten or twenty probably indicates that something odd is going on and a more heavyweight procedure is required. john
Re: [RFC 3777 Update for Vacancies]
Echoing John here, he very succinctly explains why setting out clear lines of what does or does not constitute abandonment invites abuse. If someone is acting against the interests of the IETF, we have lots of ways of dealing with it. If someone falls off the face of the Earth, and repeated attempts to contact them using legally recognized methods of notice fails, and more importantly they have a positive track record that spans over a decade, we can use our existing nomcom tools to replace their nomcom-appointed duties. I would offer that a person in such a position with such demonstrated dedication would not want us to do otherwise. On Oct 26, 2012, at 1:16 PM, John C Klensin wrote: --On Friday, October 26, 2012 12:25 -0400 Michael StJohns mstjo...@comcast.net wrote: ... I'm pretty much going to object to any condition based model that anyone proposes, because we're really bad at a) figuring out the complete list of all possible conditions that could ever happen, b) writing conditions that can be objectively evaluated, and c) figuring out how to decide when specific conditions are met (because of the lack of objective criteria). In addition, people have been carping on the mailing list about how we need to be flexible - and condition lists by their very nature are not flexible. Mike, Oddly, while I disagree with your conclusion, I agree with the above. The difference is that I don't expect an if X, then you resigned condition-based model to work very well in the edge cases and where someone was trying to game the system. It can't work well for the edge cases for all the reasons you list, especially because we are lousy at anticipating all possible cases and writing rules to match. More specifically, I'm ok with a procedure that works well when someone just disappears and stops performing -- a problem that I think has arisen around three times in the last 20 years. I'm also ok with the fact that such a procedure probably would not have worked for one of them and that it would fail any time an incumbent chose to fight expulsion, whether by stunts like one out of every 3 meetings for exactly 5 minutes or by nit-picking the rules. My only interest is to help these who, for one reason or other, have already slunk away into the night or otherwise disappeared make a graceful and efficient exit.That is an entirely different case from someone who is not performing but who actively wants to hold onto the job. For the latter cases --if someone is intentionally gaming the system or resisting expulsion or resignation in other ways-- I think the recall procedure, and all of the public unpleasantness and condemnation that go with it, is exactly right and that nothing new is needed (although see below). It doesn't let a body determine its own membership (if we don't want IESG or IAB members, even retiring ones, voting on the Nomcom because we are afraid of self-perpetuating bodies, we certainly shouldn't let them second-guess Nomcom decisions by ejecting members without any review external to the I* leadership). If someone is non-performing and being a jerk about it (and maybe just consistently being a jerk), I think it would be reasonable to let a supermajority of the relevant body initiate (and fast track the beginning of) a recall, but I note that the community has rejected less drastic ideas in the past. best, john
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Keeping I-D's around forever is incredibly important form a historical, technical, and legal perspective. They people understand how we work, think, and develop protocols (history). They help people what was tried and did or did not succeed (technology). And they provide a record of the state of the art at a particular point in time (legal). -- Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See http://www.standardstrack.com/ietf/lemonade/ On Sep 8, 2012, at 4:14 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Joe, On 08/09/2012 04:58, Joe Touch wrote: On Sep 7, 2012, at 7:36 PM, Barry Leiba barryle...@computer.org wrote: ... And I think those are very different things. The fact that expired drafts used to not be available for public viewing on the IETF site does not, by itself, mean that that was or is the intent of expiration. That is exact what it meant. Or are you claiming that it was a coincidence that this entire time that derafts were removed in sync with that expiry? It may be what some people thought it meant, or wished it meant. And yes, it was intentional that you wouldn't find them in the *active* drafts directory after expiry. The factual reality is that I-D's have always been more or less perpetual, given that anonymous FTP has existed longer than any I-D. Admittedly the record is spotty for drafts earlier that about 1995, when HTTP became a major factor (but I suspect you could find them with gopher etc before HTTP). The difference today is that we are sort-of admitting officially that obsolete drafts can be found, and that this is useful. The word expired is perhaps not ideal; obsolete or out of date would perhaps be more precise, but it's probably too late to change it now. Brian
Re: [iucg] Last Call: Modern Global Standards Paradigm
+1. The ITU is not evil. It just is not the right place for Internet standards development. As John points out, there are potential uses of the ITU-T for good. On Aug 13, 2012, at 10:50 AM, John C Klensin wrote: --On Monday, August 13, 2012 11:11 +0200 Alessandro Vesely ves...@tana.it wrote: ... FWIW, I'd like to recall that several governments endorse IETF protocols by establishing Internet based procedures for official communications with the relevant PA, possibly giving them legal standing. Francesco Gennai presented a brief review of such procedures[*] at the APPSAWG meeting in Paris. At the time, John Klensin suggested that, while a more in-depth review of existing practices would be appreciated, the ITU is a more suitable body for the standardization of a unified, compatible protocol for certified email, because of those governmental involvements. [*] http://www.ietf.org/proceedings/83/slides/slides-83-appsawg-1.pdf Alessandro, Please be a little careful about context, as your sequence of comments above could easily be misleading. For the very specific case of email certified by third parties, especially where there is a requirement for worldwide recognition (the topic of the talk and slides you cited), the biggest problem has, historically, been an administrative and policy one, not a technical standards issue. We know how to digitally sign email in several different ways -- there is actually no shortage of standards. While additional standards are certainly possible, more options in the absence of compelling need almost always reduces practical interoperability. Perhaps the key question in the certified mail matter is who does the certifying and why anyone else should pay attention. The thing that makes that question complicated was famously described by Jeff Schiller (I believe while he was still IETF Security AD) when he suggested that someone would need to be insane to issue general-purpose certificates that actually certified identity unless they were an entity able to invoke sovereign immunity, i.e., a government. For certified email (or certified postal mail), your ability to rely on the certification in, e.g., legal matters ultimately depends on your government being willing to say something to you like if you rely on this in the following ways, we will protect you from bad consequences if it wasn't reliable or accurate. If you want the same relationship with foreign mail, you still have to rely on your government's assertions since a foreign government can't do a thing for you if you get into trouble. That, in turn, requires treaties or some sort of bilateral agreements between the governments (for postal mail, some of that is built into the postal treaties). International organizations, particularly UN-based ones, can serve an important role in arranging such agreements and possibly even in being the repository organization for the treaties. In the particular case of certified email, the ITU could reasonably play that role (although it seems to me that a very strong case could be made for having the UPU do it instead by building on existing foundations). But that has nothing to do with the development of technical protocol standards. Historical experience with development of technical standards by governmental/legislative bodies that then try to mandate their use has been almost universally poor and has often included ludicrous results. A similar example arises with the spam problem. There are many technical approaches to protecting the end user from spam (especially malicious spam) and for facilitating the efforts of mail delivery service providers and devices to apply those protective mechanisms. Some of them justify technical standards that should be worked out in open forums that make their decisions on open and technical bases. But, if one wants to prevent spam from imposing costs on intended recipients or third parties, that becomes largely a law-making and law enforcement problem, not a technical one. If countries decide that they want to prevent spam from being sent, or to punish the senders, a certain amount of international cooperation (bilateral or multilaterial) is obviously going to be necessary. As with the UPU and email certification, there might be better agencies or forums for discussion than the ITU or there might not. But it isn't a technical protocol problem that the IETF is going to be able to solve or should even try to address, at least without a clear and actionable problem statement from those bodies. I do believe that the ITU can, and should, serve a useful role in the modern world. The discussion above (and some of the work of the Development and Radio Sectors) are good illustrations. But those cases have, as far as I can tell, nothing to do with the proposed statement, which is about the development and deployment of technical
Re: Last Call: Modern Global Standards Paradigm
PLEASE, PLEASE, PLEASE read what the proposal is. The proposal being put forth is not that the ITU-T wants to write Internet standards. The proposal being put forth is that ONLY ITU-T standards will be the *legal* standards accepted by signatory nations. At best, this would be a repeat of GOSIP in the U.S., where the law was the U.S. government could only buy OSI products. The issue there was the private sector was still free to buy what it wanted and DoD did not really follow the rules and bought TCP/IP instead. TCP/IP in the market killed OSI. The difference here is some countries may take their ITR obligations literally and ban products that use non-ITU protocols. Could one go to jail for using TCP/IP or HTTP? That has an admittedly small, but not insignificant possibility of happening. Worse yet, having treaties that obligates countries to ban non-ITU protocols does virtually guarantee a balkanization of the Internet into open and free networking and controlled and censored networking. Just as it is not fair to say that if the ITU-T gets its way the world will end, it is also not fair to say there is no risk to allowing the ITU-T to get a privileged, NON-VOLUNTARY, position in the communications world. On Aug 10, 2012, at 9:49 AM, Phillip Hallam-Baker wrote: I think the point needs to be made that standards organizations can only advise and not dictate. There is really no risk that ITU-T is going to end up in control of the technical standards that are implemented by the likes of Microsoft, Cisco or Google, let alone Apache, Mozilla and the folk on SourceForge and Github. The key defect in the ITU-T view of the world is that it is populated by people who think that they are making decisions that matter. In practice deciding telephone system standards right now is about as important as the next revision of the FORTRAN standard, it is not completely irrelevant but matters a lot more to the people in the meetings than anyone else. The strength of the IETF negotiating position comes from the fact that we cannot dictate terms to anyone. The consensus that matters is not just consensus among the people developing the specification document but consensus among the people who are expected to act on it. ITU-T can certainly set themselves up a Friendship Games if they like [1]. But they can't force people to show up, let alone implement their 'requirements'. From a censorship busting point of view, the best thing that can happen for us is for the states attempting to gain control of the net in their country to attempt to standardize their approach. Much easier to circumvent fixed blocks than the current moving target. [1] http://en.wikipedia.org/wiki/Friendship_Games On Fri, Aug 10, 2012 at 11:19 AM, IETF Chair ch...@ietf.org wrote: The IETF Chair and the IAB Chair intend to sign the Affirmation of the Modern Global Standards Paradigm, which can be found here: http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-15.pdf An earlier version was discussed in plenary, and the IAB Chair called for comments on the IETF mail list. This version includes changes that address those comments. Th IETF 84 Administrative plenary minutes have been posted, so that discussion can be reviewed if desired. The minutes are here: http://www.ietf.org/proceedings/84/minutes/minutes-84-iesg-opsplenary On 8 August 2012, the IEEE Standards Association Board of Governors approved this version of the document. The approval process is underway at the W3C as well. The IETF Chair and the IAB Chair intend to sign the Affirmation in the next few weeks. Please send strong objections to the i...@iab.org and the ietf@ietf.org mailing lists by 2012-08-24. Thank you, Russ Housley IETF Chair -- Website: http://hallambaker.com/ smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
We seem to be doing a lot of talking about the draft. On Jul 30, 2012, at 9:33 AM, Scott O Bradner wrote: 2804 does not say not to talk about such things - or that such documents should not be published as RFCs - 2804 says that the IETF will not do standards work in this area Scott On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote: Under the long-standing IETF policy defined in RFC 2804, I trust we will not be discussing this draft, or draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF. Regards Brian Carpenter On 30/07/2012 09:26, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Label-based Provider-Provisioned Lawful Intercept for L3 VPNs Author(s) : Shankar Raman Balaji Venkat Venkataswami Gaurav Raina Vasan Srini Bhargav Bhikkaji Filename: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt Pages : 12 Date: 2012-07-30 Abstract: In models of Single-AS and inter-provider Multi- Protocol Label Switching (MPLS) based Virtual Private Networks (VPNs) Lawful Intercept is a key requirement. For example, MPLS-based Layer 3 VPN models like VPLS and the like do not have any provider provisioned methods of lawful intercept that are comprehensive, quick and easy to provision from one single point. More particularly the auto- provisioning of lawful intercept for all sets of streams travelling between VPN sites and consequent re-direction of these streams to the appropriate government network has not been covered without multiple instances of having to configure the intercept at various points in the network both in the Single-AS case and the Inter-Provider VPN case. this paper, we propose a technique which uses a set of pre-defined labels called Lawful Intercept labels and a method for provisioning lawful intercept amongst the various PE devices using these labels both in the Single-AS and the inter-provider VPN cases. A single point of configuration is the key to this idea. The intercepted traffic is mirrored on a PE or a whole set of PEs or on all the PEs participating in the VPN. A technique called the Domino-effect provisioning of these Label-based Provider Provisioned Lawful Intercept mechanism is also outlined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis There's also a htmlized version available at: http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Re: Future Handling of Blue Sheets
Do we have guidelines as to what is an organization affiliation? On Jun 14, 2012, at 5:26 PM, IETF Chair wrote: Two things have occurred since the message below as sent to the IETF mail list. First, we got a lawyer in Europe to do some investigation, and the inclusion of the email address on the blue sheet will lead to trouble with the European privacy laws. Second, Ted Hardie suggested that we could require a password to access the scanned blue sheet. Based on the European privacy law information, the use of email will result in a major burden. If the email address is used, then we must provide a way for people to ask for their email address to be remove at any time in the future, even if we got prior approval to include it. Therefore, I suggest that we collect organization affiliation to discriminate between multiple people with the same name instead of email address. Based on Ted's suggestion, I checked with the Secretariat about using a datatracker login to download the scanned blue sheet. This is fairly easy to do, once the community tracking tools are deployed. However, with the removal of the email addresses from the blue sheets, it is unclear that there is any further need for password protection of these images. Therefore, I suggest that we proceed without password protection for the blue sheet images. Here is a summary of the suggested way forward: - Stop collecting email addresses on blue sheets; - Collect organization affiliation to discriminate between multiple people with the same name; - Scan the blue sheets and include the images in the proceedings for the WG session; - Add indication to top of the blue sheet so people know it will be part of the proceedings; and - Discard paper blue sheets after scanning. Russ On May 6, 2012, at 12:46 PM, IETF Chair wrote: We have heard from many community participants, and consensus is quite rough on this topic. The IESG discussed this thread and reached two conclusions: (1) Rough consensus: an open and transparent standards process is more important to the IETF than privacy of blue sheet information. (2) Rough consensus: inclusion of email addresses is a good way to distinguish participants with the same or similar names. Based on these conclusions, the plan is to handle blue sheets as follows: - Continue to collect email addresses on blue sheets; - Scan the blue sheet and include the image in the proceedings for the WG session; - Add indication to top of the blue sheet so people know it will be part of the proceedings; and - Discard paper blue sheets after scanning. On behalf of the IESG, Russ
Re: Making the Tao a web page
What we have now *is* sclerotic. See Russ' email above yours. Can we PLEASE eat our own dog food? Wikipedia managed not to melt down when they decided NOT TO BUILD WALLS so there were no gates for the barbarians to crush. Let's just turn on a wiki. Wiki's have a lot of technical measures to deal with problem edits as well as social measures to ensure quality. Unlike a protocol that needs one editor, I do not think we will run into interoperability problems by having an open Wiki. Yes, you and I and others can think of exactly four individuals who will try to crash the party. There are technical measures to keep them out without burdening one or even four people with keeping up the wiki. On Jun 1, 2012, at 5:33 PM, Russ Housley wrote: I have a concern here. When I did the AD review for this document, I was quite surprised how stale it had become. For example, the document told people to send I-Ds to the Secretariat for posting instead of pointing to the online I-D submission tool. If we put it in a wiki, there will be more people that can make update, but the publication process ensure that an end-to-end read takes place when an update published as an RFC. So, I am left with a few questions: - What is the similar forcing function if we use a wiki? - Will the number of people that can make updates eliminate the need for such a forcing function? - Who designates the editor-in-chief of the wiki? Russ On May 31, 2012, at 7:50 PM, Paul Hoffman wrote: On May 31, 2012, at 4:30 PM, Nick Hilliard wrote: On 01/06/2012 00:04, Paul Hoffman wrote: Works for me, other than it should not be a wiki. It should have one editor who takes proposed changes from the community the same way we do it now. Not all suggestions from this community, even from individuals in the leadership, are ones that should appear in such a document. In practice, if this is to be a living document then it should be open for inspection and poking rather than preserved in formaldehyde and put in a display case, only to be opened occasionally when the curator decides the glass needs some dusting. That way leads to sclerosis. Thank you for that most colorful analogy. :-) What I proposed is exactly what we are doing now, except that the changes would appear on the web page instead of an Internet-Draft and, five years later, an RFC. Are you saying that the current system (which you have not commented on until now) is sclerotic (a word that I have wanted to use since I learned it in high school)? Please put it on a wiki and put all changes through a lightweight review system. If someone makes a change which doesn't work, then it can be reverted quickly and easily. This approach is much more in line with the ietf approach of informality / asking for forgiveness rather than permission / rough consensus + running code / etc. In the IETF approach, only the authors of an Internet-Draft can change the contents of that draft. I hope you are not proposing a change to that as well. --Paul Hoffman
Re: Gender diversity in engineering
NSF has a ton of information on this for the U.S. population. I'm too lazy right now to dig it up, but it is there. On May 1, 2012, at 4:40 PM, James M. Polk wrote: There have been some good numbers floated on recent threads, but at least for me, they aren't enough to gain a complete (or nearly complete) picture of the issue. Having studied statistics, we need to know a starting point, and look for the reductions (or increases) from that point forward. Starting in high school is not sufficiently refined enough, as there are a lot that take advanced math (personally I'd start with trig - because that kicked my ass - but rarely is it its own class, so let's start with calculus 1) that don't go into engineering. Thus, high school is probably not a good place to measure from. Therefore, it needs to be college. We need to know % of class (based on year started) that is female in engineering (do we want to start with electrical and CS to be more applicable to our situation?) We'll call that percent 'X' then %X of drops from engineering (BS) (or just elec/CS?) over the college years before graduation? then %X that enter workforce after BS in Engineering (or just elec/CS?) into the engineering field? then %X that start graduate school (MS) in engineering (or just elec/CS)? %X that receive MS degree in engineering (or just elec/CS)? %X that enter workforce after MS in Engineering (or just elec/CS?) into the engineering field? then %X that start doctoral school (PhD.) in engineering (or just elec/CS)? %X that achieve PhD. in engineering (or just elec/CS)? then %X that enter workforce after PhD in Engineering (or just elec/CS?) into the engineering field? This will likely track those that are entering the engineering workforce, and with what level of education. From that point in the analysis - we can attempt to track at what point there are further drops out of the engineering workforce by women (i.e., after how many years). Or is it as simple as problems after childbirth to reenter the workforce (for whatever reason). As an example, if there is a significant difference from those that drop out after their BS from those that drop out MS, then maybe something should be done to encourage women to stay for the MS. comments or questions? James
Re: Future Handling of Blue Sheets
I would strongly support what Wes is talking about here. I see two (other) reasons for keeping blue sheets. The first is it is a recognized method of showing we have an open standards process. The second is to support those who are trying to defend themselves in patent suits. Frankly, I hope the IETF makes it hard for those who want to abuse the IETF process to get patents or ignore prior art and then come after the industry for undeserved royalties. For the former purpose, just having a list is sufficient. However, for the latter purpose, one needs records that would be admissible in court. Without eating our dog food and having some sort of audited digital signature technology, a simple scan will not do. On Apr 23, 2012, at 10:04 AM, George, Wes wrote: From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of IETF Chair Sent: Sunday, April 22, 2012 10:31 AM To: IETF Subject: Future Handling of Blue Sheets 2. Scan the blue sheet and include the image in the proceedings for the WG session; and 3. Discard paper blue sheets after scanning. [WEG] Based on some other messages in this thread, there seems to be a lack of clarity as to the full, official purpose of the blue sheets. Are they simply to track generic participation levels for room sizing, or are they also meant as a historical record of attendees to a given WG? It seems that if they are being subpoenaed, and they are archived today, I tend to think that they're meant to officially track attendees. I'd appreciate someone correcting me if I'm wrong. If blue sheets are meant to be an official record, then technically we should document handling/scanning/storage procedures for WG chairs and the secretariat such that this scan will be admissible in lieu of a paper copy for any subpoena or other court proceeding. But if we're honest, I'm not sure that they're of much use as an official record either way. Do we have procedures today that would prevent tampering before the paper copy ends up in an archive box? And even then, blue sheets and jabber logs (for remote participants) are still ultimately a best-effort honor system, and therefore there is no guarantee of their validity. I can remotely participate without registering for the meeting, and can sign into Jabber as Mickey Mouse just as easily as I can sign the blue sheet that way. I can also sign as Randy Bush or sign my own name completely illegibly. Could we simply do a headcount for room sizing, and treat the matter of official attendee record for WG meetings as a separate problem? IMO, it's not currently solved by the blue sheets, and I don't see that changing just because we dispense with the paper copies in a box in a warehouse. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: Proposed IESG Statement on the Conclusion of Experiments
I have to admit to laughing out loud when I saw the IESG's announcement. Why? What is more important: cycling out Experimental RFC's or promoting Proposed Standards to Internet Standards? Do I hear chirping in the audience? If we need to focus spare cycles anywhere, I would offer progressing documents would be much more valuable than writing an Informational RFC that no one will read saying that an Experimental RFC that no one is reading should not be read. On Apr 20, 2012, at 9:19 AM, Brian E Carpenter wrote: On 2012-04-19 23:27, Ronald Bonica wrote: ... I think that this is a case-by-case judgment call. In some cases (e.g., RFC 1475), the experiment is clearly over. IMO, allowing RFC 1475 to retain EXPERIMENTAL status detracts from the credibility of current experiments that share the label. I agree that it is case by case, so I don't really see the value in the IESG statement. If it's appropriate to write an experiment-terminating RFC, do so; if it's inappropriate, don't bother. That doesn't need any new legislation. Brian
Re: IETF.Fact.Check IETF Participants that were also at ICANN Costa Rica Meeting ?
I was about to say we are at a point for an RFC 4633 action. Thanks. On Mar 29, 2012, at 2:26 PM, JORDI PALET MARTINEZ wrote: Hi Jim, This is my last message to you as IETF Sergeant-at-arms. I've asked the Secretariat avoid your posts going thru the email exploder. Regards, Jordi -Mensaje original- De: Jim Fleming ietf.fact.ch...@gmail.com Responder a: ietf.fact.ch...@gmail.com Fecha: Thu, 29 Mar 2012 07:09:50 -0500 Para: ietf ietf@ietf.org Asunto: IETF.Fact.Check IETF Participants that were also at ICANN Costa Rica Meeting ? IETF.Fact.Check IETF Participants that were also at ICANN Costa Rica Meeting ? https://www.ietf.org/registration/ietf83/attendance.py http://www.registration123.com/ICANN/CR43/ Registration list as of: 03/29/2012 NAME AFFILIATION COUNTRY AARON STEWARTCLOUD VINE United States Aarón Quesada Méndez Ice Costa Rica Abdoul-Akim Adjibola Benin Telecoms BENIN Abel Brenes University of Cosra RicaCosta Rica ABELARDO FONSECA LA NACIÒN Costa Rica Abiodun Olawale Reboot Associates Ltd Abraham ArayaMMSoluciones Seguridad en Informatica Costa Rica Abraham Djekou AtciCote d''Ivoire Abraham RodriguezAgencia Datsun Nissan Costa Rica Acc Va Cac Ac Ac CR Adalberto López NIC Costa Rica Adam Eisner Tucows Inc. Adam Peake Glocom Japan Adaobi Okeke Nigerian Communications Commission Nigeria Adebiyi Oladipo Nigeria Internet Registration Association (NIRA) Nigeria Adebunmi Akinbo Young Internet Professionals (YiPS)/(NiRA) dotNG Nigeria Adela Elena Danciu Fellowship Romania Adrian Carballo South School On Internet Governance Argentina Adrian GarciaISOC Costa Rica Chapter Costa Rica Adrian Kinderis ARI Registry Services Australia Adrián Pérez CcssCosta Rica Adrián Quesada Rodríguez Costa Rica Adrián SolanoAcoprot Costa Rica ADRIANA DIAZ ICANN Costa Rica Adriana González Sulá Batsú Costa Rica Adriana Rivero Lacnic Uruguay Adriana UlateCOSTA RICA AGARWAL SWAPNA .INDIA India Ague Alain Ministry of agriculture Bénin Ahsan Fahmi Pakistan Aimee Deziel Mad Akewushola Adisa Sanbak Communications CommissionNigeria Akinori Maemura JPNIC Japan Alain Artero European Broadcasting Union France Alain Berranger Centre d'étude et de coopération internationale Canada Alain Bidron France Telecom/ETNO France Alain Patrick Aina AFRIMIC Bénin Alan Barrett AfriNIC / ASO-ACSouth Africa Alan Fernández Marín Universidad de Costa Rica Costa Rica Alan Fernández Marín Universidad de Costa Rica Costa Rica Alan Greenberg Alac/gnso Canada Alan Gutierrez Att Bolivia Alberto GomezRed.es España Alberto Medrano Cáceres Universidad NacionalCosta Rica Alejandra Castro Arias Muñoz Costa Rica Alejandra Fernández Bonilla TV Channel 15, University of Costa Rica Costa Rica Alejandra ReynosoFellowship Guatemala Alejandro Berrocal Valverde Viceministrerio Telecomunicaciones MINAET Costa Rica Alejandro Cruz Ministro de CIencia y TecnologiaCosta Rica Alejandro Esquivel Rodriguez Cisco Systems Costa Rica Alejandro Guzman ASO AC - LACNIC - GoogleColombia Alejandro JimenezIce Costa Rica Alejandro LizNic Do Dominican Republic Alejandro Moscol Fellow PERÚ Alejandro PisantyISOC Mexico Mexico Alejandro Portilla Navarro Radio Universidad de Costa Rica Costa Rica Alejandro Rivera ICE Costa Rica Alejandro Solis Unimer Costa Rica Alex Blowers Nominet United Kingdom Alex Mwangangi Municipal Council Of Mavoko KENYA Alex Siffrin Key-Systems GmbH Alex Stamos iSEC Partners United States Alexa Raad Architelos United States Alexander AlíCosta Rica Alexander Flores Universidad de Costa Rica Costa Rica Alexander Mora CAMTIC Costa Rica Alexander Mora Universidad de Costa Rica Costa Rica Alexander OtárolaOmd Costa Rica Alexander Panov Ru-Center Russia Alexander Rojas Coral Technologies Costa Rica Alexander Salas Arce Oficina Digital - CentroAmerica Hosting Costa Rica Alexander Schubert dotgay LLC USA Alexander Schwertner EPAG Domainservices GmbHGermany Alexander Seger Council of Europe France Alexis Coto Colegio AgropecuarioCosta Rica Alexis Sandoval Ice Costa Rica Alfredo Lopez Hernandez Enredo Colombia Alfredo Pinochet LatinTLD, Inc. Chile Ali Asghar Ministry of
Re: Issues relating to managing a mailing list...
I am responding to Russ' original message, because it is too hard to pick one of the 52 responses received so far. A quick count is something like 10 thinking this is a good idea with the remainder thinking this idea ranks somewhere between really bad and evil. Apps Area people who have thought deeply about the topic over the last 25 years are in near unanimous agreement this idea is on the evil end of the spectrum. While Apps Area folks do not have a monopoly on email ideas, I would offer we listen carefully. This idea brings out a whole host of very old (and solved!) issues: o What constitutes a message? (if you strip stuff, you will break signatures) o What is an attachment? (is it useless cruft like TNEF or is it S/MIME? What about the next part type?) o What about using 15-year-old solutions like HTTP on the composing side? o What about using 10-year-old solutions like IMAP 4? o ... If another vote in the Nay column is needed, here it is. Nay. -- - Eric On Mar 14, 2012, at 7:46 PM, Russ Housley wrote: Some suggestions have been made about the IETF mail lists. There is a way for mailman to strip attachments and put them in a place for downloading with a web browser. This would be a significant change to current practice, so the community needs to consider this potential policy change. What do you think? Russ The only bug in the soup is that it seemed to me that we might want to look into an alternative approach. We have asked people to post large documents somewhere and only send a pointer. Not everyone can do that, lots of people forget, and some people are just not willing to take the extra step. Plus, we cannot expect people to keep things posted on their own personal, or their company's, web-site indefinitely. If they don't keep it there, then the pointer in the archive will become stale, and information that should probably be there is lost. So we need a solution to the issue with really big email messages sometime. One solution might be to simpy strip attachments off, put them in the archive and replace them with a pointer. That shouldn't be that hard, since a lot of anti-virus software does something similar with suspect attachment types. Or we could - once again - ask people to post attachments and use a pointer in their mail, only provide them with a place to post them in the same general area as the mail archive. If there is already something like this in place, please let me know what it is and I will add a pointer to it in my too big rejection messages. The thing about threaded messages getting too big is a slightly different issue, brought about by the increasing use of HTML format email. I talked years ago about this with Scott Bradner because I really think that HTML format messages are useful and relatively easy to read when compared to plain old text. But using HTML leads to messages that are deceptively big. Possibly the right answer in that case is to bump the size limit up to maybe 100K. Even with HTML format, people will many likely realize that nobody is going to read past the 10th back message in any case (or if they do want to, they can look at the thread in the archive). But even that approach is not fool proof, and there are a lot of resourceful fools out there. Just trying to be creative, and help out... smime.p7s Description: S/MIME cryptographic signature
Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
Shall we also set up a formal committee to hear patent filing accusations, a jury of nomcom-eligible members to pass judgement on the claim, an appeals board for the party that feels the jury made the wrong decision, a process document for the IESG to hear the appeal from the appeals board, a process document for the IAB to hear the appeal from the IESG, a process document for the ISOC President to hear the appeal from the IAB, and a prayer to G-d if the ISOC President gets appealed? Would it not be easier if we just did public flogging? It is so much easier to do and so much more fun to watch. On Jan 26, 2012, at 6:21 PM, Adrian Farrel wrote: http://www.ietf.org/internet-drafts/draft-farrresnickel-ipr-sanctions-00.txt -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Pete Resnick Sent: 26 January 2012 23:12 To: IETF-Discussion list Subject: Forthcoming draft: draft-farrresnickel-ipr-sanctions Just a heads-up: Adrian Farrel and I started work on a draft to focus discussion on sanctions that could be applied to violators of the IETF's IPR policy. Because of incidents like the present one, we've each been asked by WG chairs and others what can be done in response to such violations. We've centered our draft around sanctions that are available under current IETF procedures, not introducing new ones. The draft should be available in the I-D repository soon. We think this could usefully become an RFC and we would welcome discussion. Thanks, pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
Actually (s), the IETF *does* get credit for rooms sold. We reconcile the attendee list with hotel guests. Go for it. On Jan 3, 2012, at 2:48 PM, Michael StJohns wrote: The pre-pay is pretty annoying. And the if you cancel too late, we'll take all your money *really* annoys me. So much so that I booked on-line, direct with the hotel at a higher rate for a nicer room, but still better than the rate for the alternate hotel. And no-prepay and cancel by 4pm the arrival day or pay one day's room. I hate doing it this way - the IETF doesn't get any credit for rooms sold. Mike At 01:57 PM 1/3/2012, Thomas Nadeau wrote: I agree. In addition to that the pre-pay situation can be a major PITA for expensing purposes. We should add normal booking procedures to the hotel requirements list as well. --Tom On Jan 3, 2012, at 11:52 AM, George, Wes wrote: Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com It's 2012, but the IETF and this hotel chain expects us to book reservations at the main conference hotel by (international) FAX or by *emailing* a form which includes a credit card number so that the hotel can hold the room and implement its relatively bizarre prepay/anti-cancellation policy. Would it be trolling to ask whether anyone verified that cmasson has support for PGP encrypted-email and a proper method of securely storing (and then destroying after use) the several hundred credit card numbers they are about to receive? What person or rate code should we ask for when booking our rooms over the phone? (hey if I'm going old school, I'm doing it all the way!) Though, given the above, I'm relatively worried that my credit card number will simply end up on an unprotected spreadsheet on a PC somewhere in their office even if I call to book. More practically, the hotel blocks at the primary hotel typically fill up quite fast once registration is opened, especially since the overflow hotel is actually more expensive than the primary. Does the hotel fax/call us back to tell us that they have no more rooms available for our requested dates, or is the block open-ended such that they will keep selling rooms in it until the cutoff regardless of the number? Evidently ability to book group rate rooms online is something that should be added to our list of hotel requirements. I'm stunned that it's not there already. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
I do not know why hotels will not put it into a contract; believe me we try. I call this the double-secret discount. It would be nice if the hotels gave us Most Favored Nation status, but since they do not, and no hotel has, this is the next best thing. On Jan 3, 2012, at 4:35 PM, Brian E Carpenter wrote: On 2012-01-04 10:03, John C Klensin wrote: --On Tuesday, January 03, 2012 15:54 -0500 Eric Burger ebur...@standardstrack.com wrote: Actually (s), the IETF *does* get credit for rooms sold. We reconcile the attendee list with hotel guests. Go for it. In a way, that is really too bad. If people find the cancellation or other) policies problematic enough to actually change their behavior (as distinct from whining), it would be good for the IAOC to get that message in a way that was clear and couldn't be avoided. If you don't incur a penalty for failure to fill a block and/or can't really tell paid a higher rate to get a better policy from reserved after the block was full or past the deadline, then there are few, if any, incentives for telling a hotel that these sort of policies won't do. There's a third case, paid a lower rate than the conference rate (usually due to a smart corporate travel agent). I've never understood why conferences don't get a corporate-equivalent rate. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Travel/Attendees list FAQ
+1,000,000 The argument that an RFC, retrieved from the web, is more accessible than a web page or wiki, retrieved from the web, does not reflect reality. The argument that if the questions do not change much from venue to venue needs to be an RFC, and not a web page or wiki, does not hold water. RFCs are supposed to NEVER change. That is why we still have RFC 1000, 2000, 3000 available. Do we really need 6 RFCs covering what makes a good host, because we keep thinking of new items or to fix old ones? The argument that we need an RFC or twelve to show potential hosts, instead of a how to host an IETF web page is beyond wrong. One thing that keeps coming up is the people who do the on-the-ground hosting of IETFs are not people who attend IETFs. They are the party planners, hotel coordinators, swag printers, etc. For them an RFC is entirely alien. I would be amazed if they (1) could find an RFC and (2) if they read beyond the 1.5 pages of IETF Trust boiler plate. Conversely, these people are totally used to going to a web page to pick up tips or requirements for hosting. In theory I could be swayed for making this data available as a managed web page, but in practice it will get done if it is a wiki. Instead of 16 messages on why we should or should not publish an RFC, which most would agree would be obsolete before it gets published, we could have had 12 entries in a wiki. With Wes' work as a seed, we would be done by now. On Dec 7, 2011, at 3:08 PM, Melinda Shore wrote: On 12/07/2011 10:51 AM, Ole Jacobsen wrote: But a template for the required information would indeed be useful. I guess I'm not seeing anything here that looks to me like requirements, or anything here that can't be satisfied with something totally open, like a wiki. This whole business of trying to formalize this strikes me as rather of a piece with non-Bar non-BOFs and ossification of IETF processes. I think it's great that Wes put together a proposal and I hope that it's seen as a starting point for a wiki or some such rather than as yet something else that needs an editor and needs an approval process and that isn't as lightweight and responsive as something like an attendees info sheet should be. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
+1 On Dec 1, 2011, at 1:44 PM, Christian Huitema wrote: Note that the suit does not complain about the 3GPP and ETSI rules. It alleges instead that the rules were not enforced, and that the leadership of these organization failed to prevent the alleged anti-competitive behavior of some companies. I believe that our current rules are fine. They were specifically designed to prevent the kind of collusion described in the complaint. Yes, these rules were defined many years ago, but the Sherman Antitrust Act is even older -- it dates from 1890. We have an open decision process, explicit rules for intellectual property, and a well-defined appeals process. If the plaintiffs in the 3GPP/IETF lawsuit had been dissatisfied with an IETF working group, they could have use the IETF appeal process to raise the issue to the IESG, and the dispute would probably have been resolved after an open discussion. Rather than trying to set up rules that cover all hypothetical developments, I would suggest a practical approach. In our process, disputes are materialized by an appeal. Specific legal advice on the handling of a specific appeal is much more practical than abstract rulemaking. -- Christian Huitema -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel jaeggli Sent: Thursday, December 01, 2011 8:56 AM To: Jorge Contreras Cc: Ted Hardie; IETF Chair; IETF; IESG Subject: Re: An Antitrust Policy for the IETF On 11/28/11 12:58 , Jorge Contreras wrote: On Mon, Nov 28, 2011 at 2:35 PM, GTW g...@gtwassociates.com mailto:g...@gtwassociates.com wrote: __ Ted, I like your approach of enquiring what problem we are striving to solve and I like Russ's concise answer that it is Recent suits against other SDOs that is the source of the concern Russ, what are some of the Recent suits against other SDOs It would be good to pin down the problem we are addressing There is FTC and N-data matter from 2008 http://www.gtwassociates.com/alerts/Ndata1.htm George -- one recent example is the pending antitrust suit by True Position against ETSI, 3GPP and several of their members (who also employ some IETF participants, I believe). Here is some relevant language from the Complaint: When or if that suit is concluded you may be able to divine whether the antitrust policy of either SDO was of any value. 100. By their failures to monitor and enforce the SSO Rules, and to respond to TruePosition's specific complaints concerning violations of the SSO Rules, 3GPP and ETSI have acquiesced in, are responsible for, and complicit in, the abuse of authority and anticompetitive conduct by Ericsson, Qualcomm, and Alcatel-Lucent. These failures have resulted in the issuance of a Release 9 standard tainted by these unfair processes, and for the delay until Release 11, at the earliest, of a 3GPP standard for UTDOA positioning technology. By these failures, 3GPP and ETSI have authorized and ratified the anticompetitive conduct of Ericsson, Qualcomm, and Alcatel-Lucent and have joined in and become parties to their combination and conspiracy. ___ 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 ___ 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: discouraged by .docx was Re: Plagued by PPTX again
Hacking text display applications when HTML was designed for it already and most RFC's natively generate HTML (xml2rfc), do we really have a problem to solve? On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote: On 2011-11-28 18:21, Ted Ts'o wrote: On Mon, Nov 28, 2011 at 06:12:42PM +0100, Julian Reschke wrote: What's important is that things that *should* work well on small displays, such a reflowing prose paragraphs, and re-pagination, do so. This is where text/plain fails big (and HTML does not). That's more of an attribute of the text reader than any thing else. I've had readers that reflow text just fine --- far better than PDF, at any rate. It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. Best regards, Julian ___ 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: An Antitrust Policy for the IETF
In a different venue it was suggested to me that the group (a university-based research consortium) NOT have a detailed anti-trust policy. The university's law firm felt that we would be covered so long as we up front reminded the participants that they were adults and needed to follow the appropriate anti-trust laws appropriate to their circumstance and jurisdiction. Saying so once when they joined was thought to be more than sufficient. The IETF does not have members, so we do not have the luxury of distinguishing between members and the unwashed masses. So, if the anti-trust policy is a one sentence line in the NOTE WELL telling folks to remember to be law abiding, then I am all for it. If the anti-trust policy is a statement that must be read before every meeting, call, and email exchange, and that the IETF is responsible for monitoring mail lists to ensure that no anti-competitive behavior is occurring, and that the IETF is taking active measures to halt anti-competitive behavior, like removing emails from archives, monitoring Jabber sessions and terminating participants in real time, etc., then I am against it. On Nov 28, 2011, at 2:27 PM, Ted Hardie wrote: On Mon, Nov 28, 2011 at 11:10 AM, IETF Chair ch...@ietf.org wrote: Sorry, can you expand on the threat model here? Are we developing one in order to defend against some specific worry about our not having one? Because it has become best practice in other SDOs? Because the insurance agent wishes to see something in particular? I hesitate to develop something that we have not needed in the past unless it is clear what benefit it gives us. In particular, if we develop one without some particular characteristic, do we lose the benefits of being where we are now? Recent suits against other SDOs is the source of the concern. The idea is t make it clear which topics are off limits at IETF meetings and on IETF mail lists. In this way, if such discussions take place, the good name of the IETF can be kept clean. Russ Hmm, I would characterize our previous policy as a quite public statement that no one is excluded from IETF discussion and decision making, along with with reminders that what we are deciding is the technical standard, not the resulting marketplace. What we can say beyond that without diving into national specifics is obscure to me. I agree with Dave that the first work product of an attorney should be a non-normative explanation to the community of how having such a policy helps and what it must say in order to get that benefit. (I have to say that my personal experience is that prophylactic measures against law suits tend to change the terms of the suits but not their existence. In this case, suing someone because they did not enforce the policy or the policy did not cover some specific jurisdiction's requirements perfectly, seems like the next step. Your mileage may vary.) regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
Naah. We should update the 72-character ASCII limit to 40-characters. Not only will that work for all of these mobile devices, it will work on a TRS-80, too. On Nov 27, 2011, at 3:20 AM, Yaakov Stein wrote: Dave I agree that we are thinking as content creators, and that is the problem. The requirement is not that we will be able to write a new document in 50 years in the same format. The requirement is that we should be able to read the documents written 50 years before. The problem about ASCII art is not simply the monospacing. The main problem is the line wrapping. I have tried many times to look at ASCII art on iPhones, iPods, and even small pads. Once you zoom down sufficiently to get the lines not to break, the characters are no longer readable. For a screen size of about 60 mm, 80 character lines means that the characters are only 0.75mm in width. Even assuming a short figure that could be viewed rotated (width 110 mm) each character width would be only slightly more than the 1 mm needed for viewing, and less than the 1.5 mm needed for actual reading. Put in another way, high-end cellphone screens presently have 640 pixel widths. For 80 character layouts, this translates to 8 pixels per character plus inter-character spacing, or about 6 pixel character widths. Even were they visible (and each pixel is less than 1/10 of a mm!) this would mean very low quality fonts - 5*7 was the lowest quality used by old dot-matrix printers. And modern software is not optimized for readability at that font resolution. So, if we expect people to be able to read our documents in 5 years, let alone 50, we need to stop using ASCII art. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave Aronson Sent: Sunday, November 27, 2011 00:10 To: IETF Discussion Subject: Re: discouraged by .docx was Re: Plagued by PPTX again On Sat, Nov 26, 2011 at 15:52, Yaakov Stein yaako...@rad.com wrote: ASCII is already unreadable on many popular devices Oh? For what reason? Sorry, I'm still using an incredibly stupid phone, so I may be behind the curve on such changes. As far as I've seen in my limited exposure, any difficulty is usually because it's often not linewrapped well (or at all), forcing a lot of horizontal scrolling, especially after being forced to be big enough to be legible on tiny screens not held right up to the face. That's rather inconvenient, but still a far cry from unreadable -- plus it's a problem with the reader program (being too featureless to rewrap the text), not anything inherent in the format. ASCII *artwork*, yes, that often gets ruined by the refusal of many programs to allow the user to display content in a monospaced font. But that's not because it's in plain ASCII; you could say the same thing of a Word or PDF document that incorporates ASCII art. I am referring to the fact that more and more people are reading documents on cell-phones and other small devices. According to analysts, this will be the most popular platform for reading material from the Internet within a few years. But among what audience? End-users at large, yes, I can certainly believe that. But techies, especially of sufficient caliber to even *want* to read the IETF's output, let alone participate in creating it? Very doubtful. I don't think we'll be giving up our laptops, never mind large monitors, any time soon. Phones and tablets are for content *consumption*. We are content *creators*, be it programs, documents, or whatever. That's an entirely different set of hardware requirements. When was the last time you saw a program or document or anything else of significant size, written using a phone, or even a tablet? -Dave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The death John McCarthy
By the time period Steve talks about I was out of diapers and able to toddle on my own. Fast forward a few years and I was exposed to LISP (the real one, not the IETF one) when I did my thesis at the MIT LCS and fell in love with it. To the point that I regularly argued with various cretins from Berkeley who felt that C, not LISP, was the language of the gods. It took a true grey beard to interject and say that assembly language was the language of the gods, because both LISP and C compiled into machine language, so if you could not write a program in assembly language, you could not write it at all. My rebuttal that we had lots of LISP machines hanging around didn't make much of an impact on the argument. Since the relative demise of LISP/Scheme and the ascension of the semicolon over the parenthesis, MIT has gotten its revenge, inflicting the angle bracket in the parenthesis' place through the global adoption of XML. Yes, I *have* seen XML language proposals that look deceptively identical to the lambda calculus... On Oct 31, 2011, at 5:59 PM, Steve Crocker wrote: I was at the MIT AI Lab 1967-68 and at ARPA/IPTO 1961-74 where I funded and reviewed the Stanford AI Lab. Later I based my PhD thesis on McCarthy's memo on situational fluents. I also designed but didn't implement Lisp for the Sigma 7. Later I ran research groups and insisted on Lisp as a requirement. Steve Sent from my iPhone On Oct 31, 2011, at 3:44 PM, todd glassey tglas...@earthlink.net wrote: On 10/28/2011 1:25 PM, Randy Bush wrote: First, as someone who chartered the working group, who has implemented Lisp (the programming language) at least four times, and who views Dr. McCarthy as a hero I disagree that name is problematic or disrespectful. And I almost take offense in the claim that this is a generational thing. And frankly, if there's disrespect to be found here, IMO it lies in using this sad event as a proxy to criticize some IETF work some people apparently don't like. So how many people here actually knew or worked with John... or what he was working on? its a relevant question because there seem to be a number of people speaking from authority... so how many of you were around in the 1960's and 1970's at AI (either MIT or SU)? I bring this up as t...@suai.edu... T/// aol ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] I-D Action: draft-barnes-healthy-food-04.txt
Any reason not to use attendees...@ietf.org? I do not regularly participate in the ietf-food list, but I am interested in the results. For example, I am not a vegetarian, but I like vegetarian food. Likewise, I am on a budget, so knowing where to buy good food outside the venue interests me. The idea being that while there is a core group for whom food is critically important, e.g., getting very ill from the wrong food, there is a larger audience that would be interested in the discussion, too. On Nov 1, 2011, at 9:31 AM, Mary Barnes wrote: I have a separate mailing list setup for the food discussion in general: ietf-f...@employees.org Mary. On Mon, Oct 31, 2011 at 7:02 PM, Marshall Eubanks marshall.euba...@gmail.com wrote: On Mon, Oct 31, 2011 at 6:34 PM, David Morris d...@xpasc.com wrote: On Mon, 31 Oct 2011, Marshall Eubanks wrote: Dear Mary; Which is the appropriate community mailing list for discussion of this draft ? IETF@ietf.org ? A more limited traffic alternative might be useful ... my wife is a Registered Dietician and might be willing to provide feedback and suggestions, but not if she has to wade through the wide variety of discussion on the ietf@ietf list. I suspect there may be other experts who'd feel the same. Ray, Russ - could we set up a mailing list for _general_ meeting related discussions ? (Or, maybe, such already exists.) I think that just diet may be too narrow a focus... Regards Marshall Dave Morris ___ 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: [IAOC] I-D Action: draft-barnes-healthy-food-04.txt
I'm sold. On Nov 1, 2011, at 11:30 AM, Bob Hinden wrote: An IETF food list sounds right to me. Bob On Nov 1, 2011, at 7:40 AM, Mary Barnes wrote: I think the document in general should be discussed on a separate mailing list as it's not meeting specific. And, previous attempts at discussing this topic on more general mailing lists have not been particularly positive. I would agree that sharing information on general information related to finding food at the meetings on the attendees mailing list might be a good idea. However, some of the details may be of no interest to the majority. For example, there is small (but growing) subset of the IETF population that needs to eat Gluten-Free. This tends to get into very detailed discussions (per my document) and these might seem totally trivial and unnecessary for folks that don't deal with this and while it might seem obvious to some folks what we can and cannot eat, it's not nearly as simple as it might appear. For example, asian food is always risky due to the use of soy sauce (which contains wheat). And, cross-contamination is a big issue, so the waitstaff is equally as important in ensuring we get safe food as having a cook that understands the concept. So, personally I would prefer to have those sorts of discussions on the ietf-food list as I'm sure most attendees have no interest whatsoever in a topic like this. Mary. On Tue, Nov 1, 2011 at 8:38 AM, Eric Burger eburge...@standardstrack.com wrote: Any reason not to use attendees...@ietf.org? I do not regularly participate in the ietf-food list, but I am interested in the results. For example, I am not a vegetarian, but I like vegetarian food. Likewise, I am on a budget, so knowing where to buy good food outside the venue interests me. The idea being that while there is a core group for whom food is critically important, e.g., getting very ill from the wrong food, there is a larger audience that would be interested in the discussion, too. On Nov 1, 2011, at 9:31 AM, Mary Barnes wrote: I have a separate mailing list setup for the food discussion in general: ietf-f...@employees.org Mary. On Mon, Oct 31, 2011 at 7:02 PM, Marshall Eubanks marshall.euba...@gmail.com wrote: On Mon, Oct 31, 2011 at 6:34 PM, David Morris d...@xpasc.com wrote: On Mon, 31 Oct 2011, Marshall Eubanks wrote: Dear Mary; Which is the appropriate community mailing list for discussion of this draft ? IETF@ietf.org ? A more limited traffic alternative might be useful ... my wife is a Registered Dietician and might be willing to provide feedback and suggestions, but not if she has to wade through the wide variety of discussion on the ietf@ietf list. I suspect there may be other experts who'd feel the same. Ray, Russ - could we set up a mailing list for _general_ meeting related discussions ? (Or, maybe, such already exists.) I think that just diet may be too narrow a focus... Regards Marshall Dave Morris ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] From Pandoc To RFC
Any reason not to go the Wiki route and just make sure it doesn't get corrupted? On Oct 29, 2011, at 8:23 PM, John C Klensin wrote: --On Saturday, October 29, 2011 14:51 -0400 Russ Housley hous...@vigilsec.com wrote: I just think we need a volunteer to take over maintenance of the existing page. That would be fine (and I noticed that Marshall volunteered, for which I'm grateful), but part of my hope was that we could institutionalize that page or something like it, e.g., make sure that someone was responsible for being sure that there was a volunteer. john ___ 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: Requirement to go to meetings
It gets worse. To attend every IETF meeting costs about $10,000 per year. If we say one has to go to the face-to-face meetings, we limit the IETF to participants from corporations or entities that will sponsor the individual (pay to play?), IETF participants that have independent funds, or people that can generate significantly more than $10,000 per year from their IETF activities. $10,000 per year is not within a typical individual's budget. This is more especially so if the individual comes from a region of the world where the per-capita GDP is below $10,000 per year. Where does the $10,000 figure come from? It is based on the following assumptions: One trip is far, so $2,000 for airfare One trip is near, so $400 for airfare One trip is in between, so $1,200 for airfare Hotel: 6 nights (Sunday - Friday) at $200 average per night (including tax). I know, Taipei is much more than that and Vancouver, including tax, will be exactly that. However, the numbers are nice and round at $200. I often cannot afford to stay at the conference hotel; use your own numbers for your own circumstances. Meals Misc Expenses: $50/day for 6 days So, the calculation is: 3x ($650 registration fee + $1,200 average airfare + $1,200 average hotel cost + $300 meals/other) = $10,050 It is critically important to note the cost is dominated by travel and hotel. The only parameter in IETF's control is the registration fee. Even if ISOC, sponsors, or someone else endowed the IETF so we could drop the registration fee to zero, the annual cost for travel is over $8,000, which is still rather expensive. I do not believe we consciously want to prohibit individuals from participating in the IETF. I do not believe we consciously want to prohibit individuals from outside North America, Europe, and select (wealthy) Asian countries. However, this is one logical result of mandating people go to the face-to-face to get work done. On Oct 23, 2011, at 6:26 AM, Dave CROCKER wrote: On 10/21/2011 7:58 PM, Melinda Shore wrote: It's increasingly the case that if you want to do work at the IETF, you need to go to meetings. I'd have considerable reservations about asking for the kind of money you're suggesting. Melinda, I've changed the subject line because the point you raise is orthogonal to the main thread, but since you raise it, it's worth exploring a bit (since I happen to agree with your observation.) The dynamics that make this true seem to have to do with changes in our community rather than in the nature of the technical work or the online tools. So the question is how to move the center of gravity back to mailing lists? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
For me, the plan outlined below changes the cost of the travel from: Long @ $2,000, Medium @ $1,200, and Short @ $400 = $3,600 to: Short @ $400, Short @ $400, Medium @ $1,200 = $2,000 HOWEVER, if I lived in Asia, the plan proposed below changes my costs from $3,600 to Long @ $2,000, Long @ $2,000, Medium @ $1,200 = $5,200 So, instead of someone in the U.S. paying $3,600, or about 7.5% the per-capita GDP, they can pay $2,000, or about 4% of per-capita GDP, for a reduction of travel costs of about 45%. Along with that dramatic savings, there is a corresponding shifting of the travel burden. Instead of someone in China paying $3,600, or about 84% of the per-capita GDP, they can pay $5,200, or about 122% of per-capita GDP, for an increase of almost 50%. Even better, that individual most likely will have trouble getting a visa. So, not only will we succeed in ensuring a drop-off in participation by unsponsored individuals, this would be a wonderful plan to reduce participation in the IETF by people outside of North America. [Last I looked, reducing participation was NOT a goal of the IETF.] On Oct 23, 2011, at 1:12 PM, Ping Pan wrote: In the past three IETF meetings, I have traveled to Beijing, Prague and Quebec City to meet most who live within a few hours (air, car, walking etc.) from me. The next two will be in Taipei (in Winter) and Paris (in Spring). This is more like a vacation package than a get-together for engineers to solve problems face-to-face. Several of us have chatted about this last week. How about this as a recommendation? We have two meetings in fixed locations each year: Minneapolis in winter, and Phoenix in summer. The other one can be somewhere in Europe or Asia. Both Minneapolis and Phoenix have huge conference facilities, are easy to go to, and can get cheap off-season discount. Most of all, it encourages the participants who want to do work going there. Make sense? Ping On Sun, Oct 23, 2011 at 7:50 AM, Eric Burger ebur...@standardstrack.com wrote: It gets worse. To attend every IETF meeting costs about $10,000 per year. If we say one has to go to the face-to-face meetings, we limit the IETF to participants from corporations or entities that will sponsor the individual (pay to play?), IETF participants that have independent funds, or people that can generate significantly more than $10,000 per year from their IETF activities. $10,000 per year is not within a typical individual's budget. This is more especially so if the individual comes from a region of the world where the per-capita GDP is below $10,000 per year. Where does the $10,000 figure come from? It is based on the following assumptions: One trip is far, so $2,000 for airfare One trip is near, so $400 for airfare One trip is in between, so $1,200 for airfare Hotel: 6 nights (Sunday - Friday) at $200 average per night (including tax). I know, Taipei is much more than that and Vancouver, including tax, will be exactly that. However, the numbers are nice and round at $200. I often cannot afford to stay at the conference hotel; use your own numbers for your own circumstances. Meals Misc Expenses: $50/day for 6 days So, the calculation is: 3x ($650 registration fee + $1,200 average airfare + $1,200 average hotel cost + $300 meals/other) = $10,050 It is critically important to note the cost is dominated by travel and hotel. The only parameter in IETF's control is the registration fee. Even if ISOC, sponsors, or someone else endowed the IETF so we could drop the registration fee to zero, the annual cost for travel is over $8,000, which is still rather expensive. I do not believe we consciously want to prohibit individuals from participating in the IETF. I do not believe we consciously want to prohibit individuals from outside North America, Europe, and select (wealthy) Asian countries. However, this is one logical result of mandating people go to the face-to-face to get work done. On Oct 23, 2011, at 6:26 AM, Dave CROCKER wrote: On 10/21/2011 7:58 PM, Melinda Shore wrote: It's increasingly the case that if you want to do work at the IETF, you need to go to meetings. I'd have considerable reservations about asking for the kind of money you're suggesting. Melinda, I've changed the subject line because the point you raise is orthogonal to the main thread, but since you raise it, it's worth exploring a bit (since I happen to agree with your observation.) The dynamics that make this true seem to have to do with changes in our community rather than in the nature of the technical work or the online tools. So the question is how to move the center of gravity back to mailing lists? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org
Re: Anotherj RFP without IETF community input
+1 On Oct 21, 2011, at 6:58 PM, Melinda Shore wrote: On 10/20/2011 12:02 PM, Acee Lindem wrote: I disagree. If the remote participation service is high quality, it should require the same registration fee structure as on-site participation. It seems to me that any fees (and I've got some issues with that: see below) should be tied to the expense of providing the service. But aside from that it seems to me that there's historically been an interest in keeping IETF processes open. I don't think we want to get into a situation in which only people whose participation costs are covered by an employer or someone's got enough money to fund themselves. I don't think that this would be particularly an issue if meetings haven't increasingly become the place where decisions are made (sorry, it does happen far too often) and centers of working group activity. It's increasingly the case that if you want to do work at the IETF, you need to go to meetings. I'd have considerable reservations about asking for the kind of money you're suggesting. But first, let's find out what it actually would actually cost the IETF. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Anotherj RFP without IETF community input
Simon - Careful what you promse. I am sure someone will try to use the service through two satelite hops and then complain about the latency. Unfortunately, we cannot (yet) get of this speed of light thing :-) On Oct 21, 2011, at 2:54 PM, Simon Pietro Romano wrote: Dear sm, just for the sake of completeness, I have to say that the following statement is not 100% correct: The RFP mentions bidirectional audio and video. As John has attempted to chair a working group remotely, he might be aware that real-time can mean more than 10 seconds between the time an event occurs and when it is registered at the remote end. I am quite confident that none of the tools you mention entails such a long delay. You are probably talking about the mp3 audio feed, which, as far as I know, has never been meant to represent a real-time, bidirectional means of interaction (and which, btw, proves really helpful when you want to access high-quality recordings after the meeting). I can state for sure that we have used Meetecho for remote presentations in Hiroshima, in the mediactrl WG meeting: interaction happens in real-time. Cheers, Simon -- _\\|//_ ( O-O ) ~~o00~~(_)~~00o Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: sprom...@unina.it http://www.comics.unina.it/simonpietro.romano Molti mi dicono che lo scoraggiamento è l'alibi degli idioti. Ci rifletto un istante; e mi scoraggio. Magritte. oooO ~~( )~~ Oooo~ \ (( ) \_)) / (_/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Grey Beards (was [81all] Quick Meeting Survey)
My very own BCP! On Sep 22, 2011, at 4:05 AM, Ted Hardie wrote: On Wed, Sep 21, 2011 at 2:46 PM, Elwyn Davies elw...@googlemail.com wrote: Time for the facial hair standard and ensuring that there is a proper three stage progression from provisional salt and pepper to full blown white out. /Elwyn I think you missed Eric's proposal for a one-step Balding is Common Practice standard. Ted Eric Burger wrote: You all are just bragging you still have hair :-( On Sep 21, 2011, at 12:55 AM, Melinda Shore wrote: On 9/20/11 6:26 PM, Ronald Bonica wrote: This reminds me that it has been a while since we took the last IETF grey beard photo. A few more of us have gone grey since then. Maybe we should plan on another photo to be taken after the next Administrative Plenary. Beardless, but back when I started participating in the IETF my hair was nearly black. Now I've gone completely grey. Not trying to imply causality, of course. Count me in. Melinda ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Grey Beards (was [81all] Quick Meeting Survey)
You all are just bragging you still have hair :-( On Sep 21, 2011, at 12:55 AM, Melinda Shore wrote: On 9/20/11 6:26 PM, Ronald Bonica wrote: This reminds me that it has been a while since we took the last IETF grey beard photo. A few more of us have gone grey since then. Maybe we should plan on another photo to be taken after the next Administrative Plenary. Beardless, but back when I started participating in the IETF my hair was nearly black. Now I've gone completely grey. Not trying to imply causality, of course. Count me in. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Conclusion of the last call on draft-housley-two-maturity-levels
So should we move to a one-step process? On Sep 9, 2011, at 9:33 PM, Thomas Narten wrote: Advancing a spec is done for marketing, political, process and other reasons. E.g., to give a spec more legitimacy. Or to more clear replace an older one. Nothing wrong with that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Expiring a publication - especially standards track documents which are abandoned
Why? No one has cared about the annual review from 2026. No one has time to do the bookkeeping and spend the effort to evaluate stuck documents. If there is an RFC that is harmful, then one can always ask to have it moved to Historic. On Sep 4, 2011, at 10:23 AM, todd glassey wrote: There are any number of IETF RFC's which were published and then accepted in the community under the proviso 'that they would become IETF standards' which in many instances they do not. Further many of them are abandoned in an uncompleted mode as standards efforts. To that end I would like to propose the idea that any IETF RFC which is submitted to the Standards Track which has sat unchanged in a NON-STANDARD status for more than 3 years is struck down and removed formally from the Standards Track because of failure to perform on the continued commitment to evolve those standards. Why this is necessary is that the IETF has become a tool of companies which are trying to get specific IETF approval for their wares and protocols - whether they are open in form or not. The IETF entered into a contract with these people to establish their standard and published those documents on the standards track so that they would be completed. Since they have not been completed as IETF Standards the Project Managers for those submissions have formally breached their contract to complete that process with both their WG members who vetted those works as well as the rest of the IETF's relying parties. As such it is reasonable to put a BURN DATE on any Standards Track effort which has stalled or stopped dead in its tracks for years. Todd Glassey -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ___ 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: Discuss criteria for documents that advance on the standards track
Would having professional editors make a difference here? On Aug 31, 2011, at 2:31 AM, John C Klensin wrote: --On Tuesday, August 30, 2011 14:51 -0700 Fred Baker f...@cisco.com wrote: What's also not fair game is to raise the bar - to expect the document at DS to meet more stringent criteria than it was required to meet at the time of PS approval. Hmmm, the demonstrated interoperability requirement of DS/IS is in fact a raising of the bar,and one that has served us well. We don't (although IMHO we should) require even an implementation to go to PS. I know it is controversial, but there is at least one other area in which we should be raising the bar for DS/IS by dropping the bar for Proposed. If we really want to get PS specs out quickly while the percentage of people who easily write very high quality technical English in the IETF continues to go down, we need to stop the behavior of various IESG members simulating technical editors or translators to fix PS text (or insisting that the author or WG do so, which, IMO, is less bad but still often a problem). Doing that will get documents out faster, perhaps even a lot faster in some cases, but will inevitably result in PS documents that need significant editorial work before being approved at DS. I think that would actually be a good thing. I think that stuffing explicit placeholders to the effect of this needs to be rewritten to be completely clear to folks who haven't participated in the WG into PS documents would be a fine idea -- it would get those documents finished and out while making their preliminary nature very clear. But it implies a higher editorial quality standard --a higher bar-- for DS/IS than for PS. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
My interpretation of what you wrote is that in your mind there is absolutely no difference between a SHOULD and a MAY. They are both optional, and you implement whatever you have time to implement, with SHOULD's prioritized higher than MAY's. Even if that is not what you mean, it is what many implementors do. I would offer this highlights the problem with today's SHOULD. Some think SHOULD means something is OK to implement, but life does not end if you do not do it. Others think SHOULD means something HAS to be implemented, unless the environment indicates the protocol will not work in some corner case. On Aug 30, 2011, at 3:08 PM, hector wrote: When I approach a protocol to implement, the first thing I typically do is extract and develop the basic wiring of the protocol, the minimum requirements. Make sure the basic framework is correct 100%, then I look for the SHOULDs and also MAYS which are the easiest to add. I look at the SHOULD by order of importance and also complexity. How much CANDY is it? It is a security feature? What are the other implementation requirements, tools, APIs, etc. Generally I want to get security out the way. Its like SMTP AUTH - its not required but anyone cleaning up and rewriting an SMTP spec today, might include the AUTH extension as a SHOULD. And implementators are keen to the importance of it. But nothing won't break down if you don't, less functionality but the basic structure is still there. Its the same approach used for all the protocols we support. Start with the basics and then add on as necessary. Eric Burger wrote: What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Interesting example. I like it. I agree that when to retry is not at all a protocol issue. That probably is why we are in fuzzy land, and this highlights why SHOULD is bad. The availability of SHOULD drew the author of the mentioned RFC to mix a user interface / user experience issue with a protocol issue. Saying a client SHOULD retry immediately, to migrate subscriptions, is an implementation detail and has absolutely NOTHING to do with the protocol. It would be OK to have a NOTE in the protocol RFC discussing that deactivated is an opportunity to migrate the subscription. It would be OK to have an Informational implementor's guide that notes that it would be good for clients to leverage the deactivated state to quickly migrate a subscription. However, there is NOTHING in the protocol to say SHOULD. On Aug 30, 2011, at 3:15 PM, Adam Roach wrote: In this case, unless the implementation has a good reason, failing to re-subscribe will result in behavior that the user perceives as broken. I don't think that's really MAY territory. /a On 8/30/11 1:57 PM, Eric Burger wrote: What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
This highlights an interesting issue as an RFC goes from PS to IS. I would offer that most SHOULDs in a document will, if there are real implementations out there, migrate to MUST or MUST NOT. On Aug 31, 2011, at 9:57 AM, hector wrote: I think you are speaking of long term operations where an SHOULD is so widely adopted, it inherently because a MUST have in all new implementations. So that vain, sure, eventually the better options naturally become part of the protocol to the extent the options might be even remove to simplify things. We also have the opposite where a SHOULD is implemented but no one users it so eventually, it may be remove as an option. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
+1, too. This goes along with my strong desire to eliminate passive voice, unless the goal is to have the actor be obfuscated (as an example). On Aug 30, 2011, at 5:29 AM, Mykyta Yevstifeyev wrote: 2) I strongly believe that authors should be encouraged to enumerate the potential subjects of conformance terms, and to use them in every instance. For example, a requirement like this: The Foo header MUST contain the bar directive is ambiguous; it doesn't specify who has to do what. Rather, Senders MUST include the bar directive when producing the Foo header; recipients that receive a Foo header without a bar directive MUST ... is unambiguous (assuming that the spec defines the terms sender and recipient). +1. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: Dear Eric; I support adding the SHOULD ... UNLESS formalism (although maybe it should be MUST... UNLESS). It would be useful as there will be times where the UNLESS can be specified and has been given due consideration at the time of writing. That, however, will not always be the case. (More inline). [snip] But how about SHOULD do FOO UNLESS you have given serious consideration as to the consequences of not doing FOO. Isn't that really the original intention of SHOULD ? Do we gain anything if that is added every time it is used? Looking at this from a protocol perspective, SHOULD now equals MAY. There is no objective way of deciding when to do FOO or not. [snip] smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
I would offer that working groups that say to do something that may or may not hold in foreseen or unforeseen circumstances is most likely working on a protocol that is way too complex and is begging for interoperability problems. What ever happened to building simple, point-solution protocols that followed the hour-glass and end-to-end principles, and then building your complex protocols out of them? On Aug 29, 2011, at 11:11 PM, Keith Moore wrote: On Aug 29, 2011, at 10:44 PM, Eric Burger wrote: I would offer that ANY construction of SHOULD without an UNLESS is a MAY. The essential beauty of SHOULD is that it gets specification writers and working groups out of the all-too-common rathole of trying to anticipate and nail down every exceptional case. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
This sentiment mostly makes sense. If an endpoint expects SHOULD/MAY items implemented as MUSTs on the remote end, then one should slap the endpoint developer silly. Read the RFC! If it says SHOULD/MAY, then your implementation MUST be able to handle the feature present *and* absent. Note that every SHOULD/MAY in a specification introduces cyclomatic complexity. Every SHOULD/MAY results in at least one if statement, to test the presence or absence of the feature in the remote end. Protocols will be much simpler to implement. Moreover, given the results in the software engineering literature that indicate latent defects appear super-linearly with cyclomatic complexity, protocols without (or a minimum) of SHOULD/MAY features will have fewer defects in the field. Remember, we are working on Internet protocols, where a one-in-a-million corner case happens many times per day. On Aug 30, 2011, at 4:00 AM, HLS wrote: On 8/30/11, Murray S. Kucherawy m...@cloudmark.com wrote: Mark Nottingham: 1) I agree that the SHOULD... UNLESS pattern ought be documented. I had never thought of this before. I kind of like the idea, especially since SHOULD has always meant MUST unless you really know what you're doing Such an odd reading. Does it mean you MUST because you could not handle it otherwise? It takes two to tango. One side reasons can be different than the other. If a software breaks down because it read SHOULD as a MUST and expected the other end will also view is a MUST, then it didn't know what it was doing. Things break down. Implementors on either side can't depend on it and need to function in lieu of it. There is always the possibility one decided Na, not needed, not worth the cost. Its not required. etc, and no one should die because of that decision. I think it MUST be noted that a Minimum Implementation for a protocol is all anyone can expect. If a SHOULD item is among the listed minimum requirements, it MUST be removed from the list or changed to a MUST. Maybe the term Minimum Implementation (is part of, is not part of) can be incorporated into each of the key word text. -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Strictly speaking, you are correct, in that if one interprets SHOULD/MAY as 'not bother', one does not need to check, unless the presence of the remote end doing the feature results in your barfing. However, if one interprets SHOULD/MAY as 'bother', then one most likely needs to check on the capabilities of the far end or handle the varying data elements or protocol states that will or will not happen. On Aug 30, 2011, at 9:58 AM, Keith Moore wrote: On Aug 30, 2011, at 9:56 AM, Eric Burger wrote: Every SHOULD/MAY results in at least one if statement, to test the presence or absence of the feature in the remote end. false. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
I think you have hit the root cause on the head. I would also offer that by removing the crutch, or raising the bar to using the crutch, will help alleviate the root cause. On Aug 30, 2011, at 11:44 AM, Keith Moore wrote: e.g. For the specific case of optional features that must be negotiated, I don't think that SHOULD is the problem. Rather I think that optional features are too common. That's not to say that optional features and feature negotiation are never useful, particularly when extending a protocol that is already well-established in the field. But if making features optional is seen by WGs as a way to avoid making hard decisions about what is required to interoperate, that really is a problem. It just doesn't have anything to do with SHOULD. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security On Aug 30, 2011, at 12:11 PM, Keith Moore wrote: On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: The meaning of SHOULD is clear for the authors (it mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.), the problem is that some implementers use a different meaning (I do not have to implement this if it is inconvenient or difficult for me to implement), vendors another one (SHOULD gave us the right to not implement it). I even read somewhere, perhaps on this list, about a vendor that rejected any bug report against a SHOULD. Conditional MUST, in my opinion, does not have this problem. But conditional MUST has other problems, namely that you have to enumerate the exceptions for the MUST, and that's not always practical. Implementors who think that SHOULD gives them a free pass to avoid implementing something that's needed to interoperate are misreading 2119. But document editors should avoid using SHOULD for cases where failure to implement the requirement will result in interoperability failure. I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea. And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Note the language MUST implement, SHOULD use is a common compromise. ^^^ This is my heartache. Why is it a compromise? Most use of SHOULD I run into in WG's is either this precise one: I don't want to make this a MUST use, because I will have deployments *THAT ARE NOT FOR THE INTERNET* but I want to market them as if they were. Example: instant messaging systems for enterprises where tapping is a legal requirement, not something to be avoided. Example: instant messaging systems deployed where governments want to do warrantless, undetectable tapping I would offer neither of these examples are Internet examples, and we should get some iron underpants on and say so. Internet protocols need Internet protections. SHOULD should neither be a crutch for making a proprietary protocol look like an Internet protocol nor for making two proprietary protocols look like a single, Internet protocol. On Aug 30, 2011, at 1:50 PM, Keith Moore wrote: On Aug 30, 2011, at 12:46 PM, Eric Burger wrote: Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security That wording doesn't make any sense. Security implementation should almost always be a MUST, regardless of what any particular government might say. We shouldn't relax the security requirements of our protocols because of brain-damaged governments (and I include my own country's government in that list). In cases like this it's sometimes important to distinguish between implementation and use. MUST implement, SHOULD use is a common compromise. Note also that MUST doesn't mean you have to do this. It means if you don't do this, you don't comply with the specification. I don't think the example above is a typical use of SHOULD, though it might be too common. Keith smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
We violently agree. However, the most cited reason I get for watering down security requirements are what I mentioned below. On Aug 30, 2011, at 2:19 PM, Keith Moore wrote: On Aug 30, 2011, at 2:02 PM, Eric Burger wrote: Note the language MUST implement, SHOULD use is a common compromise. ^^^ This is my heartache. Why is it a compromise? Most use of SHOULD I run into in WG's is either this precise one: I don't want to make this a MUST use, because I will have deployments *THAT ARE NOT FOR THE INTERNET* but I want to market them as if they were. Example: instant messaging systems for enterprises where tapping is a legal requirement, not something to be avoided. Example: instant messaging systems deployed where governments want to do warrantless, undetectable tapping I would offer neither of these examples are Internet examples, and we should get some iron underpants on and say so. Mumble. I fundamentally don't buy the argument that things that are used on both local networks and the Internet should not be subject to Internet-strength security. And even where recording is a legal requirement, that's NOT an argument for sending traffic in cleartext or with weak encryption. That might be an argument for some kind of backdoor - e.g. a trusted proxy or key escrow or whatever, but it's not an argument for making the traffic available for those without a legal need to see it. SHOULD should neither be a crutch for making a proprietary protocol look like an Internet protocol nor for making two proprietary protocols look like a single, Internet protocol. agree. Keith smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
I would assume in the text of the document. This paragraph is simply an enumeration of Burger's Axiom: For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a MAY. On Aug 29, 2011, at 5:50 PM, Thomas Narten wrote: It would help me if you explained the diffs and the *reasons* for the proposed changes. E.g, the new text says: This term means that the feature or behavior is a limited requirement of the specification, so that an implementation has a conditional obligation to implement the feature or to behave as defined, unless there is a strong, explicitly described reason not to do so in particular circumstances. Those who implement the specification or deploy conformant technologies need to understand and carefully weigh the full implications of violating the requirement before doing so. The term RECOMMENDED is equivalent to SHOULD. The wording unless there is a strong explicitly described reason not to do so in particular circumstances is new wording and my first reaction is it's not helpful. I.e., explicitely described by who? Explicitely specified in the text? If so, that seems unworkable in practice. What problem is this bis document intended to fix? Thomas ___ 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: 2119bis
Please make my English language sensibilities and satisfy Burger's Second Law of standards documents at the same time, forbidding passive voice. Can we have the following as the boilerplate? Thanks. Either: In this document, [RFC] describes the following conformance terms: MUST, ... Or: [RFC] describes the following conformance terms used in this document: MUST, ... Also, from a typographic point of view, why are we quoting single worlds that are already in quotes? On Aug 29, 2011, at 5:36 PM, Peter Saint-Andre wrote: After staring at http://www.rfc-editor.org/errata_search.php?eid=499 for long enough, I finally decided to submit an I-D that is intended to obsolete RFC 2119. I hope that I've been able to update and clarify the text in a way that is respectful of the original. Feedback is welcome. http://www.ietf.org/id/draft-saintandre-2119bis-01.txt Peter -- Peter Saint-Andre https://stpeter.im/ ___ 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: 2119bis
Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Unless of course one considers us the Protocol Nanny's(tm) - if do not do a SHOULD, we will send you to bed without your treacle! I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY. On Aug 29, 2011, at 9:47 PM, ned+i...@mauve.mrochek.com wrote: Hi - From: Eric Burger eburge...@standardstrack.com To: Narten Thomas nar...@us.ibm.com; Saint-Andre Peter stpe...@stpeter.im Cc: IETF discussion list ietf@ietf.org Sent: Monday, August 29, 2011 3:08 PM Subject: Re: 2119bis I would assume in the text of the document. This paragraph is simply an enumeration of Burger's Axiom: For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a MAY. I disagree. I concur with your disagreement. SHOULD should *not* be used when the list of exceptions is known and practically enumerable. If the UNLESS cases can be fully enumerated, then SHOULD x UNLESS y is equivalent to WHEN NOT y MUST X. (Both beg the question of whether we would need to spell out that WHEN y MUST NOT X is not necessarily an appropriate inference.) RFC 2119 SHOULD is appropriate when the UNLESS cases are known (or suspected) to exist, but it is not practical to exhaustively identify them all. Let's not gild this lily. +1 Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
+100 On Aug 26, 2011, at 6:50 AM, Scott Schmit wrote: On Fri, Aug 26, 2011 at 09:18:41AM +0200, t.petch wrote: Why does the IETF website consider it necessary to use TLS to access the mailing list archives, when they all appeared without it, or any other security, in the first place? TLS provides more than confidentiality--it also provides authenticity. If I were living in a hostile regime, I'd appreciate knowing that the RFCs, etc that I'm getting really come from the IETF unmodified. Also, as a general principle, I'd rather someone not be able to read over my shoulder, even if it is harmless stuff. Using encryption only when I need it makes all of my encrypted traffic less secure. For example, if I were out to modify the traffic you read to make sure that you didn't even know that a working group existed, I'd have a lot easier time of it if you use DNS without DNSSEC, HTTP without TLS, TLS without HASTLS, DANE, HSTS, etc. Now, not all of that is completed protocol work, but one step at a time. Besides all the usual hassle of TLS, today the certificate is reported by IE as expired, which sort of sums it up. Mistakes happen. Hopefully lessons are learned so that they don't get repeated. If it's a protocol problem, whose fault is that but ours? -- Scott Schmit ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Routing at the Edges of the Internet
I disagree with the fundamental premise of this concept, that it is a PROBLEM that the Internet is not a network. Um, last I looked, the Internet is an interconnection of networks. Not a network in that sense. Edge devices can today, in the scenario you portray, pick the best network to connect to. Last thing we need is to ossify a method of doing that. Let the edge be the edge and do what it wants. On Aug 25, 2011, at 9:57 PM, Adam Novak wrote: I trust that some of you have seen this article from a while back: http://moblog.wiredwings.com/archives/20110315/How-We-Killed-The-Internet-And-Nobody-Noticed.html An informative except: When I open my laptop, I see over ten different wifi access points. Say I wanted to send data to my friend in the flat next to mine. It is idiotic that nowadays, I would use the bottleneck subscriber line to my upstream ISP and my crippled upload speed and push it all the way across their infrastructure to my neighbors ISP and back to the Wifi router in reach of mine. The Internet is not meant to be used that way. Instead, all these wifi networks should be configured to talk to each other. I also trust that you are aware of what happened to the Internet in Egypt (and elsewhere) this spring, where Internet connectivity was disrupted by shutting down major ISP networks. I would like to bring the attention of the IETF to what I see as a fundamental problem with the current architecture of the Internet: The Internet is not a network. As part of the development of the Internet, fault-tolerant routing protocols have been developed that allow a connecdestined fortion to be maintained, even if the link that was carrying goes down, by routing packets around the problem. Similarly, packets can be load-balanced over multiple links for increased bandwidth. However, the benefits of these technologies are not available to end users. If I have a smartphone with both a 3G and a Wi-Fi connection, downloads cannot currently be load-balanced across them. The two interfaces are on two different networks, which are almost certainly part of two different autonomous systems. Packets must be addressed to one of the two interfaces, not the device, and packets addressed to one interface have no way to be routed to the other. Similar problems arise when a laptop has both a wired and a wireless connection. Wired networks also suffer from related difficulties: If I have Verizon and my friend has Comcast, and we string an Ethernet cable between our houses, packets for me will still all come down my connection, and packets for my friend will still all come down theirs. The Internet, as it currently appears to end-users, has a logical tree topology: computers connect to your home router, which connects to your ISP, which connects to the rest of the Internet. Cell phones connect to the tower, which connects through a backhaul link to the rest of the Internet. Almost all of the devices involved have multiple physical interfaces and full IP routing implementations, but only the default route is ever used. This results in a brittle Internet: the failure of one ISP router can disconnect a large number of end-users from the Internet, as well as interrupting communication between those users, even when those users are, physically, only a few feet from each other. My question is this: what IETF work would be needed to add more routing to the edges of the Internet? If each home or mobile device was essentially it's own autonomous system, what would this do to routing table size? To ASN space utilization? How can individuals interconnect home networks when RIRs do not assign address and AS number resources to individuals? How might individuals interconnect home networks without manual routing configuration? Under what circumstances could an ISP trust a client's claim to have a route to another client or to another ISP? How might packets sent to a device's address on one network be routed to that device's address on another network, while packets to immediately adjacent addresses take the normal path? ___ 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: https
Two thoughts. On the one hand, Ned is absolutely correct: the thing we want to make absolutely sure of is the integrity of the object. The way of doing that is making sure the object itself can prove its integrity. In the messaging world, we do this with S/MIME. The use of TLS for SMTP or IMAP does not convey any integrity assertions for the object. Note this object should be signed by me when you receive it, by the way. On the other hand, while TLS is not at all sufficient for the integrity of the object, it is necessary to protect the individual accessing the object. There are a number of countries where asking for the RFCs relating to privacy, security, and threats to such too many times could get you arrested. Likewise, the presumption is the object might be signed, but it would be insane and useless to encrypt the object. However, there are many, many times one would want the object encrypted, even if only to compress it. Given that, the question should not be, Why are we using TLS if the object is not private?, but What are we not using secure connections for all IETF access, over any modality? One of the answers seems to be, Because it sucks. That is the sentiment of the message below. So we are eating our dog food, and we are getting indigestion. Sounds like an opportunity to fix it! -- - Eric On Aug 26, 2011, at 3:32 PM, Melinda Shore wrote: On 08/26/2011 11:22 AM, Adam Novak wrote: For what reasons? Is it that things scheduled every year or every ten years are easy for admins to miss? Or is it that it's hard to stay on top of certificate revocations when they occur? Firewall researchers have found at least one error of some sort in 99% (yes, really) of the firewall rulesets they've examined. If I had to guess how many PKI deployments have problems, I'd put it in the same ballpark. They seem to fall into several broad categories 1) naming (including SANs), 2) expiration, 3) faulty trust establishment. These may or may not be fixable, but what doesn't appear to be fixable is that too people don't really understand what certificates represent, the difference between a certificate and a key, or what it means to TLS-protect traffic. Listen to Ned, Adam. He's right. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
IAOC members are like all other IETF members. We pay for our hotel rooms. That means when I have a full-time job that wants me at the IETF, I stay at the convention hotel. When I don't have a full-time sponsor, like now, I stayed at: o A charming bed breakfast 500m from the Maastricht convention center. The entire week was the price of one night at the NH. In 2010 US Dollars, about USD 215. In 2011 US Dollars, about USD 260. Then again, that was per week, not per night. o A Hilton in Beijing. That was free for me, as I had tons of HHonors points. Taxi ~ USD 6/day. o The Hilton in Prague. Score! More HHonors points. Before anyone cries foul, I am NOT on the IAOC venue selection committee, so no, I had no influence on picking a Hilton. o A tourist hotel 2.5km from the Quebec convention center. That hotel was CDN 140/night less expensive than the Hilton. CDN 20/day, including tip, if you took a taxi by yourself. Much cheaper if you took mass transit. Yes, now I am low on Hilton points. In Beijing and Quebec I moved to the conference hotel mid-week because I had a sponsor for half the week. Your mileage may vary. On Aug 23, 2011, at 10:24 AM, John C Klensin wrote: Being a little cynical, I do wonder if we would see a difference in meeting selection patterns if all IASA staff and IAOC members were required to stay in hotel or other rooms costing no more than, say, your USD 200 per night figure (including transport, if necessary, to and from the meeting site). It might help to calibrate the pain level. The idea is not realistic for a number of reasons, but might make an interesting thought-experiment. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Queen Sirikit National Convention Center
I like Thailand, and Bangkok is a StarAlliance hub. I am assuming the political troubles are settled now, and probably will be for sure in 2 years. On Aug 5, 2011, at 3:46 AM, Glen Zorn wrote: I note that there is an opening on the IETF meeting calendar for an Asian meeting in 2013. Here is a suggestion: Meeting Facilities: http://www.qsncc.com/venue-information/our-facilities.html There are 7 pages of Official Hotels, starting at about $60/night. Official Hotels: http://www.qsncc.com/visitor/official-hotels.html gwz.vcf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
I think John has the issue nailed. I think it would be easy to try to eliminate the plenaries and then end up with a full Friday, anyway. I would offer that it would be very difficult, however, to take a compressed Friday and later add an afternoon to it. Thus, I am much more in favor of a compressed Friday, perhaps with some of the mentioned tweaks (a cookie break or a graham cracker and milk break for those who know the Montessori routine), than either leaving Friday as is or eliminating the Plenaries. BTW, has anyone noticed the trend of doing more and more on the Sunday and Saturday *before* IETF week? On Aug 1, 2011, at 10:32 PM, John C Klensin wrote: --On Monday, August 01, 2011 19:02 -0400 Margaret Wasserman m...@lilacglade.org wrote: ... If we don't want to hold meetings on Friday afternoons due to conflicts, I'd much rather see us eliminate one of the plenaries and hold meetings during that time slot. Margaret, FWIW, I personally think the plenaries have enough value, if only as potential checks on the leadership, that I'd hate to see one or both go. I even think their substantive content is occasionally helpful. However, my main purpose in responding to the above is to advise that you Be careful what you wish for. I suggest that, until we start pushing back aggressively on requests for meeting slots (or, if necessary, on new WG requests), the number of slots that are asked for will always expand to fill (or nearly fill) the number of slots available. The IESG has concluded that it is ok to have three meeting slots on Fridays. If we eliminate a plenary to open up one or two more slots and use those slots to stop using the Friday afternoon ones, I suggest that it will be only a matter of time before we have enough demand for slots that we expand back into the Friday afternoon times, retaining the slots that eliminate the plenary. If we really want to eliminate the Friday afternoon slots, then we should eliminate those slots, ratcheting up the criteria for getting meeting time to the point that we don't need them. Whether or not we need two plenaries (or one or zero or three) is almost independent of thet, even though we could get some short-term relief. Given the amount of burnout I often see by Friday, simply dropping the afternoon sessions is my personal favored solution. If we want to keep the Friday afternoon slots, or keep the number of slots that Friday afternoon gives us, then compressing the day make sense to me. Doing that compression according to the suggestion has disadvantages --both those you cite and others. But maybe modifying the proposal to include a short beverage and cookie break around 11:30 would make sense. Maybe there are other ideas too. But I think the trends are very clear and that, in the long run, eliminating a plenary would buy an extra slot or two (and another very long and exhausting day) but would not improve the Friday situation. john ___ 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: A modest proposal for Friday meeting schedule
I don't think I have seen a proposal like this before. I really like it, as there are a bunch of post-IETF stuff, some of which starts in the afternoon and thus conflicts with the IETF. This fixes that problem, enables us to have the same amount of meeting time, and potentially lets people get home a day early. On Jul 31, 2011, at 11:40 AM, Hadriel Kaplan wrote: Howdy, First I'd like to thank the organizers for IETF-81 for another well-run meeting. The logistics and coordination for such an event must be daunting, and I know we (the attendees) tend to focus on the negatives rather than the positives... but we really are thankful for all the time and effort put into it. Thank you! I would also like to propose a small change for future meetings. On Friday, instead of having a 2.5 hour WG meeting, followed by a 1.5 hour lunch break, followed by 2 hours of WG meetings... perhaps we could just have 4.5 hours of WG meetings straight and also start a bit earlier? Something like this: 8:30-11:00 Session I 11:15-12:15 Session II 12:30-13:30 Session III End That way the people who need to get to an airport get more time, or fewer of them have to miss WG meetings, etc. And it would help reduce costs for attendees if they can avoid staying Friday night at the hotel. And lunch at 13:30 doesn't seem unreasonable (to me). I apologize if this has been brought up before. I tried to find it from an old email thread for the Experiment at IETF-73 which added the Friday afternoon sessions, but did not see this proposal being suggested. -hadriel ___ 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: draft-housley-two-maturity-levels
On Jul 31, 2011, at 11:55 AM, RJ Atkinson wrote: On 31st July 2011, Brian Carpenter wrote, in part: [snip] It might cause a change, simply because the effort of making the single move PS-IS will get you to the end state, whereas previously you had to make two efforts, PS-DS-STD. But only time will tell if this changes our collective behaviour. Making this process change definitely will change my attitude towards trying to advance standards-track RFCs that I am directly involved with. Until now, the process overhead to move from PS to STD was far too great to justify the time spent. My perception is that this change reduces the process work substantially -- and a change in perception (i.e. perception by itself) is sufficient to increase my own motivation to make the attempt. While perception normally varies widely between individuals, on virtually all topics, I am not alone in in the view I've expressed just above. Yours, Ran This is the intent. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
And the real question is, are we moving forward? I think that we are not moving as far as we originally wanted. However, I offer we are moving a baby step forward, and as such is worthwhile doing. On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote: Scott - Didn't RFC 5657 address your point 2? The current proposal no longer requires this report during advancement, but it does not disallow it. I hope it's obvious that I believe these reports are valuable, but I am willing to accept the proposed structure, with the hope and expectation that communities that are serious about producing and refining protocols will be producing these reports anyhow. RjS On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote: this is better than the last version but 1/ I still see no reason to think that this change will cause any significant change in the percent of Proposed Standards that move up the (shorter) standards track since the proposal does nothing to change the underlying reasons that people do not expend the effort needed to advance documents 2/ one of the big issues with the PS-DS step is understanding what documentation is needed to show that there are the interoperable implementations and to list the unused features - it would help a lot to provide some guidance (which I did not do in 2026 - as I have been reminded a number of times :-) ) as to just what process is to be followed could be a spread sheet showing features implementations an assertion by the person proposing the advancement that the requirements have been met or something in between Scott ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Standards and patents
The patent would have expired by now? On Jul 28, 2011, at 10:47 AM, Samir Srivastava wrote: Hi, Thx for your comments. Private walled garden creates lots of interoperabilty issues. In the long term with deployments in the field, even after the expiry of patents we end up for a workable solution to carry unnecessary burden. e.g. I 'GUESS' pains of htonl etc are due to patents. IMHO we need to free human brain cpu for more important issues. It is not fair for people who work on unpatented baselines specifications. What would have been situation if IP header was patented? Thx Samir On 7/27/11, Alessandro Vesely ves...@tana.it wrote: On 27/Jul/11 08:07, Samir Srivastava wrote: Standards are developed by community for community. There is no role of patent hunters in that. I agree, with the exception of defensive patents, some of which are announced with very elegant disclosures. Let's draw a veil over incomprehensible and confused disclosures, for now. For the rest, what is the purpose of standardizing a private walled garden? ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: On attending BoFs
+$1.00 Have we ever had a BOF that looked under-attended? Not me: always standing room only! Big rooms = good BOF. On Jul 28, 2011, at 4:37 PM, Peter Saint-Andre wrote: On 7/28/11 4:06 PM, Murray S. Kucherawy wrote: When we ask for a BoF room, we need to give an indication of estimated attendance. Sometimes it’s hard to make a good guess and so we underestimate, intending to keep larger rooms available for groups that need them. I think the BoF chairs and responsible ADs need to request larger rooms for BoFs. After the REPUTE BOF, I talked with the Secretariat (specifically Wanda Lo, who does an amazing job with the schedule!) about poking the chairs and ADs when they request BoF rooms to make sure that we don't assign small rooms to BoFs, at least without careful consideration. Peter -- Peter Saint-Andre https://stpeter.im/ ___ 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: On attending BoFs
Just for the record: we want big rooms! On Jul 28, 2011, at 10:01 PM, Scott Brim wrote: And do you really only want people in the room who already know the issues and have decided to be for or against it? If you already have so many of them, you don't need a BOF at all, just take a hum and be done. The main purpose of a BOF is to present. Information to the community so they can decide if the IETF should adopt the work. ___ 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: How to pay $47 for a copy of RFC 793
Interestingly, when I look at the references from IEEE Xplore when I access Xplore from Georgetown, instead of the built-in Xplore reference, I get a GU search option, which does pop up the IETF copy of the RFC. In any event, I happen to know a few people at IEEE. They are looking in to it, it being adding the RFC series to Xplore. On May 10, 2011, at 9:34 AM, John C Klensin wrote: --On Tuesday, May 10, 2011 13:20 + John Levine jo...@iecc.com wrote: [snip] In IEEE Xplore, I can't find any RFCs at all, no matter how I search for them. Search for Transmission Control Protocol and you'll find lots of articles but no RFCs. I found what you found, i.e., no RFCs but several articles that referenced them. I thought I said that in an earlier note, but maybe I wasn't clear. best, john smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How to pay $47 for a copy of RFC 793
time = money On May 10, 2011, at 5:22 PM, Masataka Ohta wrote: Bob Braden wrote: I wonder how many other IEEE standards contain similar RFC-for-pay references.. It's common (much more than 50% for academic ones, IMHO) that sold articles are freely available on-line. For example, a PDF file of the paper End-to-end arguments in system design can be purchased for $15 from: http://doi.ieeecomputersociety.org/10.1145/357401.357402 which is the first link appears in google scholar search with the paper title, or, from: http://portal.acm.org/citation.cfm?doid=357401.357402 to which the above IEEE link is redirected, but is available free of charge from: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf which is the second link (next to google scholar one) with plain google search. It is a lot more time (and money) saving to search free versions before entering transactions to purchase them than to rely blindly on PubMed, IEEE, ACM, google scholar etc. Masataka Ohta ___ 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: How to pay $47 for a copy of RFC 793
Agreeing with John here re: it's just a bug. IEEE Xplore regularly does deals (read: free) to add publishers to the digital library. It is part of the network effect from their perspective: if you are more likely to get a hit using their service, you are more likely to use the service. We (RFC Editor? IAOC? Me as an individual?) can approach IEEE to add the RFC series to Xplore. On May 9, 2011, at 1:32 AM, John C Klensin wrote: --On Sunday, May 08, 2011 15:06 -0700 Bob Braden bra...@isi.edu wrote: I just discovered an astonishing example of misinformation, shall we say, in the IEEE electric power community. There is an IEEE standards document C37.118, entitled (you don't care) IEEE Standard for Synchrophasors for Power Systems C37-118(TM)-2005, which is currently of great importance for the instrumentation of the national power grid. I just noticed that it references RFC 793, and for curiosity looked to see how it was referenced. I found: [B8] RFC 793-1981,Transmission Control Protocol DARPA Internet Program Protocol Specification.[12] ... Now, it has always been IETF's (and even before there was an IETF, Jon Postel's) policy to allow people to sell RFCs. What astonishes me is that clever people in the IEEE don't know RFCs are available free online. I guess RFCs remain so counter-cultural that industrial types don't get it. I wonder how many other IEEE standards contain similar RFC-for-pay references.. Bob, What you presumably remember, but others reading this may not, was just how many comments Jon made about the impossibility of preventing fools from throwing their money away. And, of course, it is in the interest of Global Engineering Documents --which, in the era in which few folks had direct access to the Internet was one of the better sources for miscellaneous technical standards documents-- to let people continue to believe that they are a convenient and standard (sic) source. --On Sunday, May 08, 2011 21:26 -0400 John R. Levine jo...@iecc.com wrote: ... This isn't an enormous project, but it requires figuring out which online libraries are worth getting into, making the necessary arrangements with them (which may or may not involve money), a batch process to load in all the existing RFCs, and arrange with the production house to ensure that each new RFC gets listed as it's published. Most of these systems include abstracts and forward and backward references, which will doubtless require some debugging to make them work reliably. Like I said, it's a good project for the new RFC series editor. It should be a lot easier than deciding how to put Chinese names into RFCs. +1 I do note, however, that RFCs appear to be listed in ACM's Guide to Computing Literature (essentially part of the ACM Digital Library at this stage). Putting Transmission Control Protocol into the search mechanism turns up RFC 793 in a hurry. And, behold, they have full text available and retrieving it works without any charges other than the access fees for the Digital Library itself. RFC Editor is even on their list of publishers for search purposes. The problem is that the titles they index do not contain the RFC numbers, so looking up RFC793 or RFC 793. That is not a decision to avoid indexing the series (which would require the process John outlines to reverse) but a bug. I have filed a bug report as Digital Library feedback. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00
And the Proxy - Browser interaction is 100% out of IETF scope. For that matter, the IETF should be pointing out how dangerous and evil such a proposal is, as it means the end of consumer choice and a competitive marketplace for clients. On Mar 30, 2011, at 9:14 AM, Hannes Tschofenig wrote: Dave, I explain the change with two figures in order not to be misunderstood (again). I use SIP as an example; Jonathan gave a nice presentation. Working Assumption previously: .. . . .. .+---+ . . +---+ . .| | . SIP . | | . .| Proxy |- | Proxy | . .| 1 | . . | 2| . .| | . . | | . . / +---+ . . +---+ \. . /. .\ . ./ . . \ SIP . . SIP / . . \ . . / . . \. . /. .\ . ./ . . \ . . / . . \ . . +---+ . .+---+ . . | | . .| | . . | | . .| | . . | UA 1 | . .| UA 2 | . . | | . .| | . . +---+ . .+---+ . . Domain A. . Domain B . .. Figure 1: The SIP trapezoid We have lots of standardization efforts that focus on the UA-Proxy leg in the RAI area. Suggested new working assumption: +---+ +---+ | Web/| | Web/| | SIP | SIP | SIP | | |-| | | Server | | Server | | 1 | | 2 | +---+ +---+ / \ / \ Proprietary over / \ HTTP/Websockets / \ / Proprietary over \ / HTTP/Websockets \ / \ +---+ +---+ |JS/HTML/CSS| |JS/HTML/CSS| +---+ +---+ +---+ +---+ | | | | | | | | | Browser | - | Browser | | | Media| | | | | | +---+ +---+ Figure 2: Browser RTC Trapezoid The server-to-server interaction I was referring to in my previous mail is the interaction between server 1 to server 2. With cross-domain usage there still a standardization need. This is what I mean by the interoperability need shifts. We had spoken about the implications of that change already. Ciao Hannes On 3/29/2011 1:31 PM, Hannes Tschofenig wrote: Correct. The interoperability need shifts away from the client-to-server side (for example, to the server-to-server side; No, that's wrong and I believe it is not what Eric said at all. THERE IS STILL A CLIENT/SERVER PROTOCOL, HANNES. ALL THAT CHANGES IS THAT THE CLIENT/SERVER PROTOCOL IS NOW PROPRIETARY. I apologize for shouting. I'm shouting for the classic reason that I'm taking your continuing to misunderstand this multiply-repeated and very basic point as a hearing problem. Server-server is an entirely different task and different part of the architecture. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf
Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00
I think this encapsulates what Dave is trying to get across: Yes, it is MUCH easier for a server developer to stuff in a little more JavaScript. Now, you have a 100% proprietary system, with no hope or desire for interoperability, that gets deployed much faster than someone taking their extension to the IETF for inclusion in, for example, IMAP. The only reason one would go for the standard solution is if they want to interoperate with other vendors. As you point out, there is absolutely no reason for anyone to participate in the standards process if they have no intention of interoperating with OTHER implementations. On Mar 28, 2011, at 1:53 PM, Hannes Tschofenig wrote: I think the important aspect for IETF standards development is the following. IMAP and POP are protocols standardized a while ago already. They exist and that's fine. Imagine that you are a protocol designer that wants to develop a new feature for an email client. As an example, you want to define a new extension that makes certain email functions more efficient or so. You now have various options: You can write a new specification (like we did in the past) or you could add a piece of HTML/JavaScript code to your deployment and make use of it. It will immediately be available to your customers that use email through a browser. Which approach is the right one to do? Well. It depends on a number of factors. The authors view is that the increased importance of the Web deployment will lead many developers to consider the second option rather than to go for the former. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and APIs
Would we not be better off just asking (mandating?) at least one open source implementation? That effort would produce a de facto API. On Mar 29, 2011, at 11:17 AM, Sam Hartman wrote: Dave == Dave CROCKER d...@dcrocker.net writes: Dave On 3/29/2011 10:13 AM, Sam Hartman wrote: At the mic at the technical plenary last night, I made a comment that I strongly supported the IETF doing API work. I've realized that people may have assumed I meant that it would be appropriate for the IETF to specify an API and not a protocol for some given task. That's not what I meant, so I am writing to clarify. I think that multiple levels of interoperability will be required for building blocks used in platforms including the web platform. Dave Multiple levels of interoperability sounds interesting, and Dave very possibly quite important. One level is the traditional protocol interoperability we normally discuss. Another level shows up when you want to write a cross-platform application. It's not good enough if Windows has some API. I want to have confidence that functionality is available on Windows, OSX, Linux and some of the mobile platforms before I depend on that functionality in a cross-platform API. Within the web platform, I want to make sure functionality is available on multiple browsers before I depend on it in my cross-browser application. we're the IETF. We should definitely specify protocols for the building blocks we create. However, one problem that hurts interoperability is when platforms provide different APIs or abstract interfaces to applications. Dave ... I think that we should move more into that business. I see no problem with actually specifying a language-specific API when the WG involved has the skills to do a good job. Dave Wow. What is the list of languages we should work on? C, Dave C++, Javascript, Java, Python, ...? Any of the above when it makes sense for a WG to do the work. I'd expect that typically you'd only specify one or two language bindings for a given interface. You should have a need to do the work, have the necessary skills to have probable success, have the necessary skills to get review and have people volunteer to do the work. Dave Which is not to deny the problem you cite: APIs differ and Dave this hurts interoperability. Dave One approach to solving it is, indeed, to specify /all/ of the Dave APIs that map to the protocol. Dave Another is to do more and better interoperability testing and Dave let the API developers see their deficiencies and fix them. Dave The benefit of this is that it moves the problem to the folks Dave with the knowledge and incentives to work on it and it takes Dave this very expensive specification task out of the IETF's Dave critical path. My experience is that protocol interoperability testing does not actually lead to cross-platform interoperability. This is especially true for building blocks intended to be used by components that are developed later. The issue is that the people doing interoperability testing at the protocol layer don't tend to be testing for whether things work the same way between platforms. It is when you try and build something on top of a building block that you notice the problem. You tend to notice at one of two layers. The first is if you standardize the higher level item and have participants familiar with multiple platforms involved in the standardization. You can then discover that you don't have sufficient overlapping functionality on platforms to do what you want. Another case where you discover the problem is when you implement and people discover that they cannot do so. Factors that contribute to cross-platform interoperability issues include the following. Often, the people designing and implementing the building block are not the same as the people using the building block. Often, there is separation in time between building block design and building block usage. Often, various factors complicate changing the platform to expose new functionality. In conclusion, in cases where these types of issues are likely to be important, I believe we should do work. Work can include work on abstract interfaces, which will be easier to justify. Work can include concrete APIs which will sometimes be appropriate. I would prefer that this work be standards track not information. Discussions of how to advance MIBs, GSS-API and other standards-track elements already give us approaches to judge interoperability for such elements. --Sam ___ 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: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00
Got it in 1. On Mar 29, 2011, at 1:40 PM, Dave CROCKER wrote: On 3/29/2011 1:31 PM, Hannes Tschofenig wrote: Correct. The interoperability need shifts away from the client-to-server side (for example, to the server-to-server side; No, that's wrong and I believe it is not what Eric said at all. THERE IS STILL A CLIENT/SERVER PROTOCOL, HANNES. ALL THAT CHANGES IS THAT THE CLIENT/SERVER PROTOCOL IS NOW PROPRIETARY. I apologize for shouting. I'm shouting for the classic reason that I'm taking your continuing to misunderstand this multiply-repeated and very basic point as a hearing problem. Server-server is an entirely different task and different part of the architecture. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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: draft-housley-two-maturity-levels
Agreed. On Mar 24, 2011, at 12:13 PM, Bob Hinden wrote: On Mar 24, 2011, at 5:01 PM, Dave CROCKER wrote: On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote: Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Generally, the document tries to limit itself to discussion of what it changes. There are no changes proposed for moving to Historic. (The question of Historic has not been part of the many discussions about streamlining the standards labeling.) Hence that issue is out of scope for the document. +1 Bob ___ 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: SDO vs academic conference, was poster sessions
Speaking personally, with none of my official hats on, I would offer the IETF is *only* an SDO. There are no sponsoring organizations, because the IETF is a collection of individuals. No sponsor needed. For that matter, some individuals consider some sponsors toxic, so sometimes having a sponsor is a negative. When one mentions 'finding a problem and proposing a solution,' if the problem is with an Internet protocol or an Internet protocol can solve the problem, then the IETF is the place to take the work. However, if the problem is with Internet operations, then a place like the INET (ISOC-sponsored) or NANOG/APNOG/AfNOG/EOF would be a better place to go. If the problem is about domain administration or governance, then ICANN is where to go. If the question is about governance, then your local ISOC chapter or IGF would be a better place to go. Parochially and from a purely self-serving perspective, I would offer the Internet Society has *a* I* organizational coordination role. However, before the flames start from long-time I* participants, I would also offer that Internet governance is BY DEFINITION distributed and ANY organization that claims to be to be the center of the Internet universe/governance/technology is both delusional and probably does not have the support of ALL constituents (users, manufacturers, operators, and governments). I would offer the IETF has near universal support for producing protocols from the global constituency, and near no support for anything else. On another one of your questions, I would offer that for better or worse, the IETF ignores the question who is the consumer of IETF work product at a formal level. The IETF does not produce protocols for governments. The IETF does not produce protocols for operators. The IETF does not produce protocols for vendors. Rather, as a collection of volunteer individuals, the IETF produces protocols the individuals are WILLING to produce. This is microeconomics at its best. For people to volunteer literally millions of dollars worth of engineering time per year to the IETF, the IETF has to be relevant. However, rather than being relevant because some government says it is relevant or being relevant because an industry consortium says it is relevant, the IETF is relevant because it has a history of producing relevant work. Because of that history, people (individuals!) bring important, relevant work to the IETF. Presuming other INDIVIDUALS see that work as being important, it gets worked on. The fastest way to find out if ones work is relevant to the Internet *protocol* community, and note this is NOT necessarily the Internet community at large, is to bring it to the IETF. If it is relevant work, it gets worked on. You do not have to be from a member state, a member vendor, a member operator, a member institution. You just need an email address. FInally, one of my personal goals is to keep reminding folks that the IETF does engineering, NOT research. If one has an idea that is not fully baked, the IRTF is a great place to bring the idea to where one can get the benefits of experienced IETF people without the drawbacks of an SDO. On Jan 11, 2011, at 6:24 AM, Alessandro Vesely wrote: On 10/Jan/11 23:38, Fred Baker wrote: Personally, call me stuck-in-the-mud, but this isn't an academic conference in which grad students are advertising for a professor that might be interested in mentoring them or a sponsor might fund their research. This is an SDO, and internet drafts are what any other SDO calls contributions or work in progress. I would far rather have people who ant to talk about something contribute an internet draft on their topic, and talk with other people about their ideas - whether on working group lists or other places. For those of us that *do* participate, it seems to mostly work. OTOH, for those of us who don't participate, it doesn't :-) My ignorance of IETF's inner functioning is so deep that I cannot even tell what is the equivalent of a mentoring professor or a sponsoring organization within the IETF, let alone finding one. As an Internet user, I may have a problem, hypothesize possible causes, and wait for solutions to be proposed or formulate a tentative solution myself. The question is, is the IETF the natural referent of such occurrences? Does the I in its name promote it as the universal coordinator for Internet related issues? I think a negative answer would affirm the view of the IETF as an SDO only. This would rise further questions such as who are its customers --possibly the IGF or similar assemblies-- and what kind of mechanisms do they use to order what has to be standardized and how. A positive answer would imply the IETF is something more than an SDO. Possibly the embryo of a technocracy. That would call for more dendritic links to the Internet at large. For example, someone proposed to add more entries
Re: Clarification for Copyright to referred material in IETF draft
[Soapbox warning] I love it! Finally a use for Informational RFC's that I get: Let's turn Wikipedia pages into RFC's! [NOT] On Dec 14, 2010, at 10:42 AM, Marshall Eubanks wrote: On Dec 14, 2010, at 7:40 AM, Noel Chiappa wrote: From: Simon Josefsson si...@josefsson.org Wikipedia has .. stable URLs, which makes it on par or better than other external references. That's a sad truth - I find link-rot is an incredible problem with references when I'm looking at older material; stuff seems to go offline all the time, even valuable material. The company decides to redo their website, or someone moves to a new organization, or, or, or... The IETF probably should archive any material used as a reference in an RFC, at the time the RFC is published. I do not believe that this would cause copyright issues (note : IANAL), but making that archive publicly available might. Maybe we could do something there in connection with the Internet Archive. Regards Marshall Noel ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Two step, three step, one step, and alternatives
+1 On Nov 13, 2010, at 7:01 AM, John C Klensin wrote: Russ, I'd like to make a suggestion that I hope you will find helpful. We've now got your/the IESG's two-step proposal, Dave's alternative, discussions about going directly to single step, an orthogonal proposal about STD numbers (or an alternative), some other suggestions that haven't made it as far as I-Ds, and probably some things I've missed or forgotten. To a greater or lesser extent, each of these has produced a flurry of comments on the list. Those flurries have mostly occurred just before or during IETF when some of us can't manage to read messages that are not absolutely critical-path. They also create a lot of noise for those who aren't interested and may cause relevant discussions of other topics to be lost. For protocol specs, our normal way to sort of competing and variant proposals is to form a WG. We know that doesn't work well for procedural documents. Partially as an experiment, would you consider creating a separate list, pointing the discussion there, and appointing a rapporteur or two with responsibility for figuring out when discussions have stabilized and then coming back to the IETF list with a summary of that stability point, tradeoffs, etc.? I'm not at all sure it would work but, if it did, it would save us time and likely result in a better result. Worth a try? john ___ 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: Alternative Proposal for Two-Stage IETF Standardization
And for the most part, we have had decent success with self certification in SIP and VPIM, as two examples. On Nov 12, 2010, at 12:25 AM, Spencer Dawkins wrote: I think it would be sufficient to say something like: The following implementations represent a significant Internet deployment and they are based on the specification in RFCn: -a -b -c - ... wfm. and seems very reasonable to me as well... Spencer ___ 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: [IAOC] [79all] IETF Badge
As far as I know, anyone with an email and a credit card can come to an IETF meeting. Anyone without an email and an ability to pay the registration fee cannot come physically to an IETF meeting, but can still participate over the Internet. It is an incredible stretch to say checking badges at an IETF is a free speech issue. On Nov 12, 2010, at 8:57 AM, Peter Saint-Andre wrote: On 11/12/10 12:37 AM, Eliot Lear wrote: Is there is an unspoken concern in this discussion as to whether the host wanted to take names based on what people were saying, in the case they said something objectionable? There might be many unspoken objections, e.g. that a certain kind of host might want to keep random locals out of what could be perceived as a free speech zone. Peter -- Peter Saint-Andre https://stpeter.im/ ___ IAOC mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/iaoc smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
I would offer we do the venture capital lightning round thing. Schedule a *single* 2.5 hour slot for *all* BOFs. Each BOF proposer gets 5 minutes to make their pitch and 10 minutes of discussion. I would bet that 15 minutes of FOCUSED attention would give the IAB and IESG enough input as to (1) is there community interest, (2) is there community expertise, and (3) is the IETF the right place for the activity to occur. Since Dave Crocker and John Klensin need to be at every BOF, this makes it easy for them to attend every one :-) On Nov 8, 2010, at 10:26 AM, The IESG wrote: The IESG is seriously considering a WG and BOF scheduling experiment. The goal of the experiment is to provide WG agenda sooner and also provide more time to craft BOF proposals. The proposed experiment includes three parts. First, schedule all BOFs for Monday afternoon. Second, schedule WGs before we know which BOFs will be held. Finally, provide an additional four weeks to deliver BOF proposal to ADs. Please let us know whether you support this experiment. Discussion is welcome on the mail list and the plenary on Wednesday evening. On behalf of the IESG, Russ Housley smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: what is the problem? (was Re: draft-housley-two-maturity-levels)
+1 On Oct 26, 2010, at 3:04 PM, Fred Baker wrote: On Oct 26, 2010, at 10:19 AM, Phillip Hallam-Baker wrote: Action We should adopt Russ's proposal: Axe the DRAFT status and automatically promote all DRAFT status documents to STANDARD status. This can be done formally by changing the process or the IESG can just agree to a convention where every DRAFT standard is automatically promoted. [snip] The Internet is now a large place with two billion users. Any institution that wants to be influential in shaping the future of the Internet has to be willing to commit to the proposals it is making. The current process represents an abdication of will and a failure of commitment. It should be corrected as a matter of urgency. I agree with much of that, but suspect I might have worded it differently. Bottom line, we put a lot of effort into making documents at the Proposed level right, and at that point the people working on it have neither incentive nor energy left to do anything more with it unless it is shown to have a bug. There are people that will only buy a product if it has been interoperability-tested with another vendor's product; they generally do interoperability testing themselves. So yes, move Draft Standards to Standard, and eliminate Draft Standard as a status. I might also make two other changes. There is a rule in 2026 that says that every feature of the protocol has to be shown interoperable, and it strongly prefers complete implementations - and wants an updated version with the unused bits removed. It turns out that this becomes hard to accomplish for various reasons, and is one of the issues with taking protocols to Draft (er) Standard. It could also be described as the purpose of a PICS Pro Forma; other standards bodies write documents that say when you are using protocol X for purpose Y, you need to implement features Z1, Z2, and Z3. PICS make me crazy, but they may be an acceptable alternative to the current rule. And how do you do interoperability testing? I suspect that if N vendors care and are in a position to say that they have several common customers that are using both of their equipment interchangeably in the same network, that constitutes prima facie evidence of interoperability. We would need to clearly specify what an acceptable statement of interoperability is, but we might consider that approach. ___ 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: draft-housley-two-maturity-levels
Look at RAI: I would be grateful if some proposals had running code that ran once. On Oct 27, 2010, at 7:16 PM, Peter Saint-Andre wrote: As I understand it, running code means that the technology has been deployed across the full breadth of the Internet, in services large and small, by individuals and companies and service providers and universities and government agencies and all the other kinds of entities that are connected to the network. The technology doesn't need to be universally deployed, but it does need to be widely deployed. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: what is the problem bis
Actually, my heartache with Russ' proposal is the automatic If it's Draft, it's now Standard. I would be quite happy with Proposed and Internet Standard, with NO grandfathering. On Oct 26, 2010, at 5:57 PM, Ofer Inbar wrote: On Oct 26, 2010, at 2:39 PM, Dave CROCKER wrote: I'm a fan of reducing down to 2 levels, too. But it has nothing to do with how overblown the effort to get to Proposed is. (Well, I feel like we already have a 2-level system. What's the practical difference between Proposed and full Standard? It may take a lot of effort to make that jump, but what difference does it make outside of the fact that the document now has a new label? Who notices or cares about the distinction? Does it affect anything real? These aren't rhetorical questions. I feel like there's no practical effect, but I may be wrong, and I'm asking. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
The known problem is it takes well over four years to get anything published. I am experiencing in one never-ending saga the logical conclusion of the logic: since Proposed Standard is the new Draft Standard, and since the IESG has to make sure any proposal is beyond bullet-proof, the industry has long since implemented draft-mumble-21, which has not changed for over a year, and few in industry cares if the document publishes as an RFC, because from their point of view, if something has been working in the field for three years, has 18 independent implementations, and has not yet crashed the Internet, it is probably ready, whether the IETF formally says so or not. That is the fast track to making the IETF irrelevant. The very real danger here is while that attitude may be OK for a small media application, that attitude could be a disaster in, for example, the routing area. Something really has to be done. Now, I do agree with Scott here there is absolutely no incentive for anyone to bring a protocol to Draft/Internet Standard level. What I *am* hoping is that with two, clearly defined maturity levels, we can go back to publishing Proposed Standards in about a year, and have Internet Standard mean something. Otherwise, we will be perpetually running the Internet on Internet Drafts, which is something I do not think anyone really can say is a good thing. On Oct 25, 2010, at 10:48 PM, Scott O. Bradner wrote: I'd like to hear from the community about pushing forward with this proposal or dropping it I do not think this proposal fixes any known problems the major reason (imo) that technology is not advanced along the standards track is because there is no need to do so. someone labors for a while to get a proposed standard published and people start to use it (if they did not start at the Internet Draft stage) soon about anyone that has a need for the technology has implemented it and it is being used by customers all over the globe just what is the reason that someone would take time from working on new technology to do the work to advance the proposed standard? it is unlikely that all that many more people will implement or use the technology so what is the point? in addition, the IESG acts as if the proposed standard will be the last step in the publication process (or at least reviews IDs as if this were the case) so we have all the benefits of the cross area review (this making the proposed standards about as good as one could without requiring interoperable implementations at the first stage (i.e. bringing back running code)) so I say drop it and live with the fact that rfc 2026 does not paint an accurate picture of the current one step standard process Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Ever since Proposed Standard became Draft Standard for all practical purposes, might as well make it official. On Oct 25, 2010, at 8:35 PM, Brian E Carpenter wrote: On 2010-10-26 13:22, Barry Leiba wrote: I'd like to hear from the community about pushing forward with this proposal or dropping it. I see disagreement with the proposal, but we'll see disagreement with any proposal. I see enough support to continue pursuing it, in my opinion, and trying to find a balancing point that enough of us can agree with. I am happy to agree to what the draft currently says. We've sliced and diced this many times over the years, and this seems very close to the least-unpopular view. That's the best we can hope for, imho. Brian I'd like to see work continue. Barry ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
