Re: Community Feedback: IETF Trust Agreement Issues
Chris I would not like to see the Trust Agreement change to accommodate issues one or two - I think that the agreement got that one right. Three is different. The Trust ought to be able to dispose of rights that are not needed, never will be and are costing money. But how can that be expressed without giving carte blanche to dispose of everything, for whatever purposes? We need a proposal as to how that line would be drawn - I do not have any sound ideas on this. Can you indicate what annual or one-off costs we are talking about? The domain names I have dealt with have been cheap enough not to be concerned about, once I found the best way to deal with them, although I understand that the IETF is operating in a different realm and so may have costs of a different magnitude. Tom Petch - Original Message - From: Chris Griffiths cgriffi...@gmail.com To: ietf@ietf.org Sent: Saturday, August 03, 2013 7:48 AM IETF Community, The IETF Trust Trustees would like feedback from the community on several issues: - We have received requests that we cannot accommodate and have consulted legal counsel to review our options - The trust agreement does not allow the trustees to effectively manage some trust assets The Trust was created in December 2005 by the Internet Society and the Corporation for National Research Initiatives (CNRI) for the purpose of the advancement of education and public interest by acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology. http://trustee.ietf.org/docs/IETF-Trust-Agreement-Executed-12-15-05.pdf Issue 1 We have recently been asked permission to republish the TAO with a creative commons license, but according to counsel, the current trust agreement does not give the trustees the rights to do this. - Without specific language being added to the trust agreement, we cannot grant these types of requests. - The current open request for a creative commons license from 6/18/2013 cannot be completed. Issue 2 We cannot currently accept physical assets like hardware donations into the trust. Once accepted into the trust, we would be unable to dispose of these items in the future if they are identified as no longer being needed. - This removes flexibility in managing assets in the trust, and we currently use alternative methods of accepting donations outside of the trust. Issue 3 Once a domain name or trademark is registered by the trust, it cannot be abandoned even if it is no longer needed. - We must maintain these in perpetuity based on legal counsel review of the current language You can also find the latest trust report that covers these items and was presented at the IETF 87 plenary here: http://www.ietf.org/proceedings/87/slides/slides-87-iesg-opsplenary-4 Thank you and we look forward to getting your feedback. Chris Griffiths Chair, IETF Trust
Re: procedural question with remote participation
Hi Keith, Thanks for clarifying. Put that way I agree 100%. -Andrew On 08/06/2013 02:03 PM, Keith Moore wrote: On 08/06/2013 11:06 AM, Andrew Feren wrote: On 08/06/2013 09:08 AM, Keith Moore wrote: On 08/04/2013 02:54 PM, Ted Lemon wrote: While I think getting slides in on time is great for a lot of reasons, reading the slides early isn't that important. What is important is that remote people see the slides at the same time as local people. For that, it seems to me that Meetecho support does exactly what is needed. You just follow the slideshow online, along with the audio. I agree that remote people should see the slides at the same time as local people, except that I think that in both cases this should be well before the meeting. The slides shouldn't be shown at the meeting unless needed to illustrate a point of active discussion. People keep acting as if the purpose of these meetings - the reason people spend thousands of euro and travel thousands of km - is to watch slides. Hi Keith, I think this sort of misses the point. At least for me as a remote participant. Actually I think the desire to get slides out early largely misses the point. Or at least, it's an effort optimizing what should be the rare case. I fully agree that slides should be easily available to both local and remote participants well prior to any meeting in which a presentation will be made. (Say a plenary session where presentations are normal and appropriate.) While speakers might like to revise their slides at the last minute, there's no reason why they shouldn't be expected to upload preliminary slides well in advance (because the key to an effective presentation is good preparation, after all) and a revised version (if necessary) later. This isn't at all rocket science, and there's no reason why it should not be done. But if we really want to make remote participation effective, we need to figure out better ways to involve remote participants in _discussions_ - not only in plenaries, WG meetings, BOFs, etc., but also in hallway and bar conversations. Having a local speaker read something from a laptop that was typed into a Jabber session by a remote participant is better than nothing. But surely we can do better. As of today when the slides are available (or if there are no slides and just talk) I can follow WG meetings quite well. Being able to actively engage in any discussion remotely is, IMO, pretty much limited to the mailing lists. Getting involved in an active discussion at a WG meeting remotely is currently difficult at best and impossible at worst. It used to be the case that Internet access at IETF meetings was flaky, either because of the wireless network or because of the network connection or both. More recently the performance of the meeting Internet access has been stellar. If we put the same kind of effort into facilitating remote participation in discussions, I suspect we could move from difficult at best and impossible at worse to works well. Of course, it might take awhile, but it's those very kinds of discussions that are so essential to broad consensus that (when it works) makes our standards effective. The fact that it doesn't work well now is not a good argument for not making it work well in the future. (We're supposed to be creating the future, after all. That's our job.) It's also the case that the fact that facilities for involving remote participants in conversation haven't historically worked well, is used as a justification for continuing to have this dysfunctional style of conducting working group meetings, thus making very poor use of local participants' time and money. I'm all for making presentation slides available to local and remote participants well before the meeting. But if we're only concerned with making presentation slides available, we're selling ourselves very short. That's the point I'm trying to make. Keith
Re: procedural question with remote participation
--On Tuesday, August 06, 2013 11:06 -0400 Andrew Feren andr...@plixer.com wrote: ... I think this sort of misses the point. At least for me as a remote participant. I'm not interested in arguing about whether slides are good or bad. I am interested in following (and being involved) in the WG meeting. When there are slides I want to be able to see them clearly from my remote location. Having them integrated with Meetecho works fine. Having slides and other materials ... Let me say part of this differently, with the understanding I may be more fussy (or older and less tolerant) than Andrew is... If the IETF is going to claim that remote participation (rather than remote passive listening/ observation with mailing list follow up) is feasible, then it has to work. If, as a remote participant, I could be guaranteed zero-delay transmission and receipt of audio and visual materials (including high enough resolution of slides to be able to read all of them) and that speakers (in front of the room and at the mic) would identify themselves clearly and then speak clearly and at reasonable speed, enunciating every word, I wouldn't care whether slides were posted in advance or not. Realistically, that doesn't happen. In some cases (e.g., lag-free audio) it is beyond the state of the art or a serious technical challenge (e.g., video that is high enough resolution that I can slides that have been prepared with 12 point type). In others, we haven't done nearly enough speaker training or it hasn't been effective (e.g., people mumbling, speaking very quickly, swallowing words, or wandering out of microphone or camera range). And sometimes there are just problems (e.g., intermittent audio or video, servers crashing, noisy audio cables or other audio or video problems in the room). In those cases, as a remote participant, I need all the help I can get. I'd rather than no one ever use a slide that has information on it in a type size that would be smaller than 20 pt on A4 paper. But 14 pt and even 12 pt happen, especially if the slides were prepared with a tool that quietly shrinks things to fit in the image area. If I'm in the room and such a slide is projected, I can walk to the front to see if if I'm not already in front and can't deduce what I need from context. If I'm remote and have such a slide in advance, I can zoom in on it or otherwise get to the information I need (assuming high enough resolution). If I'm remote and reading the slide off video, especially low resolution video, is hopeless. More generally, being able to see an outline of what the speaker is talking about is of huge help when the audio isn't completely clear. Others have mentioned this, but, if I couldn't read and understand slides in English easily in real time, it would be of even more help if I had the slides far enough in advance to be able to read through them at my own pace before the WG session and even make notes abut what they are about in my most-familiar language ... and that is true whether I'm remote or in the room. And, yes, for my purposes, 48 hours ahead of the WG meeting would be plenty. But I can read and understand English in real time. If the IETF cares about diversity as well as about remote participation and someone whose English is worse than mine is trying to follow several WGs, 48 hours may not be enough without requiring a lot of extra effort. That is not, however, the key reason I said a week. The more important part of the reason is that a one-week cutoff gives the WG Chair (or IETF or IAB Chairs for the plenaries) the time to make adjustments. If there is a nominal one week deadline, then the WG Chair has lots of warning when things don't show up. She can respond by getting on someone's case, by accepting a firm promise and a closer deadline, by finding someone else to take charge of the presentation or discussion-leading, or by rearranging the agenda. And exceptions can be explained to the WG on the mailing list. With a 48 hour deadline, reasonable ways to compensate are much less likely, the Chair is likely to have only the choice that was presented this time (accepting late slides or hurting the WG's ability to consider important issues) and one needs to start talking about sanctions for bad behavior. I would never suggest a firm one week or no agenda time rule. I am suggesting something much more like a one week or the WG Chair needs to make an exception, explain it to the WG, and be accountable if the late slides cause too much of a problem. There is some similarity between this and the current I-D cutoff rule and its provision for AD-authorized exceptions. That similarity is intentional. --On Monday, August 05, 2013 13:36 -0500 James Polk jmp...@cisco.com wrote: At 12:38 PM 8/5/2013, John C Klensin wrote: Hi. I seem to have missed a lot of traffic since getting a few responses yesterday. I think the reasons why slides should be available well in advance
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
The point is that there would BE discussion. Consensus is not enough, the process has to be open. A consensus formed by keeping people out of the room is no consensus at all. Though if the discussion was of the form 'this was already decided' then that effort would be a farce as well. What we need for 90% of IETF specifications is nothing more than an easy way to extend JSON to encode binary blobs without BASE64 encoding. Just that, nothing more. Instead we have a reinvention of ASN.1 without a schema. When I say nothing more, I don't mean the rest would be 'nice to have' or harmless, I mean that it is positively harmful. I want to be able to mix binary and text forms of the JSON encoding in the same object. For example, we have part A that collects JSON datagrams from B and C and puts a wrapper round them. This is a very common requirement in a network protocol (and one of the things that XML was meant to do but is horrible at). If we can mix and match Text/Binary JSON this is very simple, the packager can just include the input from B and C into its output stream as opaque blobs without having to decide whether to convert them to make the inner format compatible with the outer wrapper or each other. The way that we normally decide issues as important as a data encoding format is to have an open competition where multiple proposals can be made by anyone with an idea. That is how W3C managed the binary encoding of XML and how the HTTP 2.0 compression issue is being addressed. The process for CBOR has been that Carsten writes a spec and then Paul Hoffman acts as Czar deciding which requirements are to go in it. At any rate, I have an open source tool on source forge now that generates an Internet Draft, Examples and sample code from a simple abstract schema. It currently uses JSON coding but I will be adding a binary encoding, hence my interest. I would be happy to add an IETF Proposed Standard binary encoding that had been the result of an open process. On Wed, Aug 7, 2013 at 4:28 AM, Murray S. Kucherawy superu...@gmail.comwrote: On Wed, Aug 7, 2013 at 1:03 AM, Barry Leiba barryle...@computer.orgwrote: Using the individual submissions track as a way to circumvent working group process when there is an actual IETF JSON working group seems completely wrong to me. No one is circumventing anything. The JSON working group is not chartered to deal with this or other documents like it, and we won't be rechartering it to do so any time soon. And remember that any time I'm sponsoring a document as AD, part of what I'm doing is what working group chairs do in a working group: judging rough consensus on the document's content and the issues that concern whether it's intended status is appropriate. If you (and/or others) can show that there are solid reasons that this should not be a Proposed Standard, or if I do not see rough consensus to publish it, I will not bring it to the rest of the IESG. I would add that CBOR has already seen enough interest and feedback that I believe it would pass a call for adoption in APPSAWG, and be processed there onto the standards track. That would make Barry's job quite a bit easier, since it would then be our job to host the discussion and record consensus in that context. It would also get a shorter IETF Last Call. Instead, it's going what is for all intents and purposes a tougher route. I'm not suggesting we derail its progress to do it the other way, but it does suggest to me that the route it's following is hardly a shortcut or bypass of some kind. -MSK -- Website: http://hallambaker.com/
Re: procedural question with remote participation
Well, I've worked remotely for 16 years and in most meetings I don't get to see the slides until the meeting starts. Usually I can only see them via some conferencing tool. Sometimes I get a copy in mail the week after. So I think the IETF is already doing pretty well at making materials available, and insisting on getting slides far in advance of the meeting is beyond what most people get in reality outside of the IETF. I would call this a SHOULD not a MUST.
Re: [TLS] Last Call: draft-ietf-tls-oob-pubkey-09.txt (Out-of-Band Public Key Validation for Transport Layer Security (TLS)) to Proposed Standard
On 02/08/2013 08:23, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Out-of-Band Public Key Validation for Transport Layer Security (TLS)' draft-ietf-tls-oob-pubkey-09.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-08-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a new certificate type and two TLS extensions, one for the client and one for the server, for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation. Hi, I just read the document and support its publication. I think I found one minor issue: Section 4.1 says: In order to indicate the support of out-of-band raw public keys, clients MUST include the 'client_certificate_type' and 'server_certificate_type' extensions in an extended client hello message. The hello extension mechanism is described in TLS 1.2 [RFC5246]. In Section 5 (the first example): client_hello, server_certificate_type=(RawPublicKey) - // [1] So it looks like the example doesn't comply with the MUST requirement in the Section 4.1 (client_certificate_type is missing) or the requirement stated in Section 4.1 is incorrect. I suspect you meant 'client_certificate_type' and/or 'server_certificate_type' in Section 4.1. Best Regards, Alexey
Re: procedural question with remote participation
On 8/8/2013 7:53 AM, Scott Brim wrote: Well, I've worked remotely for 16 years and in most meetings I don't get to see the slides until the meeting starts. Usually I can only see them via some conferencing tool. Sometimes I get a copy in mail the week after. So I think the IETF is already doing pretty well at making materials available, and insisting on getting slides far in advance of the meeting is beyond what most people get in reality outside of the IETF. I would call this a SHOULD not a MUST. suspect Scott's experiences matches that of many of us, but let's consider possible sampling bias here, which might limit the applicability of that experience to the IETF... There is a difference between being a native English speaker who is already integrated into an on-going work effort, versus someone who might be neither, as is often true for IETF meetings. Informative slides that are available ahead of time can be extremely helpful, for establishing the context of the presentation/discussion and for outlining the main points. For someone new to a topic or with language limitations, that can make the difference between understanding the flow of speech, versus not. So let's be careful about whether slides ahead of time need to be a requirement, rather than being considered only a nice-to-have. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Models of building platform standards
The situation with CBOR illustrates a difference of design philosophy that I think is of much wider relevance. Consider the normal process of engineering design: 1) Use use cases to develop requirements 2) Perform triage on requirements to focus on most important ones and 3) Implement 4) Test, if necessary return to 1, 2, 3 What makes platform standards different is that the criteria for performing triage are very different. In normal engineering the engineer talks to the product manager and puts a dollar cost on each of the various features the product manager asks for. Which is often guesswork but the engineer is the person who will suffer if the guess is wrong. [If the engineer works for Dilbert's boss, it is the pointy haired one who makes the commitments] In platform engineering the ultimate use of the platform is unknown and so triage is not driven by a cost/benefit analysis in the same way. So what tends to happen is that Working Groups attempt to limit the requirements to the absolute minimum in order to make the specification as simple as possible. The unfortunate fact is that this frequently produces the exact opposite outcome. PKIX is a very complex standard because it has grown to meet requirements organically. As a result it has three certificate issue protocols, two mechanisms for revocation and still lacks a standardized discovery protocol. When I was asked to design a successor for PKIX in XML back in 2000, I implemented every feature of PKIX in a 20 page spec. The spec later formed the basis for the assertion layer in SAML and XKMS where they did get larger, but nowhere near as large as PKIX. So I think the approach is broken. Instead of trying to do triage by limiting use cases and requirements before considering design alternatives we should instead rank them. So no use case that meets a minimal criteria of plausibility is rejected but it is understood that the final design need not cover all the use cases. The reason for taking this approach is that having to deal with a large number of requirements forces people to consider a higher level of abstraction rather than the 'one off' approach that tries to avoid complexity in the short term by adopting design approaches that are sure to result in horrors later. -- Website: http://hallambaker.com/
Re: Faraday cages...
On Wed, Aug 7, 2013 at 8:17 PM, Christian Huitema huit...@microsoft.comwrote: Unless we adopt the WIDE practice where the tag is re-used from meeting to meeting. It's an elegant solution, and not that different from the reason I own a complete set of Suica, Pasmo, ICOCA, PASPY and London Oyster cards. That is where I was going with that remark, yes. :) Why bother with RFID tags, or badges? Simply register with your cell phone. We can then scan your Wi-Fi and Blue-Tooth signals when you approach the mic. -- Christian Huitema 'Simply' What is this simple technology of which you speak? I find that the best we can do with electronic systems is about 99% and that takes a huge amount of effort. I have a whole drawerful of bluetooth headsets and thats where they will stay because none of them works well enough to be useful. I have the whole Apple/Nest/Sonos/Windows/etc suite in the house. The UI sucks because my phone takes about 45 seconds to context switch to a new applet. Often it takes a lot longer as the applet begs to be updated for no particular reason. If we want to do simple then use a BARCODE. A webcam is cheaper and easier to come by than wireless scanning devices. They are just as reliable and there is only one device with a source of power involved. We could easily add QR codes to the front and rear of the badges. A side benefit would be that we also equip ourselves for showing video of people at the mic at the same time (should that prove desirable). No privacy issues, much more robust. It even deals with the issue I have occasionally had where I have had a plane delay and gone straight from the airport to a WG meeting before picking up my badge. Rare exceptions like that are easy to declare, just state it in advance at the mic. I doubt the RFID cars and the associated readers will work as well. Trying to reuse my cell phone is an exercise in the crazy. -- Website: http://hallambaker.com/
Re: Faraday cages...
On Aug 8, 2013, at 1:47 PM, Phillip Hallam-Baker hal...@gmail.com wrote: Why bother with RFID tags, or badges? Simply register with your cell phone. We can then scan your Wi-Fi and Blue-Tooth signals when you approach the mic. -- Christian Huitema 'Simply' What is this simple technology of which you speak? I find that the best we can do with electronic systems is about 99% and that takes a huge amount of effort. I have a whole drawerful of bluetooth headsets and thats where they will stay because none of them works well enough to be useful. I am fairly sure Christian was being ironic.
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
Barry, Could you please answer the questions I put to you privately: * Will CBOR become the default binary JSON encoding? * Will other IETF WGs be expected to adopt CBOR as their binary encoding? * Will you consider publishing alternative binary encodings of JSON? I accept that there are circumstances where an individual submission is appropriate. But I do not think that something that is designed to be built on by other IETF Working Groups is appropriate for individual submission. Adding a media type or a PKIX feature or HTTP header are all case where individual submission to Proposed STANDARD is quite appropriate. CBOR is not. The test I think should apply here is the dog food test: Is anyone else going to be expected to eat the product. In this case we have a specification that I am likely going to have to argue against as flawed in every WG which might use it. Which is likely to mean a lot of unnecessary WG effort, IESG effort and appeals. Most of us here have experience of using ASN.1, XML and JSON. Most of us have had a considerable amount of unnecessary pain as a result of ASN.1 and XML. The Web Services world would probably have taken off much quicker if there has been some debate and discussion before the decision was taken to turn XML into the standard for data exchange. Here we have a situation where you have decided to take a short cut on a decision that could hardly be more fundamental to the design of network protocols and handed the whole design process off to two individuals to make a design decision in private. For example, take the following messages from the CBOR authors: On Wed, May 22, 2013 at 12:16 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On May 22, 2013, at 9:14 AM, Phillip Hallam-Baker hal...@gmail.com wrote: I think we can all agree that *A* binary format would be useful and that two dozen are not useful. Nope, that is patently absurd. That would only be true if everyone agreed on all the design goals and decisions for the one binary format, and that clearly cannot happen. I think that one binary format for JSON data structures is an eminently achievable goal. There is a limited design space, the JSON model covers almost all necessary data types, the main exception being binary blobs. At the very most there might be space for one, two or three binary encodings for use in IETF protocols. But isn't the notion that binary encodings become like EAP authentication methods and we end up with two dozen what is really absurd? On Wed, May 22, 2013 at 6:42 PM, Tony Finch d...@dotat.at wrote: Why not BSON or BJSON or UBJSON or MsgPack or ... ? I never did see that question answered on the list. To be clear, there are reasons why I don't think the formats Tony suggests cannot become a universal standard but those objections also apply to CBOR which also has the problem of not being based on the JSON data model. The reason that I don't find putting the reasons in the draft an acceptable substitute to answering the three people who raised the point is that it was a cop out. Paul and Carsten gave their design rationale unilaterally and were not prepared to have their decisions challenged. Neither Paul nor Carsten have ever been noted for ranting about why XML and ASN.1 are broken. Which I see as a problem because to do a better job than those two, you really have to understand why those projects went so badly wrong. ASN.1 came very close to getting it right but they only did extensibility as an afterthought and the way they ended up handling it means that you can't use ASN.1 without a code writing tool which means that you can't use it from Perl, Python etc. unless someone has written the tool for those. XML might have been the solution but the XML design team was charged with writing a document markup language that could be defined using SGML DTD and data markup only needs about 5% of the features in XML as a result. On Wed, Aug 7, 2013 at 4:03 AM, Barry Leiba barryle...@computer.org wrote: A couple of procedural points here: The issue here is whether this proposal should be an IETF Proposed STANDARD. ... Usually when the IETF publishes an algorithm it is given INFORMATIONAL or EXPERIMENTAL status. That is what originally happened with JSON, RFC 4627 has INFORMATIONAL status despite the fact that at the time it was written there was a lot of implementation. First, Proposed Standard is just that: a proposal. It does not require implementations. It requires that it be generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. That's from RFC 2026, Section 4.1.1, which goes on to say, Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. I believe that CBOR qualifies, which is why I agreed to
Re: procedural question with remote participation
John C Klensin john-i...@jck.com wrote: In those cases, as a remote participant, I need all the help I can get. I'd rather than no one ever use a slide that has information on it in a type size that would be smaller than 20 pt on A4 paper. But 14 pt and even 12 pt happen, especially if the slides were prepared with a tool that quietly shrinks things to fit in the image area. If I'm in the room and such a slide is projected, I can walk to the front to see if if I'm not already in front and can't deduce what I need from context. If I'm remote and have such a slide in advance, I can zoom in on it or otherwise get to the information I need (assuming high enough resolution). If I'm remote and reading the slide off video, especially low resolution video, is hopeless. Also, I can't go back to the previous slide if the system is just remote projection. Good quality mumble-free audio + pre-distributed slides locally rendered beats any amount of lag-free video. I also can go ahead and find out if the speaker is going to cover an important point, or if I have to bring it *now*. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpLVRGCO4sym.pgp Description: PGP signature
Re: [iaoc-rps] RPS Accessibility
On Tue, Aug 6, 2013 at 4:03 PM, Melinda Shore melinda.sh...@gmail.comwrote: On 8/6/13 11:58 AM, Joe Abley wrote: For what it's worth (not much) I would miss the line at the mic. There are useful conversations that happen within the line that I think we would lose if the mic followed the speaker, and I also think that pipelining the people at the mic promotes more fluid conversation. But these are minor points, and I'm mainly just waxing nostalgic. I actually think that this is not a small point. The people in line are the people with issues and the ability to hash stuff out quickly is pretty nice They can also negotiate and reorganize each other. For example, if I am at the mic wanting to raise a new topic and there is someone with an issue on the current one they will usually ask if they can cut in. Another frequent case is when someone raises an issue and someone actually knows the answer. That sort of thing can be pretty important when a statement of fact is made that is wrong, particularly when it is the alleged opinion of someone else. In Orlando someone asserted X had stated Y would happen which being in the security area and knowing that Y was idiotic and X was most unlikely to have said it, I pointed out that the speaker had likely misunderstood. When I later met up with X they were surprised anyone would think they thought Y because that would be idiotic. -- Website: http://hallambaker.com/
Re: Community Feedback: IETF Trust Agreement Issues
On Aug 8, 2013, at 5:42 AM, t.p. daedu...@btconnect.com wrote: Chris I would not like to see the Trust Agreement change to accommodate issues one or two - I think that the agreement got that one right. Thank you for this feedback. Three is different. The Trust ought to be able to dispose of rights that are not needed, never will be and are costing money. But how can that be expressed without giving carte blanche to dispose of everything, for whatever purposes? We need a proposal as to how that line would be drawn - I do not have any sound ideas on this. I think providing thoughtful language around seeking community feedback and requiring time frames to dispose of items would be needed in this case. Can you indicate what annual or one-off costs we are talking about? The domain names I have dealt with have been cheap enough not to be concerned about, once I found the best way to deal with them, although I understand that the IETF is operating in a different realm and so may have costs of a different magnitude. I agree some domains are not very expensive, however trademarks require legal work for registering and filing for them. While not huge numbers, we want to raise the issue that keeping these items requires overhead and expense that seems to not be warranted in some cases, and we want to discussed and get feedback on if keeping these and paying for them makes sense. Thanks Tom Petch - Original Message - From: Chris Griffiths cgriffi...@gmail.com To: ietf@ietf.org Sent: Saturday, August 03, 2013 7:48 AM IETF Community, The IETF Trust Trustees would like feedback from the community on several issues: - We have received requests that we cannot accommodate and have consulted legal counsel to review our options - The trust agreement does not allow the trustees to effectively manage some trust assets The Trust was created in December 2005 by the Internet Society and the Corporation for National Research Initiatives (CNRI) for the purpose of the advancement of education and public interest by acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology. http://trustee.ietf.org/docs/IETF-Trust-Agreement-Executed-12-15-05.pdf Issue 1 We have recently been asked permission to republish the TAO with a creative commons license, but according to counsel, the current trust agreement does not give the trustees the rights to do this. - Without specific language being added to the trust agreement, we cannot grant these types of requests. - The current open request for a creative commons license from 6/18/2013 cannot be completed. Issue 2 We cannot currently accept physical assets like hardware donations into the trust. Once accepted into the trust, we would be unable to dispose of these items in the future if they are identified as no longer being needed. - This removes flexibility in managing assets in the trust, and we currently use alternative methods of accepting donations outside of the trust. Issue 3 Once a domain name or trademark is registered by the trust, it cannot be abandoned even if it is no longer needed. - We must maintain these in perpetuity based on legal counsel review of the current language You can also find the latest trust report that covers these items and was presented at the IETF 87 plenary here: http://www.ietf.org/proceedings/87/slides/slides-87-iesg-opsplenary-4 Thank you and we look forward to getting your feedback. Chris Griffiths Chair, IETF Trust
Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-04
On Jul 30, 2013, at 09:05, Martin Thomson martin.thom...@gmail.com wrote: What would cause this to be tragic, is if publication of this were used to prevent other work in this area from subsequently being published. Indeed. As Paul and I have repeatedly said, CBOR is not trying to be the final, definitive, binary object representation for all purposes. It was written to some specific objectives, clearly stated in the document. It is being proposed for standards-track because specific ongoing work that works well with these objectives will benefit greatly from being able to reference a common specification. If the objectives for other work are different, that work may benefit from using a different format, existing or newly designed. We had some offline discussion of what can be done to make this more apparent from the document, and decided to start at the most visible part, the abstract. In -04, the abstract says: The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. Now this seemed fairly clear to the authors, but without context it might be read as trying to be the final, end-all format because it only talks about earlier formats. We propose to fix this (at the danger of being slightly tautological) by making it clear other formats will be created in the future: The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack, or other binary serializations that may be created in the future. Serialization/encoding of data structures for transmission continues to be an exciting (if sometimes arcane) subject of computer science and its long history will not end with CBOR. (CC to ietf@ietf.org because some discussion there appears to be related.) Grüße, Carsten
Re: Community Feedback: IETF Trust Agreement Issues
I've been doing some more thinking about this, and I have received quite a bit of private feedback about my previous comments, ranging from don't be so picky, let these guys do their thankless job to please be more picky, this is the thin end of the wedge. So - this isn't really about being picky, except that a legal agreement more or less forces us to be picky. Also, I appreciate as much as anybody that the Trustees are doing a thankless job for the benefit of the community. But if we look at the three issues together, we have to also consider *why* the Trust was created in the first place. My summary: it was created to ensure that the intellectual property important for the openness of Internet standards could never be alienated or altered except for the benefit of the community. I can understand why, in certain circumstances, the community might agree that some physical property, such as a worn-out pencil sharpener, should be disposed of, or that a specific piece of intellectual property might be agreed by the community to no longer important and therefore could be released by the Trust. The first case is pretty easy and I think we *could* give the Trustees the authority to dispose of useless physical property. Intellectual property is much harder, because who is to judge what's important? We might reach consensus that it's OK to release change control over the Tao (although I'm not sure I agree with that - what's so hard about keeping it under an RFC-like license?). We probably wouldn't reach consensus to release change control over RFC 791. But who would care to write down legally sound text drawing the line between those two extremes? A couple more comments in line... On 09/08/2013 07:47, Chris Griffiths wrote: On Aug 8, 2013, at 5:42 AM, t.p. daedu...@btconnect.com wrote: Chris I would not like to see the Trust Agreement change to accommodate issues one or two - I think that the agreement got that one right. As I said, if the Trust has a worn-out piece of equipment, they should be able to dispose of it. But this dilemma can be avoided by not acquiring equipment at all. Thank you for this feedback. Three is different. The Trust ought to be able to dispose of rights that are not needed, never will be and are costing money. But how can that be expressed without giving carte blanche to dispose of everything, for whatever purposes? We need a proposal as to how that line would be drawn - I do not have any sound ideas on this. I think providing thoughtful language around seeking community feedback and requiring time frames to dispose of items would be needed in this case. I note that the Trust Agreement does not explicitly recognise that the Trustees should follow BCP 101, including aspects such as: To ensure that the IASA is run in a transparent and accountable manner. the IAOC and IAD will ensure that guidelines are developed for regular operational decision making. Where appropriate, these guidelines should be developed with public input. In all cases, they must be made public If we're going to add something about community feedback to the Trust Agreement it should probably be more general rather than just for the specific matter of asset disposal. It's always been understood that the transparency requirement for the IAOC also applies to the Trust, but to my surprise we never wrote it down. Can you indicate what annual or one-off costs we are talking about? The domain names I have dealt with have been cheap enough not to be concerned about, once I found the best way to deal with them, although I understand that the IETF is operating in a different realm and so may have costs of a different magnitude. I agree some domains are not very expensive, however trademarks require legal work for registering and filing for them. While not huge numbers, we want to raise the issue that keeping these items requires overhead and expense that seems to not be warranted in some cases, and we want to discussed and get feedback on if keeping these and paying for them makes sense. There's also the issue that (as I understand it) specific marks like IETF Secretariat may be easier to defend than a more generic mark like plain IETF. IANAL. Brian Thanks Tom Petch - Original Message - From: Chris Griffiths cgriffi...@gmail.com To: ietf@ietf.org Sent: Saturday, August 03, 2013 7:48 AM IETF Community, The IETF Trust Trustees would like feedback from the community on several issues: - We have received requests that we cannot accommodate and have consulted legal counsel to review our options - The trust agreement does not allow the trustees to effectively manage some trust assets The Trust was created in December 2005 by the Internet Society and the Corporation for National Research Initiatives (CNRI) for the purpose of the advancement of education and public interest by acquiring, holding, maintaining and licensing certain
RE: Faraday cages...
Why bother with RFID tags, or badges? Simply register with your cell phone. We can then scan your Wi-Fi and Blue-Tooth signals when you approach the mic. -- Christian Huitema 'Simply' What is this simple technology of which you speak? I find that the best we can do with electronic systems is about 99% and that takes a huge amount of effort. I have a whole drawerful of bluetooth headsets and thats where they will stay because none of them works well enough to be useful. I am fairly sure Christian was being ironic. :-) I was. On the other hand, there are systems out there that will, for example, track customers as they move in a shop. They do that by listening to the Bluetooth radios. They definitely do not requests the customers to install an application or pair their devices. An extract form a research paper on the subject (http://www.gim-international.com/issues/articles/id1443-Bluetooth_Tracking.html) asserts that Bluetooth tracking on the basis of MAC addresses does not violate privacy law. In fact, it simply makes use of a general Bluetooth function: scanning for nearby devices. Everyone is free to use this function, for instance when turning on a mobile phone in a public place. So it must be just fine. -- Christian Huitema
Re: Community Feedback: IETF Trust Agreement Issues
On Aug 8, 2013, at 1:46 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: We might reach consensus that it's OK to release change control over the Tao (although I'm not sure I agree with that - what's so hard about keeping it under an RFC-like license?). Nothing is hard about it. The question is whether granting a different license will help the goals of the Tao more than the current license. Many people (including me, the current editor) think that a lighter-weight license would get the Tao read by more people. --Paul Hoffman
Re: Community Feedback: IETF Trust Agreement Issues
On 08/08/2013 02:04 PM, Paul Hoffman wrote: On Aug 8, 2013, at 1:46 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: We might reach consensus that it's OK to release change control over the Tao (although I'm not sure I agree with that - what's so hard about keeping it under an RFC-like license?). Nothing is hard about it. The question is whether granting a different license will help the goals of the Tao more than the current license. Many people (including me, the current editor) think that a lighter-weight license would get the Tao read by more people. Can you elaborate on why the license makes a difference?
Re: Community Feedback: IETF Trust Agreement Issues
On Aug 8, 2013, at 2:09 PM, Doug Barton do...@dougbarton.us wrote: On 08/08/2013 02:04 PM, Paul Hoffman wrote: On Aug 8, 2013, at 1:46 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: We might reach consensus that it's OK to release change control over the Tao (although I'm not sure I agree with that - what's so hard about keeping it under an RFC-like license?). Nothing is hard about it. The question is whether granting a different license will help the goals of the Tao more than the current license. Many people (including me, the current editor) think that a lighter-weight license would get the Tao read by more people. Can you elaborate on why the license makes a difference? We have been told it would make it easier for people to make and distribute translations. --Paul Hoffman
Re: Community Feedback: IETF Trust Agreement Issues
Can you elaborate on why the license makes a difference? We have been told it would make it easier for people to make and distribute translations. --Paul Hoffman Actually, verbatim translations are already allowed under the existing IETF document license. It's other modifications that are not allowed under IETF, but which CC-BY would permit.
Re: Community Feedback: IETF Trust Agreement Issues
We have recently been asked permission to republish the TAO with a creative commons license, but according to counsel, the current trust agreement does not give the trustees the rights to do this. - Without specific language being added to the trust agreement, we cannot grant these types of requests. I'm looking at section 9.5 of the trust agreement, and I'm looking at the CC Attribution-NoDerivs 3.0 license, and I don't see what's in the CC license that conflicts with the trust agreement. The TA says that derivatives belong to the IETF, the CC license says no derivatives, the TA says that the goodwill belongs to the IETF, the CC license says no disparaging, which isn't the same thing but leans in the same direction. If they want a different CC license, that's easy, the answer is no. http://creativecommons.org/licenses/by-nd/3.0/legalcode Once a domain name or trademark is registered by the trust, it cannot be abandoned even if it is no longer needed. - We must maintain these in perpetuity based on legal counsel review of the current language I have more sympathy for this one. Although the renewal fee for a domain name is usually trivial, what happens if some third party files a UDRP challenge to or a lawsuit about a domain name that the IETF is no longer using? Do they have to run up legal bills responding to and fighting it? For trademarks, the renewal fee is $400 payable 5 years and 10 years after registration, and every 10 years after that. But along with the renewal fee, the registrant has to send in a sworn statement saying that the mark is still in use in commerce, listing the goods and services on which it's used, and if requested providing samples. If the IETF isn't actually using the mark, what is the trust supposed to do? Furthermore, unlike patent or copyrights, a trademark owner has to police unauthorized use and challenge it legally, or risk losing the trademark to what's known as genericide. This is a lot of work for a trademark you want, and it's absurd for one you don't. My suggestion would be that the abandonment process take a year, requiring four quarterly announcements and solicitation of comments to a public venue such as the IETF general list. After the year, considering all responses received, if the trustees believe that there is consensus to abandon, they do so. If people are concerned that the trustees would do something silly, the solution is to pick better trustees, not to make more complex rules. R's, John
Re: Community Feedback: IETF Trust Agreement Issues
On Aug 8, 2013, at 2:21 PM, Jorge Contreras cntre...@gmail.com wrote: Actually, verbatim translations are already allowed under the existing IETF document license. It's other modifications that are not allowed under IETF, but which CC-BY would permit. That sounds right. Someone might want to add commentary (even in English) to the Tao, such as to discuss local participants, diversity, and so on. --Paul Hoffman
Re: Community Feedback: IETF Trust Agreement Issues
On Aug 9, 2013, at 12:21 AM, Jorge Contreras cntre...@gmail.com wrote: Can you elaborate on why the license makes a difference? We have been told it would make it easier for people to make and distribute translations. --Paul Hoffman Actually, verbatim translations are already allowed under the existing IETF document license. It's other modifications that are not allowed under IETF, but which CC-BY would permit. Interesting. What does verbatim translation mean? Word-for-word? There is a reason why searching for google translate funny yields 63,000 results. How much would I be allowed to paraphrase and yet keep within the license? Yoav
Re: Community Feedback: IETF Trust Agreement Issues
On 08/08/2013 02:49 PM, Paul Hoffman wrote: On Aug 8, 2013, at 2:21 PM, Jorge Contreras cntre...@gmail.com wrote: Actually, verbatim translations are already allowed under the existing IETF document license. It's other modifications that are not allowed under IETF, but which CC-BY would permit. That sounds right. Someone might want to add commentary (even in English) to the Tao, such as to discuss local participants, diversity, and so on. It's not at all clear to me why the current license would prohibit that, or why the CC license would make it easier or better. As long as the commentary is clearly separated from the text of the Tao, there is no conflict. What I'm looking for is a clear statement to the effect of, We cannot do X with the current license because ...; and the CC license would make that better because ... Doug
Re: Community Feedback: IETF Trust Agreement Issues
Actually, verbatim translations are already allowed under the existing IETF document license. It's other modifications that are not allowed under IETF, but which CC-BY would permit. That sounds right. Someone might want to add commentary (even in English) to the Tao, such as to discuss local participants, diversity, and so on. Someone might, or they might rewrite it to say that IETF meetings have simultaneous translation, and while the IAB is all U.S. greybeards, the IESG members are chosen to represent the gender and ethnic balance of the whole world. Or they might rewrite it to say that the IETF has corporate members, you have work for one to participate, and all RFCs are standards. The CC license says You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Would those changes be prejudicial to your honor or reputation, or are they just wrong? How much are we willing to spend to find out? It's extremely hard to let just one of the cat's paws out of the bag. In practice either we have change control or we don't, and I don't see much sentiment for giving it up to unknown CC users. On the other hand, if they just want a CC license, it looks to me like they can use CC BY-ND right now. R's, John
Re: Faraday cages...
Hmmm didn't a certain large company whose name rhymes with scroogle recently get whacked with a huge fine for violating privacy in a similar manner in the EU? Like you say, must be just fine it says so on the net. On Thu, Aug 8, 2013 at 4:52 PM, Christian Huitema huit...@microsoft.comwrote: Why bother with RFID tags, or badges? Simply register with your cell phone. We can then scan your Wi-Fi and Blue-Tooth signals when you approach the mic. -- Christian Huitema 'Simply' What is this simple technology of which you speak? I find that the best we can do with electronic systems is about 99% and that takes a huge amount of effort. I have a whole drawerful of bluetooth headsets and thats where they will stay because none of them works well enough to be useful. I am fairly sure Christian was being ironic. :-) I was. On the other hand, there are systems out there that will, for example, track customers as they move in a shop. They do that by listening to the Bluetooth radios. They definitely do not requests the customers to install an application or pair their devices. An extract form a research paper on the subject ( http://www.gim-international.com/issues/articles/id1443-Bluetooth_Tracking.html) asserts that Bluetooth tracking on the basis of MAC addresses does not violate privacy law. In fact, it simply makes use of a general Bluetooth function: scanning for nearby devices. Everyone is free to use this function, for instance when turning on a mobile phone in a public place. So it must be just fine. -- Christian Huitema -- Website: http://hallambaker.com/
Re: Faraday cages...
On 08/08/2013 07:41 PM, Phillip Hallam-Baker wrote: Hmmm didn't a certain large company whose name rhymes with scroogle recently get whacked with a huge fine for violating privacy in a similar manner in the EU? The rules are different for large companies with funny names. Keith
Re: Faraday cages...
When next you walk into a target or big W, ask to see the conditions of entry. Along with implied consent to have your bags checked at any time, you have probably given consent to be video'ed and tracked at their behest. The poster is on the wall somewhere usually. Your statutory rights cannot be abrogated but equally, the grey areas have been 'informed'. BT tracking inside the store is passive collection of data you are radiating. The store's use of the BT location and timing of presence against shelves is private information of immense value to them. They share it for mutual benefit with suppliers, or for money. I doubt they give much away. The large international scroogle rhyming company was compiling third party uses of the data to inform location as a service, and were not solely collecting information inside their own physical territory you entered, with implied consent: they were harvesting data in the public space and then providing insight into that data into the public space. They relate because its harvesting RF. They don't relate in much else to my mind. -G On Fri, Aug 9, 2013 at 10:22 AM, Keith Moore mo...@network-heretics.comwrote: On 08/08/2013 07:41 PM, Phillip Hallam-Baker wrote: Hmmm didn't a certain large company whose name rhymes with scroogle recently get whacked with a huge fine for violating privacy in a similar manner in the EU? The rules are different for large companies with funny names. Keith
Re: Faraday cages...
On Thu, Aug 8, 2013 at 8:31 PM, George Michaelson g...@algebras.org wrote: When next you walk into a target or big W, ask to see the conditions of entry. Along with implied consent to have your bags checked at any time, you have probably given consent to be video'ed and tracked at their behest. The poster is on the wall somewhere usually. Your statutory rights cannot be abrogated but equally, the grey areas have been 'informed'. The efficacy of such notices has not been tested in court and when they are tested it is likely to cost the target about $2 million+ in legal fees. Since the IETF meets around the world the last thing we need is to spend time checking the legality of the badge at the mic system. And even though the IETF is not likely to be a target, I would hate to have some of the less popular with governments organizations I am involved in copy what the IETF does and then find themselves being targeted with a selective prosecution. Barcodes have the potential to work really well and require almost no change from current practice. The only downside to a barcode is that they are slightly easier to forge. Though in the IETF context, forgery would likely consist of people copying other people's badges for fun rather than to avoid paying. -- Website: http://hallambaker.com/
Re: Faraday cages...
Philip, I'm not disagreeing. I responded to Keith's mail relating what we do to what was done harvesting WiFi. Like the store, we're in a room. we're in a world of implied and actual consent (you do actually have to give some consents when you register for IETF) -G On Fri, Aug 9, 2013 at 10:48 AM, Phillip Hallam-Baker hal...@gmail.comwrote: On Thu, Aug 8, 2013 at 8:31 PM, George Michaelson g...@algebras.orgwrote: When next you walk into a target or big W, ask to see the conditions of entry. Along with implied consent to have your bags checked at any time, you have probably given consent to be video'ed and tracked at their behest. The poster is on the wall somewhere usually. Your statutory rights cannot be abrogated but equally, the grey areas have been 'informed'. The efficacy of such notices has not been tested in court and when they are tested it is likely to cost the target about $2 million+ in legal fees. Since the IETF meets around the world the last thing we need is to spend time checking the legality of the badge at the mic system. And even though the IETF is not likely to be a target, I would hate to have some of the less popular with governments organizations I am involved in copy what the IETF does and then find themselves being targeted with a selective prosecution. Barcodes have the potential to work really well and require almost no change from current practice. The only downside to a barcode is that they are slightly easier to forge. Though in the IETF context, forgery would likely consist of people copying other people's badges for fun rather than to avoid paying. -- Website: http://hallambaker.com/
Re: Faraday cages...
On 08/08/2013 08:48 PM, Phillip Hallam-Baker wrote: Barcodes have the potential to work really well and require almost no change from current practice. Except that current practice is broken anyway and we desperately need to change it, not add more mechanisms to reinforce continued use of it. Actually I think all of this emphasis on being able to reliably identify every speaker is a bit beside the point. With rare exceptions, who is speaking is not nearly as relevant as what is being said. Of course there are times when it's important or useful to know who is speaking - say if it's an AD, or the document author/editor, or a person with whom there needs to be a followup discussion. But when we find ourselves working so hard to make sure that we can reliably identify every speaker (and perhaps also to exclude anonymous / pseudonymous input), maybe that's a distraction. Maybe we should instead be concentrating on how to make sure that our standards have been written in light of a wide degree of input about requirements, are technically sound, and have enjoyed thorough review. Would being able to reliably know exactly who said everything that was said in a WG meeting visibly improve the quality of our standards? If the answer is not a clear yes (and I don't think it is) then I suggest that this topic is a distraction. Keith
Re: Faraday cages...
On Fri, Aug 9, 2013 at 11:05 AM, Keith Moore mo...@network-heretics.comwrote: Would being able to reliably know exactly who said everything that was said in a WG meeting visibly improve the quality of our standards? If the answer is not a clear yes (and I don't think it is) then I suggest that this topic is a distraction. Keith With this I heartily agree. I think there is nothing to see here which will really make much difference, or cannot be solved in other ways after the event anyway. The problem is not one which technology can solve, because the problem isn't that kind of problem.
Re: Faraday cages...
In message cakr6gn3qr-oaegi0xjglhocmvf7x7eex6akibb5oys0rizo...@mail.gmail.com , George Michaelson writes: When next you walk into a target or big W, ask to see the conditions of entry. Along with implied consent to have your bags checked at any time, you have probably given consent to be video'ed and tracked at their behest. The poster is on the wall somewhere usually. Your statutory rights cannot be abrogated but equally, the grey areas have been 'informed'. You expect to video'ed and bag checked for stock loss prevention. There is no implied consent for anything else. You don't need to track mobile phones for stock loss prevention. BT tracking inside the store is passive collection of data you are radiating. The store's use of the BT location and timing of presence against shelves is private information of immense value to them. They share it for mutual benefit with suppliers, or for money. I doubt they give much away. The large international scroogle rhyming company was compiling third party uses of the data to inform location as a service, and were not solely collecting information inside their own physical territory you entered, with implied consent: they were harvesting data in the public space and then providing insight into that data into the public space. They relate because its harvesting RF. They don't relate in much else to my mind. The main difference is the levels of encryption used in the two standards. For WiFi there are still a large percentage of networks sending in the clear. For BlueTooth there were no non-encrypted channels in the base spec (1.0) support for them was added in 1.1 [1]. With BlueTooth you get presence. With WiFi you get presence + data Mark [1] http://en.wikipedia.org/wiki/Bluetooth#Bluetooth_v1.1 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Weekly posting summary for ietf@ietf.org
Total of 288 messages in the last 7 days. script run at: Fri Aug 9 00:53:03 EDT 2013 Messages | Bytes| Who +--++--+ 7.29% | 21 | 6.58% | 137704 | ted.le...@nominum.com 4.86% | 14 | 4.24% |88736 | scott.b...@gmail.com 4.51% | 13 | 3.79% |79279 | jo...@taugh.com 3.82% | 11 | 4.27% |89389 | hadriel.kap...@oracle.com 2.78% |8 | 4.66% |97597 | hal...@gmail.com 3.47% | 10 | 3.18% |66490 | mo...@network-heretics.com 3.12% |9 | 3.19% |66877 | john-i...@jck.com 2.43% |7 | 2.11% |44224 | y...@checkpoint.com 2.43% |7 | 1.97% |41295 | aaron.d...@cl.cam.ac.uk 2.08% |6 | 2.03% |42597 | jab...@hopcount.ca 1.74% |5 | 2.24% |46840 | brian.e.carpen...@gmail.com 1.74% |5 | 2.17% |45393 | cgriffi...@gmail.com 1.74% |5 | 1.72% |36025 | s...@resistor.net 1.74% |5 | 1.55% |32513 | c...@tzi.org 1.74% |5 | 1.55% |32472 | mcr+i...@sandelman.ca 1.74% |5 | 1.54% |32264 | barryle...@computer.org 1.74% |5 | 1.42% |29701 | do...@dougbarton.us 1.39% |4 | 1.72% |35986 | abdussalambar...@gmail.com 1.74% |5 | 1.34% |28087 | paul.hoff...@vpnc.org 1.04% |3 | 1.62% |33914 | spencerdawkins.i...@gmail.com 1.39% |4 | 1.26% |26452 | ulr...@herberg.name 1.39% |4 | 1.21% |25379 | h...@cs.columbia.edu 1.04% |3 | 1.41% |29477 | g...@algebras.org 1.04% |3 | 1.25% |26200 | mary.h.bar...@gmail.com 0.69% |2 | 1.49% |31154 | superu...@gmail.com 1.04% |3 | 1.13% |23755 | hil...@cursive.net 0.69% |2 | 1.37% |28593 | cntre...@gmail.com 1.04% |3 | 1.00% |20881 | stephen.farr...@cs.tcd.ie 1.04% |3 | 0.98% |20456 | pait...@cisco.com 1.04% |3 | 0.94% |19716 | o...@cisco.com 1.04% |3 | 0.92% |19193 | m...@sandelman.ca 1.04% |3 | 0.89% |18567 | d...@dcrocker.net 1.04% |3 | 0.87% |18120 | adr...@olddog.co.uk 1.04% |3 | 0.86% |18025 | l...@netapp.com 1.04% |3 | 0.86% |18017 | melinda.sh...@gmail.com 1.04% |3 | 0.85% |17892 | joe...@bogus.com 0.69% |2 | 0.84% |17550 | l.w...@surrey.ac.uk 0.69% |2 | 0.82% |17211 | daedu...@btconnect.com 0.69% |2 | 0.81% |16966 | huit...@microsoft.com 0.69% |2 | 0.77% |16166 | andr...@plixer.com 0.69% |2 | 0.74% |15583 | grm...@gmail.com 0.69% |2 | 0.73% |15295 | carlosm3...@gmail.com 0.69% |2 | 0.71% |14909 | doug.mtv...@gmail.com 0.69% |2 | 0.71% |14817 | o...@nlnetlabs.nl 0.69% |2 | 0.69% |14423 | petit...@acm.org 0.69% |2 | 0.69% |14359 | james.h.man...@team.telstra.com 0.69% |2 | 0.64% |13368 | a...@yumaworks.com 0.69% |2 | 0.63% |13122 | rpellet...@isoc.org 0.69% |2 | 0.58% |12238 | arturo.ser...@gmail.com 0.69% |2 | 0.58% |12064 | h...@shrubbery.net 0.69% |2 | 0.56% |11702 | glenn.d...@nbcuni.com 0.69% |2 | 0.55% |11585 | jari.ar...@piuha.net 0.69% |2 | 0.54% |11318 | o...@edvina.net 0.69% |2 | 0.49% |10285 | m...@sap.com 0.35% |1 | 0.82% |17173 | cpign...@cisco.com 0.69% |2 | 0.47% | 9886 | ra...@psg.com 0.69% |2 | 0.43% | 8965 | j...@mercury.lcs.mit.edu 0.35% |1 | 0.60% |12460 | ron.even@gmail.com 0.35% |1 | 0.49% |10339 | nar...@us.ibm.com 0.35% |1 | 0.48% | 9952 | jmp...@cisco.com 0.35% |1 | 0.45% | 9462 | uyesh...@ifa.hawaii.edu 0.35% |1 | 0.45% | 9364 | mehmet.er...@nsn.com 0.35% |1 | 0.45% | 9336 | rog...@gmail.com 0.35% |1 | 0.45% | 9333 | l...@cisco.com 0.35% |1 | 0.45% | 9330 | gjs...@gmail.com 0.35% |1 | 0.44% | 9299 | d...@cridland.net 0.35% |1 | 0.42% | 8862 | cgriffi...@dyn.com 0.35% |1 | 0.41% | 8603 | ma...@isc.org 0.35% |1 | 0.41% | 8490 | framefri...@gmail.com 0.35% |1 | 0.40% | 8304 | bmann...@isi.edu 0.35% |1 | 0.37% | 7831 | b...@brianrosen.net 0.35% |1 | 0.37% | 7734 | aal...@blackberry.com 0.35% |1 | 0.36% | 7615 | jgu...@csc.com 0.35% |1 | 0.36% | 7582 | tobias.gond...@gondrom.org 0.35% |1 | 0.36% | 7517 | y...@isoc.org 0.35% |1 | 0.35% | 7345 | chell...@pobox.com 0.35% |1 | 0.34% | 7092 | l...@pi.nu 0.35% |1 | 0.34% | 7090 | listse...@me.com 0.35% |1 | 0.34% | 7056 | jcur...@istaff.org 0.35% |1 | 0.34% | 7056 | iana-questi...@iana.org 0.35% |1 | 0.34% | 7035 | t...@att.com 0.35% |1 | 0.33% | 7011 | rg+i...@qualcomm.com 0.35% |1 | 0.32% | 6788 | alexey.melni...@isode.com 0.35% |1 | 0.31% | 6483 | sprom...@unina.it 0.35% |1 |
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Thu, Aug 8, 2013 at 7:47 AM, Phillip Hallam-Baker hal...@gmail.comwrote: The point is that there would BE discussion. Consensus is not enough, the process has to be open. A consensus formed by keeping people out of the room is no consensus at all. I believe this is why an AD-sponsored document undergoes a Last Call twice the length of a document that comes out of a working group, and the comments are typically sent to this list, which is open by definition and also goes to a more general audience than a working group list would. I don't see any evidence of attempts to exclude participation here, unless your concern is sufficiently general that you also believe the Individual Submission route needs to be abolished because it's too closed. -MSK
Last Call: draft-ietf-storm-iscsi-sam-08.txt (Internet Small Computer Systems Interface (iSCSI) SCSI Features Update) to Proposed Standard
The IESG has received a request from the STORage Maintenance WG (storm) to consider the following document: - 'Internet Small Computer Systems Interface (iSCSI) SCSI Features Update' draft-ietf-storm-iscsi-sam-08.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-08-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in RFCxxx (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a companion document to RFCxxx. RFC EDITORS NOTE: The above two references to RFCxxx should reference the RFC number assigned to the draft-ietf-storm- iscsi-cons-xx document, and this note should be removed. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 6994 on Shared Use of Experimental TCP Options
A new Request for Comments is now available in online RFC libraries. RFC 6994 Title: Shared Use of Experimental TCP Options Author: J. Touch Status: Standards Track Stream: IETF Date: August 2013 Mailbox:to...@isi.edu Pages: 11 Characters: 25577 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-experimental-options-06.txt URL:http://www.rfc-editor.org/rfc/rfc6994.txt This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6984 on Interoperability Report for Forwarding and Control Element Separation (ForCES)
A new Request for Comments is now available in online RFC libraries. RFC 6984 Title: Interoperability Report for Forwarding and Control Element Separation (ForCES) Author: W. Wang, K. Ogawa, E. Haleplidis, M. Gao, J. Hadi Salim Status: Informational Stream: IETF Date: August 2013 Mailbox:wmw...@zjsu.edu.cn, ogawa.kent...@lab.ntt.co.jp, eha...@ece.upatras.gr, gaom...@mail.zjgsu.edu.cn, h...@mojatatu.com Pages: 29 Characters: 70308 Updates:RFC 6053 I-D Tag:draft-ietf-forces-interop-09.txt URL:http://www.rfc-editor.org/rfc/rfc6984.txt This document captures the results of the second Forwarding and Control Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China. The results of the first ForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results. This document is a product of the Forwarding and Control Element Separation Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
