Re: Proposed Standards and Expert Review (was: Re: Last Call draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard))
From: John C Klensin john-i...@jck.com My problem here, which I hope was clear from the note from which you quoted, is that a request/document in the second category was proposed for Standards Track and then that comments that would be entirely appropriate for a Last Call on a Standards Track document were essentially rejected on the grounds that they would require changes to already-registered RRTYPEs. This seems to be the only truly controversial point, and it is very important. The IETF does not promote something to a standard just because someone (or even lots of people) are already doing it. It is, however, perfectly acceptable to document it, and even to document that some other group has anointed it as a standard within *their* practice. Dale
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
From: Keith Moore mo...@network-heretics.com On 05/21/2013 10:04 AM, Joe Abley wrote: With respect, *my* question as the author of this document is simply whether the specification provided is unambiguous and sufficient. It was my understanding that this was the question before the community in this last call. The criteria for Proposed Standard are quite a bit higher than that. See RFC 2026 section 4.1.1. Coming into this from the outside, the issues are interesting. I originally thought RRTYPEs are scarce, since all the ones I was aware of are less than 256. But it turns out that RRTYPEs are 16 bit integers, and we've only consumed about 110 of them in ~25 years; we have about 15,000 years' supply of them. So they can be handed out rather generously. There actually is a standard for allocating RRTYPEs, which is RFC 6195 (section 3.1). RRTYPEs are to be handed out rather freely. OTOH, the standards for Proposed Standard are stricter. In regard to the question of whether to use one RRTYPE or two, it seems that the question is whether, in practice, it is common to want to query for both EUI-48 and EUI-64 for the same domain name at the same time. In regard to *how* to subtype a single RRTYPE, the resource records themselves contain a DATA length field (RDLENGTH, see RFC 1035 section 3.2.1), so if we used only one RRTYPE, the RDLENGTH field would differentiate EUI-48 from EUI-64. There are 768 RFCs that have INFORMATIONAL status and contain the word MUST -- and that is over 10% of the total number of RFCs published to date. So it looks like RFC 2119 terminology is commonly used in informational RFCs. Personally, it seems like a good idea. If you want to notify the world of a privately-developed protocol, you want to be able to say MUST and SHOULD; labeling it as INFORMATIONAL makes clear that the IETF hasn't endorsed the protocol. Dale
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
From: Thomas Narten nar...@us.ibm.com What I do think the IETF should do is *require* that participants identify themselves. That means knowing who they are (a name and email contact) and an affiliation. For 80% of the participants, this info is not very hard to figure out (see below). But we also have participants that use obscure email handles that don't correlate to anything obvious, whether a real person or to a name in the list of registered attendees, etc. I suspect these folk are *not* intenending to be anonymous participants, but in practice they are. And yes, knowing who someone is, their background and who they work for is important to me in figuring out how to guage their input. E.g., I would likely pay more attention to an operator's comments on a proposed use case than from someone else. I believe that this is a less good idea than first appears. One objection is that the concept of affiliation is less simple than it appears. People normally expect it to mean Who is your employer? As John mentions, it can mean What is the organization whose interests you are promoting? But in regard to your observation about use cases, it can also mean What area of technology do you have experience in? In many cases, affiliation is related to Who is paying for your attendance? But there are situations where your employer may be willing to pay for your attendance but doesn't want you to be seen as officially representing them. And (at least in common-law countries) one can simply invent an (unincorporated!) company name and claim it as your affiliation. In practice, the way we deal with these problems is that we consider everyone to be individuals, rather than as the representative of company XYZ, and it takes time to build a reputation. One is thus unwilling to sacrifice that expensive reputation to advocate a poor solution because one's employer favors it. 3) Google names, look at authorship info in RFCs, linked in, etc. Works in a lot of cases, but is sometimes more work than seems appropriate. If you can't find any information about them, they have no reputation. Dale
Re: article on innovation and open standards
From: Thierry Moreau thierry.mor...@connotech.com Some sections of the IETF would be more vendor-heavy, e.g. the routing area. In those sections, only a serious economic study might tell to which extent the patent pool (wikipedia is your friend) excludes the permissionless inventor in those IETF sections. My impression of the presentation is that it does not focus on innovation that is part of, and extends, an existing technological area, but rather innovation that uses existing technology as a platform upon which to build new technology. This sort of innovation is less vulnerable to attack via patents, but it is vulnerable to service providers that can differentially price the use of the platform within the new application. Dale
Re: article on innovation and open standards
From: Andrew Sullivan a...@anvilwalrusden.com The critical difference is that the IETF is an organization of *buyers* rather than an organization of *sellers*. Without wishing to be nasty, I will point out that we have way more vendors than operators participating in our standards development. That is actually what I mean... By sellers I mean sellers of telecommunications services. The equipment vendors generally favor the interests of the buyers of telecommunications services, who are their customers. Dale
Re: article on innovation and open standards
From: Jari Arkko jari.ar...@piuha.net Just FYI that I wrote another article, this time on permissionless innovation and the role of open standards. A nice summary! No permit had to be applied [for], no new network had to be built, and no commercial negotiation with other parties was needed when Facebook started, for instance. And one consequence is, No incumbent could value-price its services so as to extract the added value created by Facebook. But I don't think that would be very popular at the ITU! The critical difference is that the IETF is an organization of *buyers* rather than an organization of *sellers*. Dale
Re: Accessing tools from IETF pages
From: t.p. daedu...@btconnect.com I wanted to submit an I-D so I wanted to access the tools, as I have done before, so I clicked on 'IETF Tools' from http://datatracker.ietf.org/wg/ and when that failed tried again with 'Tools Team Pages' from http://www.ietf.org/iesg/ with the same result. Can anyone else get to tools from that link? It resolves to http://tools.ietf.org/ which Internet Explorer (what else?) assures me cannot be displayed, either from the link or from typing it into the Open drop down. Well, all three of those links work for me at May 8 19:33:01 UTC 2013 using Firefox 18.0.2 on Linux. (For whatever that is worth.) I'd sniff the HTTP transaction to get some information on the specific failure mode. Dale
Re: Language editing
From: Brian E Carpenter brian.e.carpen...@gmail.com On 04/05/2013 09:22, Yaron Sheffer wrote: GEN-ART is a good example, but actual document editing is much more work and arguably, less rewarding than a review. So I think this can only succeed with professional (=paid) editors. I think I disagree, if we can find the knack of effective crowd-sourcing. We do after all have several hundred native English speakers active in the IETF, which would mean each one would have to volunteer for less than one draft per year and we'd be done. I don't know how much experience you have with professional editors. Apart from the RFC Editor crew, my experience has been mixed. Somebody a year or three ago (the last time we had this exact same discussion) pointed out the differences between copy-editors and technical editors. One difference is that the latter are much more expensive. Copy-editors tend to be rule-driven; technical editors are supposed to understand the material. In a sense you're right; if we could find sufficient members who are good at editing technical English and motivate them to do so, then the problem would be solved. However, I don't see any of those conditions becoming true. As an organization, we don't place much value on making the *words* of a document clear and correct, and neither do our employers. And relatively few engineers can write high-quality English specifications. More subtly, our process works against us, because we use technical contributors as the document editors. Improving writing is a matter of zillions of relatively small changes, which is inefficient to do if the person weilding the pen isn't the person who is working out the corrections to the majority of the sentences in the document. Dale
Re: Language editing
From: Scott Brim s...@internet2.edu My experience is that unless the editors have some background in protocols, this takes a surprising amount of effort, explaining it to them and catching _their_ mistaken assumptions (which can be subtle). I'm told that the CCITT maintains a staff of technical writers. Certainly, the *writing* in their standards is better. Dale
Re: W3C standards and the Hollyweb
From: m...@sap.com (Martin Rex) DRM system are evil in any way you look at it. Originally, copyright was a conceived as a temporary (50yrs) monopoly. The protection period has in recent years been prolonged in many years to at least 70 years. [...] I read an analysis somewhere that pointed out that DRM is evil in considerably different ways than one naively thinks. You tend to think of DRM as a way of enforcing copyright. But the real power of DRM is in effectively eliminating the right of first sale. Currently, once you've bought a copy of a copyrighted work, you have bought a physical object, the copy, and that ownership gives you a bundle containing a considerable number of rights, including the right to sell the copy to someone else. The real economic purpose of DRM is to be able to subdivide the bundle of rights traditionally associated with the copy so that they can be sold and priced individually. Even better, since the copy may no longer be transferrable between customers, different customers can be charged different prices for the same thing. The net effect is that the work creators can get larger aggregate sales for the creation than before. Which may or may not be a good thing. Wikipedia has a long article, Price discrimination, on this. Dale
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
From: Ted Lemon ted.le...@nominum.com On Apr 16, 2013, at 11:51 AM, Dale R. Worley wor...@ariadne.com wrote: I've advocated the equivalent of the following opinion before (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but in the current context it bears repeating: Here in the IETF we accept that low-status people may argue regarding technical matters, but reserve for high-status people having opinions about our procedures. I thought your original message (the one you cite above) was very good, but I'm not sure I like the terms low-status and high-status, simply because tey could be easily taken to mean something other than what I think you intend them to mean. We do have a status system within the IETF and generally one gains status within that system by recognized technical work. And on certain sorts of issues, particularly changes in processes, we don't listen well to people who don't have high status within that system. In that regard, the IETF is far from egalitarian. In regard to diversity issues, it is important to ask whether position in the status system is directly affected by factors other than just technical contribution. Probably more important for diversity issues is that factors in a person's life other than their outright technical ability can strongly affect their ability to contribute to our technical work, and thus achieve the status needed to be influential. A more subtle problem is whether technical contribution correlates well the skills needed for leadership positions -- does being a quality technical contributor demonstrate the skills needed to be an effective IAB member? Although given the discussion around IESG review, it seems that the reward for gaining the leadership position of IESG membership is becoming an extremely busy technical reviewer of standards... Dale
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
How can a memebr of staff in a company argue with the manager about the manager's decisions or performance? It is IMO the *obligation* of a professional to call his manager on wrong decisions or performance. I've advocated the equivalent of the following opinion before (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but in the current context it bears repeating: Here in the IETF we accept that low-status people may argue regarding technical matters, but reserve for high-status people having opinions about our procedures. Dale
Is there a Git repository of RFCs? Or of Internet-Drafts?
Is there a publicly-available Git repository of RFCs or of Internet-Drafts? The reason I ask about a Git repository is that regular Git pulls from such a repository seems like a straightforward and well-supported way to maintain a local copy of the document collection. Dale
Re: Fwd: Re: [IAB] WCIT slides
From: Joel M. Halpern j...@joelhalpern.com With apologies for the problems making these slides available, and thanks to Bernard for finding a work-around, for now the slides are available via links from http://www.iab.org/2013/03/14/wcit-what-happened-whats-next/ In this mailing list: - One major component of the WCIT kerfuffle is that governments (especially those of less-devleoped countries) want to have more influence in Internet processes. - Another thread lamenting the lack of people from less-developed countries who attend the IETF and participate in various of its leadership activities. A common solution to these problems would be for the governments in question to provide long-term sponsorships for their citizens to attend and participate in the IETF. This would probably cost less than many of the activities the WCIT treaty was proposed to enable! Dale
Re: Is there a Git repository of RFCs? Or of Internet-Drafts?
From: Christopher Morrow morrowc.li...@gmail.com curious why rsync doesn't also seem 'straightforward' and 'well supported' ? Is this an advocacy of a particular tool? Or are you asserting that rsync can be used to maintain a directory of RFCs? If the latter, could you supply some details (including, especially, how to get at the public repository)? Dale
Re: Diversity of IETF Leadership
From: Scott Brim s...@internet2.edu On 03/11/13 14:41, Mary Barnes allegedly wrote: This year's set of nominees was far more diverse than in the past and yet the IESG will still be entirely male and entirely North American/European. Of course, only people that bothered to use the tool to input comments would see that. So, indeed the nomcom process is part of the problem. Mary: I believe you would agree with this but your language doesn't seem to say so: just because the nomcom chose a less diverse set of nominees from a more diverse set of candidates doesn't mean there is something wrong with the nomcom or the nomcom process. That is true, but this message of Mary's is one of the few items of *data* we have on the subject: The diversity of the selected people (along the dimensions we are considering) is noticably smaller than the diversity of the pool from which they were selected. So we can conclude that there is some factor operating within the Nomcom process that we should examine and analyze and may wish to change. (As opposed to the possibility that the output of Nomcom has the same diversity characteristics as the input of Nomcom, in which case, trying to fix the Nomcom process would probably be ineffective.) In regard to data, I see that the statistics on nation of authorship for recent RFCs (http://www.arkko.com/tools/recrfcstats/d-countrydistr.html) is even more US-heavy (~70%) than the statistics for all RFCs (http://www.arkko.com/tools/allstats/countrydistr.html) (~50%). It's possible that IETF participation even at the purely technical level has become less diverse over the past decade. In regard to data, I expect that there are several levels of participation which may have very different statistics due to the difference in time/money costs involved: 1. participants in WG mailing lists 2. authors of drafts 3. regular attendees of the meetings 4. WG chairs 5. AD/IESG/IAB members My guess is that groups 3 and 4 are fairly similar, but that group 3/4 may differ strongly from group 5 and groups 1 and 2. Dale
Re: Nomcom Reports
From: Mary Barnes mary.ietf.bar...@gmail.com As far as I can tell, the last official Nomcom report was from the Nomcom I chaired (2009-2010): http://tools.ietf.org/id/draft-barnes-nomcom-report-2009-00.txt I have a general question for the community as to whether they find such reports useful and whether we should encourage future nomcom chairs to produce these? I haven't read this NomCom report, or any others. But I consider them very valuable -- if I ever considered volunteering for NomCom, I'd want to read the last five or more reports to get some background on the job. Dale
Re: Call for Comment: RFC Format Requirements and Future Development
Wouldn't it suffice to say The IETF should not use a document format if it is substantially bulkier than an alternative format that satisfies substantially similar goals. and leave the details to the RFC Editor? Dale
Re: Appointment of a Transport Area Director
From: Randy Bush ra...@psg.com as an area director, it was not the technical load which was hard, and i read every single draft (draft load has grown since). it was the social and political 'work'. One possibility might be to split TSV into two areas, so the workload on the TSV ADs (both technical and social) is reduced. Dale
Re: IETF Challenges
From: Michael StJohns mstjo...@comcast.net At 07:38 AM 3/3/2013, Abdussalam Baryun wrote: Under the IETF role it is very easy of WG chairs to ignore minority participants of large communities. I've come to the conclusion - possibly wrong - that you're lacking some basic understanding in the operational model of the IETF. Unlike most other standards bodies, the IETF tries to get good technical contributions from smart technical people, not based on voting status of their company or country. If you have a good idea, [etc.] Let me try to explain that point in a different way. The model that the IETF attempts to follow -- and generally does fairly well at following -- is to consider all participants as *individuals* not as *representatives* (of particular companies, of particular countries, or of particular communities). All may speak, but not all are listened to. One is listened to depending on one's reputation. Basically, that reputation is established by sound technical contribution. It generally takes around a year of useful contribution for one to gain a reputation. However it is true that consistent attendance at IETF meetings will improve the recognition of one's technical talents, if one has those talents. Occasionally a participant has attempted to enhance his influence by declaring that his technical proposal is backed by his employer, which is an economically powerful vendor. Inevitably, this causes the person to be considered to be an idiot, and his proposal is then completely ignored. Based on this, WG chairs find it easy to ignore -- and they are *supposed* to place little weight on -- people whose contributions have little technical merit, and conversely, they pay great attention to people whose contributions consistently have technical merit. Unfortunately, these factors mean that a smaller proportion of respected contributors come from backgrounds or communities with lower levels of education or less deployment of Internet technology -- there is no mechanism, indeed, no intention, to ensure that various sectors receive equal representation. The IETF and the Internet Society have tried in various ways to reduce the barriers (especially money barriers) to participation for competent people from such backgrounds. But if there are no competent people who can be attracted to participate, that community will have no representative -- even if that community has particular technical needs which the IETF desires to satisfy. In any particular instance, if one knows of some particular technical consideration that is important for a particular community, and is having trouble getting attention in a working group for that consideration, it is useful to talk privately with various well-respected members of the working group (including the chair(s)) to ask what course of action would be best for gaining the needed attention. Listen to the feedback. If the advisers do not see the importance of the issue, consider whether it really is important, and consider how to make clearer its importance. If the advisers suggest a course of action, follow it. Because reputations are built of doing good work in a series of particular instances. Dale
Search plugins to make it easy to find IETF information
I've composed some simple web browser search plugins to make it easy to locate ITEF information. These are expressed in one of the portable search plugin formats. For Mozilla, you put these in the 'searchplugins' folder (which is ~/.mozilla/firefox/.default/searchplugins on Linux). Dale -- iana-assignments.xml searches for the given words in the IANA protocol assignments pages. It generally finds the registry for the item in question within the first few hits. SearchPlugin xmlns=http://www.mozilla.org/2006/browser/search/; ShortNameIANA assignments/ShortName DescriptionIANA protocol assignments/Description InputEncodingUTF-8/InputEncoding Image height=16 width=16 type=image/x-icondata:image/x-icon;base64,AAABAAMAEBEACABoBQAANgAAACAgAAABAAgAqAgAAJ4FAAAwMQAIAKgOAABGDgAA KBAgAQAIAHt3AABQiwAAQpUAAD6Y AABFnQMAdIUEAGqdBQBLnQYASZ0HAJVmCgCGegoATaMLAFeiDgBIjhEAUKERAFSpEgCxYhMA jXcTAHWSEwCkXBQAhYIUAJtsFQBplhYAlnQXAKNlGQCQVBsAWKQbAFqmHwB%2FVyEAXakjAJle JACZdSYAeZwmAGGqKQBUiiwAplUvAHmlLwBlYjAAlzs0AGqvNACqYjYAUGI6AG6xOgByrzsA pn1AAKdsQgCgdEcAsnpMAHq3TACNrk0AdUtOALyFTgBpYU8AnkZRAGN6UQCfhVUAg7xWAIdw WACSo1gAqFtaALZ4WgCrbV8ArpRjAHJ%2BaQCRw2kAd4hqALd5bACzuHMAvnJ5AJzKeQCnwnsA tG99AL2ChwCRiYcAqs6HAKnQigDFjY0Aw3ySAJOQkgDEkpIAzriSAL%2FKkwC%2B0ZQAn56bAMrE ngC6354Ay5efAM6jnwDUtaIAqKikAL3bpQDJk6YAsrKyAL6%2BuQDcwr0AzuW9ANy0vgDf2L4A 2sfAANHowADjr8QAxMTEANTnxADg4coA2uvNAO3c0ADe7dIA1dXVANjX1wDc29sA7tffAPDt 4ADv7%2BEA4%2BPjAOz05ADz3OYA7%2FfpAPX27AD0%2BfAA8vLyAPb78wD3%2FPUA%2Bfz3APv9%2BQD%2F7%2FsA %2FPz7AP7%2B%2FgAA AGtZSUlTZXcA bDkZJiYTExw0XAAAXR4QIzUjGBUXHzJObR4QEzs7GBUXET1EJVkAfi4QEyhH LRURCixNNwYpcWk8ExNCSB8RChRPTxYMDVNYW0w8Vj4KFAU%2BZDoHDg8%2FMy9XYGA%2BAAUSXmIa Dg4PNiwJF1huc1QgMXxGBA4ODzZQHwBhZ1F%2BfXJ5HQgODg9Bb3ZDdVIBK19%2BekULCA4OWXBD dX5KAgMnfnZ%2BajgLIncARiR4eFobMH4wQHR%2BWl0AAABAeUVacmZ6GwMaVW0AfntAAypo ejgIIWMAdEowS3p2anYA%2BA8AAOAHAADAAwAAgAEA gAEAAMADAADABwAA8A8AACggQAEACAAA AABYkQAAQZkAAGeMAQB5ewIAaZIFAEecBQBdlgYAhnkHAHCd CQB1iwwATZ8MAJBtDQCEfw0AfIUOAE%2BgDwBamxAAUKERAI14EgBTpxIAVqoSAKddEwBPmhQA qWMWAJ1rFwCUchgAbZsYAFSjGABJhxkAlFoaAFilHAB3mR4Ap1ggAE55IwCIkCgAZ6gqAKZn KwCdSC4Al28vAICcLwB4VTAAaK4yAFWDMwCffzcAmTg5AFFnOQB1rDkAjKg8AHGzPQBeSEIA mI5CAKJRSQCdRkoAqI1MAH25TgBXVU8ArGxQAHlRUQCIY1IAmrVYAKdZXwCKwGAAw5ppAG5s agCvYmsAuH1vAJbHbwCxanAAr2hyAKu5cgC0bnMAtY90AI2KdgC2dHwAfX18AMKQgQC%2BnYEA o82BALqxhQC2xoUAvHyHAImIhwDBhYwArNKNAMy0kADEjJMAucOWALTXmQDKl5oAmpqaAMvM nADOm6MA0bOjAMHbpwDUp60Ara2tAMPfrgDWqbMA27O5AN%2FSvADR5b8A37nBAMnIxwDZ58gA 5MfKAOfdzADpz9QA1tbWAObu2QDs2doA8dTeAPHf4wDr9OMA9OPoAOrq6QDz9%2B0A%2BPXxAPX6 8QD57vIA9fX1APj79QD98vkA%2Bvr5APr9%2BQD9%2BPsA%2FP37AP%2F%2F%2FwAA AAB2al5eWFhYXl5sdgAA AAB2ZVA%2BMDAwMDA2Nj5YZXwAZT4nHCQrKysfFhQcJzY2SWUA dkknFBYfKysrJBQUFhYXFxg2Nlh2AHE5FBYUFCQzMzMf FBYXFxcYGCU4NklxAABxJxYUFBQfMjMyMhQWFxcXGBgYNz87NklxdjkW FBQUFDI7OzsfFxcXFxgYESVDP0U5NlB5AABHFhQUFBQfOz87NxcXFxgYGAwRRUVFRSEg Nl4AZRQUFBQUFDc%2FQkUjFxcYGBERDDdPSE80AggsPnEqFBQUFBQfRUhINxcYGBgR DAwqUU9RRgQEDxU2WAAAYjcUFBQUFCNPT08qFxgREQwMDUZUVFchBg8PEyA%2BcQBXT0AjFBQW QFFUQBgYEREMDA0xWldaRgYPDxAaFTZlc1RRVFRAIxdUV1c0CxEMDAwNCUtdXV0mChAQEBAS LFhoSlpXV1pXSlpaWioHDAwNDQkxYWFhTQoQEBAQEBIgUFMWN1pgXV1gXWFLBwwMDQ0JAk1n Z2ciChAQEBAQEhtJPRQWI0ZhZGFkZFsxAw0JCQIeZ2ltVQUQEBAQEBASG0k9FhcXCypTZ2dn
Re: Call for Comment: RFC Format Requirements and Future Development
From: t.p. daedu...@btconnect.com The result was 32kbyte, ie the formatting used by another SDO had increased the size 16-fold, a 16-fold increase in network traffic, a 16-fold increase in the storage needed for as long as the document was stored. Repeat this across the IETF's I-Ds and the ability to produce RFCs would be substantially reduced. Certainly larger formats are less desirable than smaller formats. But since RFC 1000 (1987), the size of disk drives has increased over 1000-fold (http://en.wikipedia.org/wiki/File:Hard_drive_capacity_over_time.png), and communication speeds have also increased greatly. So size increases of a factor of 10 over periods of decades is unlikely to reduce our ability to work. Dale
Re: Internet Draft Final Submission Cut-Off Today
From: Stefan Winter stefan.win...@restena.lu [...] ferkakte [...] As a German, I'm now torn apart between being flattered that we've successfully exported a German word to the U.S. and being speechlessly shocked by the way spelling was b0rked in the process. Given that the word is Yiddish, and therefore has been transliterated from the Hebrew alphabet (in which Yiddish is written) into the Latin alphabet, you can blame the problem on incorrect internationalization... Dale
Re: Internet Draft Final Submission Cut-Off Today
From: James Polk jmp...@cisco.com It used to be 5 PM Pacific, now it's 24:00 UTC. It's always been 2400 UTC, but with all the daylight savings time adjustments from country to country changing from year to year, I have talked to the Secretariat before (and recently), and verified this is indeed 8pm ET, at least for those in the US. Well, 2400 UTC is 8pm Eastern Daylight (i.e., summer) Time (GMT-4), but 7pm Eastern Standard Time (GMT-5). So I'd ask *when* did the Secretariat tell you that? Personally, I'd trust date -u much sooner than any random person. Even better: $ date --date='00:00 Feb 26, 2013 UTC' Mon Feb 25 19:00:00 EST 2013 $ Dale
Re: Internet Draft Final Submission Cut-Off Today
From: m...@sap.com (Martin Rex) I have a recurring remote participation problem with the IETF Meeting Agendas, because it specifies the time of WG meeting slots in local time (local to the IETF Meeting), but does not give the local time zone *anywhere*. I would appreciate if the local time zone indication would be added like somewhere at the top of the page, to each IETF meeting agenda. I would be nice to have local time zone information. But in a pinch, you can google Time in Orlando to get the answer. As for date --date='...', well, ye shall know the workman by his tools. Dale
Re: IETF chair's blog
From: Brian Trammell tramm...@tik.ee.ethz.ch It does not seem appropriate for a technical standards organization dedicated to making the Internet work better through the development of open standards to implicitly endorse communication protocols which are based on closed access to distributed databases through interfaces that can and do change at the whim of the organizations that control them, further where those organizations have demonstrated a willingness to assert editorial control over the content they disseminate. First, let me add my cynical definitions: Collaborate is when I listen to you. Public relations is when *you* listen to *me*. Let us use these terms correctly (as opposed to most usage in the business world). In regard to platforms, I'm torn, because the current crop of commercial social media is a good technique of doing PR and no doubt would help the IETF generate public awareness. On the other hand, having a major sector of social interaction be operated on a completely closed platform operated by an organization with completely commercial purposes is *exactly the opposite* of what the IETF is attempting to accomplish. Dale
Re: draft-gellens-negotiating-human-language-01
(It's not clear to me what the proper mailing list is to discuss this draft. From the headers of the messages, it appears that the primary list is ietf@ietf.org, but the first message in this thread about that draft already has a Re: in the subject line, so the discussion started somewhere else.) (Also, it's not clear why Randall's messages are coming through in HTML.) But onward to questions of substance: - Why SDP and not SIP? I'd like to see a more thorough exploration of why language negotiation is to be handled in SDP rather than SIP. (SIP, like HTTP, uses the Content-Language header to specify languages.) In principle, specifying data that may be used in call-routing should be done in the SIP layer, but it's well-accepted in the SIP world that call routing may be affected by the SDP content as well (e.g., media types). And some discussion and comparison should be done with the SIP/HTTP Content-Language header (used to specify the language of the communications) and the SIP Accept-Language header (used to specify the language of text components of SIP messages), particularly given that Accept-Language has different set of language specifiers and a richer syntax for specifying preferences. In any case, preference should be given to reusing one of the existing syntaxes for specifying language preferences. - Dependency between media descriptions? Another example would be a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus a text stream (known as voice carry over). Making language a media attribute allows the standard session negotiation mechanism to handle this by providing the information and mechanism for the endpoints to make appropriate decisions. This scenario suggests that there might be dependency or interaction between language specifications for different media descriptions. Whether this is needed should be determined and documented. - Specifying preference levels? For example, some users may be able to speak several languages, but have a preference. This might argue for describing degrees of preference using q parameters (as in the SIP Accept-Language header). - Expressing multiple languages in answers (While it is true that a conversation among multilingual people often involves multiple languages, it does not seem useful enough as a general facility to warrant complicating the desired semantics of the SDP attribute to allow negotiation of multiple simultaneous languages within an interactive media stream.) Why shouldn't an answer be able to indicate multiple languages? At the least, this might provide the offerer with useful information. - Reusing a=lang Searching, I can only find these descriptions of the use of a=lang:...: RFC 4566 draft-saintandre-sip-xmpp-chat draft-gellens-negotiating-human-language So it looks like a=lang:... is entirely unused at the present and is safe to be redefined. Dale
Re: I-D affects another or work in ietf groups
From: Abdussalam Baryun abdussalambar...@gmail.com 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, If you are reviewing a document as an individual, you are free to consider its interactions with anything that you consider relevant. As you say, as much as I can to make the Internet better. If you have been given a specific duty when reviewing a document, then that duty may prescribe what interactions you should be considering. In any case, if you are doing something incorrect in your review, presumably people will call your attention to that fact, and explain how you should change what you are doing and why you should change it. Dale
Re: The RFC Acknowledgement
From: Abdussalam Baryun abdussalambar...@gmail.com 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. Hi Abdussalam, I believe that you are examining this problem from the point of view of a reviewer (and possible contributor) to a document, rather than the point of view of a document author. That is, your question is When can I expect a document author to include an Acknowledgment of my review? In practice, that depends on the judgment the document author; does the document author feel that you have made a significant contribution to the document? In general, even if an outside observer would say that you contributed significantly to a document, it can appear impolite to explicitly request that your name be added to the Acknowledgments section. A participant that still did not complete a year working for IETF, but trying to continue :) My belief is that one must participate in the IETF fairly intensively for six months to a year before one can gain a reputation as being a knowledgeable contributor. After all, most of the people authoring documents have been participating for several years -- and they already know each other. Before you have gained that reputation, it may be difficult to get people to pay attention to your contributions, even if they are objectively valuable. I describe the rule in the IETF as Everyone may speak; not everyone is listened to. You need to prove yourself to be a person worth listening to. Much useful advice on this subject is contained in RFC 4144, How to Gain Prominence and Influence in Standards Organizations. My experience is that one can learn how to get more respect in an organization by occasionally asking more experienced people how to do so. One method that works in most organizations is to volunteer for the thankless tasks. In any organization, there are tasks that are acknowledged as necessary, they are unpleasant to do, and people who do it are not rewarded commensurately for doing them. (Reviewing drafts is one of them in the IETF.) However, if you develop a reputation as a person who does these tasks, it will increase the respect you receive. Dale
Re: CRLF (was: Re: A modest proposal)
From: John Day jeanj...@comcast.net Multics was based on EBCDIC which had a New Line (NL) character but no CR or LF. The ARPANET went with the ASCII standard. But I never forgave the ANSI committee for taking left arrow out of the character set (as a replacement operator). Which suggests that the reason Unix used LF as newline was because Unix was consciously based on Multics, and Multics had a newline but no carriage return or line feed. Dale
Re: A modest proposal
A great deal of complexity comes from the fact that standards are rarely created in a vacuum. In this case, RFC 3261 SIP had to be upward-compatible from RFC 2543 SIP. And the early design of RFC 2543 SIP was influenced (I am told) by the idea that SIP messages should be able to go through HTTP proxies. (That didn't work out, but the idea is less silly than it seems, especially if you are contemplating organizations whose only permitted outside net traffic goes through HTTP proxies...) So, much of the SIP header formatting was taken from HTTP, which got it from RFC 822 e-mail message formatting. And of course, once a variation is permitted, you *can't take it out*, because some product with significant market share depends on it. There is also the necessity to allow for extensibility, which favors the use of various sorts of separators rather than a fixed sequence of fixed-length fields. As for CR-LF, that is conformity to the ASCII standard by RFC 822, where CR stands for carriage return and LF stands for line feed. Exactly why those functions were given separate control characters I don't know, but I suspect it was to allow overstriking. The CF-LF standard was largely followed back in 1982, especially in Digital Equipment Corporation systems, which were the backbone of the Arpanet. So CR-LF remains the conventional line ending in Internet protocols. The use of LF alone seems to come largely from the Unix lineage of systems. There is also a strong tendency to favor protocols that are readable and writable by humans as text strings (among other things, that makes debugging easier), so formatting alternatives are added to make those tasks easier. Dale
Re: Vestigial Features (was Re: CRLF (was: Re: A modest proposal))
From: Carsten Bormann c...@tzi.org I think in protocol evolution (as well as computer system evolution in general) we are missing triggers to get rid of vestigial features. That's quite true. Let us start by rationalizing the spelling and punctuation of written English (which is the coding system for *this entire discussion*). Once we've cleaned up that idiocy, we can start in on SIP. Dale
Standards-essential patents under RAND licensing
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
Re: Hello ::Please I need to know LEACH protocol standard???
I am a researcher of Master's degree , working on LEACH routing protocol for wireless sensor networks and i need to know for which standard does LEACH , its family ,or even Layer 3 belong to. A Google search suggests that LEACH has not been standardized. LEACH appears to have been invented by academics; several papers have been published about it. In regard to layer 3, see http://en.wikipedia.org/wiki/OSI_model Dale
Re: Acoustic couplers
From: Steve Crocker st...@shinkuro.com I honestly don't remember whether the plugs were the clunky four pin or the then-modern RJ11. I recall studying RJ11 and RJ45 plugs and sockets at some point and discovering that some plugs and sockets had six wires instead of only four or two. I never did learn if they had a different number. The form factor was the same. Wikipedia has a long list: http://en.wikipedia.org/wiki/Registered_jack It's probably not complete. Dale
Re: WCIT outcome?
From: John Day jeanj...@comcast.net No, there was nothing illegal about it. The reason for acoustic couplers was that the RJ-11 had been invented yet and it was a pain to unscrew the box on the wall and re-wire every time you wanted to connect. In the 1970s, in the US, and for inter-state use, you either had to rent the modem from the phone company, or rent a data-access arrangement device to connect your modem to the network. The DAA cost about as much as the modem, so there was little in the way of independent modems. Acoustic couplers got around that rule. Also, in those days, there was a large four-pronged plug that could be used for phones. It was sometimes used when people wanted to move phones around. http://en.wikipedia.org/wiki/File:4prongplug.JPG Dale
Re: WCIT outcome?
From: John Day jeanj...@comcast.net No, there was nothing illegal about it. The reason for acoustic couplers was that the RJ-11 had been invented yet and it was a pain to unscrew the box on the wall and re-wire every time you wanted to connect. In the 1970s, in the US, and for inter-state use, you either had to rent the modem from the phone company, or rent a data-access arrangement device to connect your modem to the network. The DAA cost about as much as the modem, so there was little in the way of independent modems. Acoustic couplers got around that rule. Also, in those days, there was a large four-pronged plug that could be used for phones. It was sometimes used when people wanted to move phones around. http://en.wikipedia.org/wiki/File:4prongplug.JPG Dale
Last call comments on draft-ietf-bliss-call-completion-18.
My apologies for dealing with this earlier. I've been neglecting this
draft.
Fundamentally, I think the draft is in great shape. The only
significant change is that I think a summary of the retain option
procedures and considerations should be added so the reader can see
how it affects the procedures (and how gateways to the PSTN handle
retain).
Only items 2 and 19 have technical content; the remainder are
editorial. Item 2 is a request to insert a short section summarizing
the retain option processing. The relevant information is scattered
throughout the draft and it could be difficult for an implementer to
find all the fragments that are relevent. Item 19 is probably an
editing error, but currently the ABNF doesn't match the text.
item 1) headers
Can you abbreviate my affiliation on the front page to Ariadne? I
you are using XML2RFC, you can use the 'abrev' attribute of the
organization element:
organization abbrev='ISI'
USC/Information Sciences Institute
/organization
item 2) overall
The procedures regarding the retain option are scattered throughout
the document in a way that makes it difficult to see how it is
handled. It seems to me that it would be helpful to add a summary of
retain option processing as a section, perhaps at the end of section
4. This allows deleting the last paragraph of section 4.2, which is
vague when it stands alone.
4.5 Summary of retain option procedures
When the call completion call fails there are two possible options:
the CC feature has to be activated again by caller's agent
subscribing to callee's monitor, or CC remains activated and the
original CC request remains in the queue.
If the callee's monitor operates in the latter way, it is said to
support the retain option. Callee's monitors SHOULD support the
retain option. If a monitor supports the retain option, it SHOULD
provide the cc-service-retention header in its call-completion
events. The caller's agent can use this header to know that this
monitor supports the retain option.
If a callee's monitor does not support the retain option (e.g., if
it is a gateway to a network device whose CC functionality does not
support the retain option), it SHOULD NOT provide the
cc-service-retention header. In addition, after a failed CC call
that causes the CC request to be deleted from the queue, the
monitor MUST terminate the corresponding agent's subscription to
inform the agent that its CC request is no longer in the queue.
After a failed CC call, the caller's agent MAY terminate its
subscription, to inform the monitor that it is terminating its CC
request. After a failed CC call, the caller's agent MAY receive a
termination of its subscription from the callee's monitor, if the
monitor has terminated the agent's CC request. In either case, the
agent MAY create a new subscription (as described in section 6.2)
to create a new CC request for the same original call. The agent
SHOULD avoid terminating one subscription and creating a new one if
the caller's monitor has indicated support of the retain option.
I have used SHOULD to describe procedures which are desirable but are
not required for correct functioning. In particular, the
cc-service-retention value does not have to be correct for a
properly-implemented agent and monitor to interact correctly. This
gives us some freedom in situations where a gateway cannot discern
accurately whether the callee supports the retain option or not.
Pure SIP agents and monitors can implement all the SHOULD behaviors,
so in the pure-SIP case, CC is done with the retain option.
item 3) section 4.1
The callee's monitor maintains information about the set of INVITEs
received by the callee's UA(s) considered unsuccessful by the caller.
Strictly speaking, the monitor can't know if an INVITE is considered
unsuccessful by the caller. This wording might fix that:
The callee's monitor maintains information about the set of INVITEs
received by the callee's UA(s) that the caller might consider
unsuccessful.
item 4) section 4.2
The callee's monitor
keeps a list or queue of the caller's agent's subscriptions,
representing the requests from the caller's agent to the callee's
---^
should be agents
monitors for call-completion services.
--^
should be monitor
item 5) section 4.2
When the callee's monitor determines the callee and/or callee's UA
insert are here
available for a CC call, it selects a caller to execute the CC call
and sends a call-completion event update (''cc-state: ready'') via a
-^^
this should probably use rather than ''
NOTIFY request to the selected caller's agent's subscription, telling
it to begin the CC call to the callee's UA.
item 6) section 4.2
When the call completion call fails there are two possible
Re: Newcomers [Was: Evolutionizing the IETF]
Responses to a couple of points that people have made: From: t.p. daedu...@btconnect.com I started, some years ago, with a meeting, because the culture that I was used to was that conferences, be they annual or triannual, were where things really happened and that e-mail filled in the gaps in between (and I think that this remains the case in other, related, fora). That attendance showed me that most of the IETF meeting was a waste of time, that it was e-mail that was the main vehicle for work, and I think that the IETF web site has it about right when it says This is all true. Any decision come to during a meeting session must be reviewed and approved on the WG mailing list. The reason for this is to ensure that one can participate completely *without* attending the meetings and paying the associated expenses. From: Carlos M. Martinez carlosm3...@gmail.com The feeling I kept receiving here is that there is a kernel of IETFers who still believe that IETF is some kind of ivory tower that exists by itself, for itself and is self-sufficient. First, I think you are not using the correct term. Ivory tower is used specifically to mean an excessively academic or theoretical approach. In the IETF's case, it is considerably more practical and hands-on than other organizations. In particular, contrast can be drawn with the ITU's OSI networking protocols. I think a better term for the concept is insular, meaning isolated or island-like. The IETF is one more component of the complex ecosystem of Internet governance. However, I think you are correct in that the IETF is insular, that it does not concern itself much with other parts of the ecosystem of Internet governance. Partly this is historical, in that there wasn't much Internet governance when the IETF was founded. And for a long, formative period (15 years or so), the only other global element of the networking world was the ITU's OSI effort, which was directly competitive. But to a considerable degree, the IETF confines itself to aspects of networking which do not greatly intersect with Internet governance. We design and implement protocols. The connection with the larger ecosystem is more done by the Internet Society. - What is a reasonable goal in terms of participation, so that having a meeting in Latin America is actually meaningful?: X attendees from the region and Y people actively participating in mailing lists and contributing text Success can probably be judged simply by attendance numbers -- does the meeting have an attendance at least as large as meetings in more traditional places (within statistical error)? - After that, set the goal: The IETF will hold a meeting in Latin America in the next four to five years - What does the IETF to do that?: The IETF needs partners to pledge X $ in sponsorship funds, or whatever else. As far as I can tell from others' postings: A venue needs to be found that has adequate space and tolerance of our networking needs. Sponsors need to be found to cover the costs that the standard meeting fee will not cover. The typical attendee budget (air fare, hotel, meeting) needs to be no higher than in traditional locations. (This can probably be ensured with sufficient sponsor support.) Air travel to the location should not be substantially longer or inconvenient than to traditional locations (because employers consider employee's time to be more expensive than direct expenses). Dale
Re: Newcomers [Was: Evolutionizing the IETF]
From: Mikael Abrahamsson swm...@swm.pp.se Well, it's hard to say what caused an email I sent (new thread, pitching idea, asking if it was relevant to the WG) to not get responded to. Perhaps it was irrelevant or uninteresting but nobody wanted to say so. I don't know, if I don't get a response, I tend not to push the issue. The operational rule in the IETF is Everyone may speak. Not everyone is listened to. More or less by definition, your message was uninteresting. The question is why was it considered uninteresting. One way to find out would be to send private messages to respected people in the WG and ask what they think of the idea. (socializing the idea) Of course, they might not answer either. One way to build up enough credibility to get respected people to answer you is to do thankless jobs. In most WGs, there are never enough people who are willing to read and provide detailed critiques of drafts. (And believe me, almost all drafts need significant improvements of their presentation, and often of the technology.) And the quality of your critiques of drafts is a good way to demonstrate your technical skills. Dale
Re: Newcomers [Was: Evolutionizing the IETF]
From: Arturo Servin arturo.ser...@gmail.com Your comment just reinforce my perception that the IETF is not interested in being an global organization of standards. People is asking how to evolve the IETF, well, one possibility is to start thinking global and to reach more people outside the common venues. It is more expensive, more complex, yes. But in my opinion is worthy if we really want to show that we care about the multistakeholder model that we preach. In my opinion, the *location* of IETF meetings is not important for the technological openness of the standards, but it *is* important for its *symbolism*. My observation is that members have been supportive of attempts to hold IETF meetings in diverse locations, but there are constraints that limit the locations that are practical. I am in no way involved with IETF site selection, but based on the extensive discussions of site selection on this mailing list, the constraints seem to be as follows. The list suggests some things that individuals can do to help find suitable locations, which I've listed at the end. The meetings require a certain number of hotel rooms, a fairly large array of meeting rooms, and large common spaces, in one or a small cluster of hotels. (These arrangements are fairly easy to find in North America and Europe, but are much less common in the rest of the world.) The hotel has to be willing to allow the IETF to install its wireless network and to take control of the hotel's Internet connectivity. Members desire locations that offer tourism possibilities, which generally means that the meeting site is in or near a city center. Because IETF participation is not of immediate commercial value to the employers of most participants, cost is of significant concern. In practice, the cost and availability of air transportation seems to be the most variable factor, and the less international traffic to a given location, the more expensive air fares seem to be. (You can explore the available air fares at http://matrix.itasoftware.com/search.htm.) The meeting fees cover only part of the meeting costs, so it is necessary to find sponsors to pay the remainder of the costs. The sponsors usually are associated with the meeting location in some way. Since finding sponsors is difficult, meeting locations are harder to set than meeting dates. What an individual can do to encourage selecting a particular location is to find hotels that have the necessary meeting spaces. If possible, it would be helpful to determine that the management would be willing to let the IETF take over their network. Most importantly, a local individual can find local sponsors for the meeting. Dale
Re: IAOC Request for community feedback
There seems to me to be a constitutional issue that has not been addressed, and may well bedevil us in the future: In any collective body, there is a concept of a quorum, which is set high enough to ensure that the actions of any meeting represent the opinions of the body as a whole, and which is set low enough that the expected level of absences will not prevent business from being done. The current crisis is (apparently) due to the chronic absence of *one* member causing *chronic* failures of the IAOC to achieve a quorum. This suggests to me that the quorum of the IAOC is too high to allow it to reliably conduct business -- after all, any of a thousand accidents can cause one member to be absent for a long period of time. What are the quorum rules of the IAOC? Should they be revised? Dale
