Re: IAOC: delegating ex-officio responsibility
So my brain then went to: The ex officio positions are non-voting liaisons, delegated or not, but they also should appoint a person who is /not/ from their body as a voting person. IMHO your brain went to the wrong place ;-) The IETF Chair is not a liaison for goodness sake - s/he is where the buck stops and should be a full part of the oversight process. Do remember that the O in IAOC stands for oversight; it's the IAD and the various contractors who execute. And if the question of who has a formal vote in the IAOC ever becomes a real issue, we are, as JCK might say, already in far worse trouble. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Internet pioneer Paul Baran passes away
Sad news: http://www.bbc.co.uk/news/technology-12879908 -- Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Site Renumbering (RENUM) BOF at IETF 80
Site Renumbering (RENUM) BOF at IETF 80 THURSDAY, March 31, 2011, 1520-1720, Congress Hall II Chairs: Brian Carpenter + TBD Sponsoring AD: Ron Bonica Mailing list: re...@ietf.org Subscribe: https://www.ietf.org/mailman/listinfo/renum Description --- As outlined in RFC 5887, renumbering, especially for medium to large sites and networks, is viewed as an expensive, painful, and error-prone process, avoided by network managers as much as possible. Some would argue that the very design of IP addressing and routing makes automated renumbering intrinsically impossible. In fact, managers have an economic incentive to avoid having to renumber, and many have resorted to private addressing and Network Address Translation (NAT) as a result. This has the consequence that any mechanisms for managing the scaling problems of wide-area (BGP4) routing that require site renumbering have been dismissed as unacceptable. Even so, renumbering is sometimes unavoidable. It is expected that as the pressure on IPv4 address space intensifies in the next few years, there will be many attempts to consolidate usage of IPv4 addresses so as to avoid wastage, which necessarily requires renumbering of the sites involved. Unfortunately, current IPv4 deployment practices mean that automating this process appears extremely difficult. However, strategically, it is more important to implement and deploy techniques for IPv6 site renumbering, so that as IPv6 becomes universally deployed, renumbering can be viewed as a relatively routine event. For renumbering to become routine, a systematic address management approach will be essential. A large site with a short prefix will be divided into subnets with longer prefixes. In this scenario, renumbering or partial renumbering can be complicated. Aggregation, synchronisation, coordination, etc., need to be carefully managed. The task of the RENUM working group is to identify specific renumbering problems in the context of site-wide renumbering, and to develop point solutions and system solutions to address those problems, or to stimulate such development in other working groups if appropriate. The principal target will be solutions for IPv6, but solutions that apply equally to IPv4 may be considered. RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are starting points for this work. Goals/deliverables -- Develop draft-jiang-ipv6-site-renum-guideline as a roadmap for the WG and for items that should be specified by other WGs. - The result of this work will be a more specific list of goals and deliverables Develop a management model for site renumbering. Milestones -- Jul 2011draft-jiang-ipv6-site-renum-guideline ready for WGLC Sep 2011draft-jiang-ipv6-site-renum-guideline ready for IESG Oct 2011management model ready for WGLC Nov 2011recharter with specific goals and deliverables Dec 2011management model ready for IESG BOF agenda -- 0. Agenda Bash, Intro. (5 min) 1. Brief review of RFC 5887. (Brian Carpenter, 10 min) 2. Main lessons from UNH experience (Tim Winters, Lincoln Lavoie, 10 min) 3. Review of draft-jiang-ipv6-site-renum-guideline. (Sheng Jiang, 15 min) 4. Brief review of RFC 4192, and a management model for systematic renumbering. (Fred Baker, 15 min) 5. Brief announcements of solution space drafts (1 slide each, 2 min each): 5.1. Border Router Discovery Protocol (BRDP) framework, draft-boot-brdp-framework (Teco Boot) 5.2. Diagnostic function for SLAAC/DHCPv6 conflicts, draft-liu-ipv6-renum-conflicts (Sheng Jiang) 6. Discussion of goals and milestones. (30 min) 7. Discussion of conclusions (further work justified? WG? Which area?). (10 min) -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On 2011-03-16 11:22, Martin Rex wrote: Dave CROCKER wrote: Brian E Carpenter wrote: Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. 1. While the accounting ugliness of leaving these untouched is obvious, I am less clear about the practical trouble they cause. We should gain some public agreement that this is seriousness enough to worry about, and why. 2. Automatic reclassification strikes me as dangerous and likely to have serious unintended consequences. I don't understand the motivation about changing anything about the status of documents that have already been published. Among the original complaints there were the two: - the IETF is confusing the non-IETFers about the standardization with its three levels of document maturity - the bar for Proposed is too high and ought to be lowered. Unless the clear intent and IETF consensus is to add - mislead _everyone_ about the real document maturity of *ALL* IETF documents, including all existing documents If we do the reclassification correctly, nobody will be misled. - penalize all folks did put effort into going to Draft Standard by completely nixing their effort two years later. That's why my personal preference is what I already suggested - just label them all as Internet Standard. But in fact, the proposed bar for promotion from DS to Internet Standard is pretty low. I doubt that any deserving document will lose out. There are 85 DS documents today. If each IETF Area does its own bulk promotion, that averages at 12 documents per area - not an enormous job. the status of the existing documents should NOT be touched by any new rules for publishing documents as Proposed Standards. Disagree. If we don't reclassify, people will be puzzled for the next 50 years by the residual DS documents. To make clear which documents were issued under the original regime and which were issued under the new, there should probably be an obvious gap in the number range (going to 5 digit or 6 digit numbers). Oh, have you any guess how many tools will be broken by the RFC10K problem? (That is not a joke.) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
There are numerous improvements in this version and I hope we can get consensus soon. Just a couple of remarks on 5. Transition to a Standards Track with Two Maturity Levels 1) Probably there should be a statement that all existing Internet Standard documents are still classified as Internet Standard. That may seem blindingly obvious, but if we don't write it down, somebody will ask. 2) More substantively, Any protocol or service that is currently at the Draft Standard maturity level may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. This reclassification is accomplished by submitting a request to the IESG along with a description of the implementation and operational experience. I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Where to find IONs?
On 2011-03-07 00:15, Adrian Farrel wrote: Hi Mykyta, Please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04792.html Adrian One could argue that http://www.ietf.org/iesg/process-experiment.html should also contain pointers, or at least a status line, for concluded experiments. (It's my fault that it doesn't, since I created the original version of that page.) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about OAM for MPLS
On 2011-03-04 06:51, Russ Housley wrote: Nurit: Not to mention including the canard that the IETF unilaterally disbanded its group assigned to work with ITU in 2009. Others with more detailed knowledge can explain exactly why this is, er, a lie. Here are some facts: === I was member of the MEAD team. A meeting of the MEAD team was scheduled to meet in Munich 12-14 October 2009. It was scheduled right after an ITU-T SG15 plenary meeting (September 28 - October 9) because MEAD team members attended that meeting too. On Friday October 2nd an agenda was distributed for the MEAD team for the meeting in Munich on the MEAD team list m...@ietf.org. On Monday October 5th an email was sent to m...@ietf.org announcing the disbanding of the MEAD team, and that the meeting in Munich should not be considered a MEAD team meeting. The decision to disband the MEAD team was liaised to the ITU-T on the same day (October 5). Do I need to say more. It does not sound like the shutdown of the MEAD team was smooth. However, the closure of a design team when their output is being handled by a working group is quite normal. That's the point. A design team is always a short term mechanism and once it reports back to the WG, it closes down. Not having been personally involved, I can't judge whether the process was clear to those involved, especially people with more experience in ITU-T than in the IETF. Just so we are all talking about the same thing, here is the official description from BCP 25 (RFC 2418): 6.5. Design teams It is often useful, and perhaps inevitable, for a sub-group of a working group to develop a proposal to solve a particular problem. Such a sub-group is called a design team. In order for a design team to remain small and agile, it is acceptable to have closed membership and private meetings. Design teams may range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair or AD appoints to attack a controversial problem. The output of a design team is always subject to approval, rejection or modification by the WG as a whole. In other words, what counts in the IETF process is the WG consensus, not the design team consensus. There are cases where the WG refuses or significantly changes the design team proposal; RFC 3246 and RFC 3248 make a good example. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about OAM for MPLS
On 2011-03-03 05:02, Marshall Eubanks wrote: On Mar 2, 2011, at 10:15 AM, Russ Housley wrote: I want the whole community to be aware of the comments that I made to the press over the past few days. Last Friday, the ITU-T Study Group 15 decided to move forward with an OAM solution that is incompatible with the work being done in the IETF MPLS WG. This is a breach of the agreement reached by the IETF and the ITU-T, which is published in RFC 5317. The ITU-T press release about their action is here: http://www.itu.int/net/pressoffice/press_releases/2011/03.aspx On behalf of the IETF, ISOC helped get the word out: http://isoc.org/wp/newsletter/?p=3287 The press is starting to cover the story: http://www.eweekeurope.co.uk/news/ietf-slams-itu-standards-vote-22392 http://news.idg.no/cw/art.cfm?id=8B71BD58-1A64-6A71-CE24B4B4EB59B200 And, the ITU-T made a second announcement today: http://www.itu.int/ITU-T/newslog/Experts+Cast+Doubt+On+Jeopardize+Internet+Statement.aspx With a very badly worded appeal to unnamed authority. Not a good response in my opinion. Not to mention including the canard that the IETF unilaterally disbanded its group assigned to work with ITU in 2009. Others with more detailed knowledge can explain exactly why this is, er, a lie. I am very disturbed by this development. ITU/IETF agreements go back a long way - I believe the first ones were signed off by Vint Cerf, so long ago that I would need to look in my paper archives to find the date. In fifteen years of my personal experience, including my own dealings with three different heads of ITU-T while I was IAB Chair and then IETF Chair, they have never reneged on an agreement before. Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Where to find IETF recommendations?
On 2011-03-02 01:29, Andrew Sullivan wrote: On Tue, Mar 01, 2011 at 01:18:12PM +0100, Shane Kerr wrote: FWIW, this came up in the dnsext working group a few years ago. In the end, I don't think anything was done, which is kind of a shame. Nothing was done for want of workers ;-) We concluded there was no real room in official IETF channels for such a publication, I have asserted for some years that the Applicability Statement subset of the standards track, defined in RFC 2026, could perfectly well be used for explaining how a group of RFCs fit together. There have been various proposals for more specific methods than that which haven't caught on, but the real problem has already been mentioned: Nothing was done for want of workers ;-) It is a lot of work. I've done it for IETF process RFCs and even that was a lot of work: http://www.ietf.org/about/process-docs.html Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What If....
On 2011-02-26 10:34, bill manning wrote: The IANA function was split? RFC 2860 already did that. It seems to work well. http://www.ntia.doc.gov/frnotices/2011/fr_ianafunctionsnoi_02252011.pdf I'm glad to see they are up to date: Paper submissions should include a three and one-half inch computer diskette in HTML, ASCII, Word or WordPerfect format (please specify version). Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC production center XML format usage, was: [IAOC] xml2rfc and legal services RFPs
On 2011-02-25 05:38, Andrew Sullivan wrote: On Thu, Feb 24, 2011 at 05:11:00PM +0100, Henrik Levkowetz wrote: The ratio of gripes against idnits to actual bug reports is getting to be a bit annoying; and I'd like to suggest that people either submit bug reports, or direct the complaints against the requirements of 1id-guidelines.txt rather than against the tool which checks the requirements if the problem is that the requirements are too strict. You're quite right that I'm using idnits as a portmanteau for the whole 1id-guidelines checking at submission bundle. My apologies for being imprecise. I am indeed complaining about the latter and not about the former. For the record, I positively like the facts that the submission tool carries out basic conformance checks and that 1id-guidelines is picky. 1. I like this as an author, because it avoids me having to check things as a separate step (until the draft is ready for AD review). 2. I like this as a reader and reviewer of drafts, because it leads to a very useful degree of uniformity in the way drafts are laid out. And while I'm at it, I like the fact that xml2rfc does a lot of fiddly stuff for me that I always found a pain in the neck with other methods. Yours, A Satisfied Customer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] xml2rfc and legal services RFPs
Bob, On 2011-02-22 08:23, Bob Hinden wrote: John, Support for the xml2rfc tool was discussed on the IETF mail list when Marshall Rose indicated he could no longer support the tool. Several people volunteered to maintain the tool, and they recommended the it be rewritten. That recommendation plus the realization that this tool had become critical to IETF operations resulted in the IAOC deciding to issue a public RFP for a rewrite. The Statement of Work in the xml2rfc RFP was reviewed and modified by the people on the tool-development list. You can read the discussion at: http://www.ietf.org/mail-archive/web/tools-development/current/maillist.html There was an active discussion that resulted in many changes from what was first proposed. While this wasn't the whole community I think it a good representation of the people who are interested in the xml2rfc tool. I will send you the list members off line. Also, we will use a subset of this group to review the bids. I think the tools development list was a good venue for the detailed discussion. Was the process mentioned on tools-discuss too? (I dropped off that one a while back, due to lack of cycles, but it does seems the obvious place, not to mention the xml2rfc list, where I don't recall it being mentioned). The legal services RFP was developed inside the IAOC/Trust. To be honest, I didn't see very much value in doing a community review for this. We will consider it in the future. I do note that this work was previously done without a public RFP (dating back to when Wilmer-Hale was providing the service) so I think this is a better process than what was used earlier. In the future, we will strive to give more notice to the community on planned RFPs. I think that is appropriate, given the comments in BCP 101 about transparency. But I agree that for legal services, our community doesn't particularly have the skills to wordsmith an RFP. Brian Bob p.s. I will forward your specific comments to tools-discuss. On Feb 19, 2011, at 8:49 AM, John C Klensin wrote: Hi. This is not an attempt to derail either of these RFPs, nor is it a formal appeal (request for review). However, these two RFPs raise an issue that may be worth some consideration. The clear intent of the discussions leading up to RFC 4071/ BCP 101, and some of text in that document, was that the IASA was to act with maximum transparency to the community and openness to community comment. It is especially important that substantive decisions be open for community review and discussion before they are made because, especially for those that are eventually represented by contracts, there is no mechanism for review later. IASA has recently issued two RFPs -- for legal services and for a reprogrammed version of xml2rfc -- with no advance indication to the community (at least that I can find) that they were coming or opportunity for the community to review draft provisions. The clear expectation is that proposals will be submitted (on a fairly short timeframe) and that the IAD and IAOC will do whatever they do to evaluate the proposals and establish contracts. I don't know whether that is harmful in these particular cases, but I don't believe it is how the community had intended that things be done. FWIW, community discussion might have improved at least the XML2RFC one -- either the details of the RFP or community confidence that it addresses/includes the right specifications. For example, of the very large number of extensions or additions that have bee requested over the years, the RFP selects two (explicit line breaks in titles) and alternate anchors for citations/references) but ignores the others. I know that the ability to easily index and cross-reference items in bulleted lists, to easily generate numbers for ABNF productions (rules) and build an index of productions, to have indexing reflect section (and other subdivision) numbers rather than page numbers (as various RFC style guides have required for years and that becomes particularly important as people contemplate non-paginated output formats), the ability to properly reference books and journal articles without resorting to odd tricks involving seriesInfo, and better handling of widows and orphans (especially with regard to section title-text and lists with undented headings top my personal list, but there are certainly others. In addition, one of the two extensions that was specified involves the addition of a new format-specific directive that is exclusive to xml2rfc, not the DTD/Schema, thereby making equivalent processing by other, XML-standard, processors problematic and violating the fundamental principle that generic markup does not specify formatting. Perhaps community members might have been able to propose design models that are more friendly to XML principles and other tools (even I can think of
Re: World IPv6 Day and Us
On 2011-02-17 03:47, Livingood, Jason wrote: Parts of the challenge here is that turning on IPv6 (publishing a ) can also cause brokenness for users that have no IPv6 connectivity, e.g., those relying on broken 6to4 relays. This has been documented all over the place, for example here: http://ripe61.ripe.net/presentations/162-ripe61.pdf So even if there are very few IPv6 eyeballs, this event can serve to flush out that flavor of brokenness. As I understand it, part of the idea of everyone moving together is to get people to see the brokenness across multiple sites, thus to blame the network not the content provider, thus to pressure the networks to fix things. Richard is exactly right on where a lot of value is. This is an opportunity to find and fix the ~0.05% level of brokenness. Even non-participating ISPs will need to take steps to prepare, and this is of course a great forcing function within companies to ask what their IPv6 plans and to begin/continue IPv6 technical training, etc. Over in v6ops, we have had some vigorous discussion about the anycast 6to4 brokenness and there is a draft: draft-carpenter-v6ops-6to4-teredo-advisory My hope is that this will be in good enough shape prior to June 8th that it can contribute to the day. Discussion welcome on the v6ops list. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 2011-01-27 16:29, Scott O. Bradner wrote: 1/ I still do not think this (modified) proposal will have any real impact on the number of Proposed Standard documents that move to a (in this proposal, the) higher level since I do not see how this makes any significant changes to the underlying reasons that documents have not progressed in the past - i.e., I see no reason to think that this proposal would change the world much (would not help, would not hurt) I tend to be more optimistic. I think that having only one step ahead to reach final status is *much* less of a psychological barrier, and the name Internet Standard is a *much* more appealing target than Draft Standard. Therefore, I believe this change will be a significant step forward. 2/ I think the proposal must specifically deal with the 2026 IPR licence requirement in section 4.1.2 If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. I strongly agree. This exact sentence should be carried forward. The requirement can be dealt with by explicitly discarding it or by including it. But not mentioning the requirement does not make the issue go away. This requirement was, in theory, a way to keep the IETF/IESG out of the business of evaluating the fairness of licensing terms. I can remember only one time it came up (in an appeal) so getting rid of it may be fine - but don't make it look like it was just forgotten. 3/ I think you also be quite specific as to how to decide that the conditions for advancement have been met - one of the big implementation issues with 2026 was knowing how to decide that a technology was ready to be advanced (did you need a spreadsheet listing all features and noting with ones had been multiply implemented (as was done at huge effort for HTTP 1.1) or is there someting simplier - clear rules would help avoid this type of issue in the future Whike I agree with Scott, I suggest solving this outside the BCP itself. It's quite a complex issue. 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. this requirement was included to try to remove cruft from protocols as they went forward - maybe this is no longer a desire but, like with the license issue, a specific mention of what has been decided would mean that people would not think that things were not just forgotton. Actually the draft does not appear to require interoperability testing at all: * There are a significant number of implementations with successful operational experience. Is that intentional? I thought interop was generally regarded as fundamental. So I think the text needs to be explicit about which bits of section 4.1.2 of RFC 2026 still apply. Or expand the sentence by adding , including interoperation between different implementations when meaningful. (It's when meaningful because some standards such as MIB modules don't interoperate as such, see RFC 2438.) On another point: 5. Open Question Regarding STD Numbers IMHO the easiest solution is still what I suggested some years ago: retain STD numbers, but assign them at the PS stage. That removes the confusion about a PS that updates a numbered Standard. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 2011-01-30 09:52, Dave CROCKER wrote: On 1/29/2011 12:10 PM, Brian E Carpenter wrote: On 2011-01-27 16:29, Scott O. Bradner wrote: 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the ... Actually the draft does not appear to require interoperability testing at all: * There are a significant number of implementations with successful operational experience. Is that intentional? I thought interop was generally regarded as People are confusing testing with use. Those are two different kinds of interoperability, with the latter being far more stringent. The new draft specifies the latter. And it quite intentionally does not specify the former. Please point to the text that requires *any* kind of interoperability being demonstrated by running code. successful operational experience does not state or imply interoperation between independent implementations. This is a big change in principle from 2026, which is not what is advertised on the box as primarily a reduction from three IETF standards track maturity levels to two. I want a two stage process, but I don't want to lose interoperability as an explicit criterion. To me, that's always been the meaning of the running code slogan. Brian While testing is extremely important for when doing development, there is no reason that the IETF should be required to include that very intermediary activity within our standards process. So the new proposal has two phases: 1) Specification 2) Use That there are intermediate real-world phases, such as development, testing and deployment is essential, of course. But there is nothing essential in having the IETF mark completion of any of those intermediate phases. d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
Hi Scott and John, I don't see this as inconsistent with the current 2-stage proposal, if the latter's omission of a requirement for independent interoperable implementations for stage 2 is corrected. I don't, however, believe that the problems are separable. The bar for PS has crept up, IMHO, precisely because the bar for DS/STD has appeared too high to be readily attainable. So I see two ways forward that hang together: 1. draft-bradner-restore-proposed + (draft-housley-two-maturity-levels + independent interoperable implementations) 2. draft-loughney-newtrk-one-size-fits-all-01 (i.e. simply abolish the second and third stages, and make interoperability reports optional) I prefer #1. Regards Brian On 2011-01-30 11:39, Scott O. Bradner wrote: I've previously expressed my opinion that proposals to muck with the number of steps in teh IETF standards process will no do anything useful (i.e., will not be effective) - JOhn and I have just posted what, to us, would be a prerequisite for amy process mucking proposal to succeed Scott - From: internet-dra...@ietf.org To: i-d-annou...@ietf.org Subject: I-D Action:draft-bradner-restore-proposed-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Restoring Proposed Standard to Its Intended Use Author(s) : J. Klensin, S. Bradner Filename: draft-bradner-restore-proposed-00.txt Pages : 6 Date: 2011-01-29 Restore the very low bar for Proposed Standard described in RFC 2026 (BCP 9) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bradner-restore-proposed-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Just Thinking (About the Nightmare Transition Ahead)
What nightmare? I find IPv6 dual stack works just fine. However, see draft-wing-v6ops-happy-eyeballs-ipv6 Regards Brian Carpenter On 2011-01-23 04:34, Sabahattin Gucukoglu wrote: My thought right now is perhaps of an OS update that includes a background client which tries very hard to reduce the effect of breakage or delay caused by IPv6 routes that are dead, DNS queries that don't go anywhere, and delays caused by slow transition techniques. It couldn't be comprehensive, but I think it'd go a long way at this point. The software vendors could, for instance, provide the test sites that receive IPv6 probes and/or traffic, and respond to them. Not scalable? ... Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
Firstly, I agree: as a general rule, to get official floor space of any kind at the IETF venue, you SHOULD have posted a draft. If there is no draft, that is exactly when you need a bar BOF. (Complicated joke about the height of the bar for a bar BOF, and the drafts to be drunk, goes here.) Second, a number of operators' meetings have a session for lightning talks with minimal formality. But in practice, we have that at most Area Meetings - post a relevant draft, ask the ADs for a 5 minute slot, and you usually get it. So I'm not sure that we have a gap in our options. I'm more likely to read a draft with an interesting title than to walk around reading hard-copy posters. Regards Brian Carpenter On 2011-01-07 09:16, Worley, Dale R (Dale) wrote: From: Sam Hartman [hartmans-i...@mit.edu] I think the bar of producing an internet draft is low enough. Regardless of what mechanisms we adopt to give people a chance to try and sell their drafts, I think it is critical that we require the drafts to be written. Actually, the bar for writing an I-D is near zero, so it should not be a barrier to presenting any idea, no matter how half-baked. A more significant effect is that an I-D is in text form rather than poster form so it tends to direct the writer to a more thought-through presentation. But most importantly, an I-D is globally available and globally announced, whereas a poster session at an IETF meeting would be inherently limited to those physically present, which is biased toward frequent attendees, those with sponsorship from large organizations, and those from the developed world. Historically, the IETF has tried to limit biases in favor of those groups. Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG position on NAT traversal and IPv4/IPv6
In any case, there are four facts of life that can't be ignored: 1. We have a BEHAVE WG and it has a charter. 2. We'd better hope that as many protocols as possible can traverse NAT64, which will be with us for many years. 3. An important protocol that needs to traverse NAT44 is called IPv6 (in a tunnel). 4. Address scopes with limited reachability are plentiful, and the boundaries between them need to be traversed. The problem is a bit more than just NATs. Oh, there's a draft that mentions this: draft-carpenter-referral-ps-01.txt, to be discussed on the gr...@ietf.org list. Brian On 2010-11-15 18:19, Hadriel Kaplan wrote: Hi, In one of the working group meetings this past week, when the group was discussing a NAT traversal solution for their new protocol, an A-D suggested they not spend much time on NAT traversal. He/she indicated the IESG was discouraging NAT traversal mechanisms for new protocols, in order to foster demand for IPv6 instead. The A-D further noted that we really want it to run over IPv6 more than we want it to run over IPv4. After being asked for clarification he/she said that if you build something that will encourage people to stay on IPv4 longer, when you send it into the IESG you will get pushback. I am not going to name the WG nor A-D, because I'd rather encourage A-D's to speak their mind, and it doesn't matter who it was. Also, anyone can make a mistake or be mis-interpreted, and perhaps that's all this was. (We don't read written prepared statements at the mic, after all :) What I'd like to know is the IESG's position with respect to protocols trying to make themselves work around NATs in IPv4. I'd like to know if the IESG will push back on new protocols if they attempt to work around NATs. I would also like to understand the IESG's position with respect to IPv6 and whether protocols should not attempt to make themselves work around potential IPv6 NATs; and more importantly to handle the possibility that the firewall-type policies which NATs have by nature, may continue to be used in IPv6 on purpose even if addresses/ports don't get mapped. I appreciate the workload you are always under, but I think it's important for us outside the IESG to know. If this is not the right medium/process for asking such questions, my apologies... and please let me know the right way. :) Thanks, -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] Badges and blue sheets
On 2010-11-13 02:02, Phillip Hallam-Baker wrote: The general tenor of this conversation seems to be: * Paper badges that reveal our names: BAD - Privacy risk! * RFID badges that allow our movements to be recorded: Cool - Technology! How about paper badges with 2D barcodes? That's exactly what we had in Beijing (on the back). No barcode readers around, though. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Badges and blue sheets
On 2010-11-12 12:32, Lawrence Conroy wrote: ... Do I think the introduction of badge police to control access to IETF WG meetings is a big deal? I think that freeriders attending our meetings without paying their share of costs would be a big deal. I think that patent trolls attending our meetings without identifying themselves and signing the blue sheets would be a big deal. I am very happy to have my badge checked and I would be even happier if the blue sheets could be automated. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternative Proposal for Two-Stage IETF Standardization
Hi, I could live with this. I could live with draft-housley-two-maturity-levels. I could also live with draft-dawkins-pstmt-twostage (2003), or draft-atkinson-newtrk-twostep (2006), or even draft-carpenter-newtrk-twostep (2005). For that matter I could live with draft-loughney-newtrk-one-size-fits-all (2006). We do, after all having running code proof that a single stage standards process works just fine. (In case that isn't obvious, the running code is called 'the Internet' and the single stage is called 'proposed standard'.) Just one tiny nit in draft-crocker-ietf-twostage-00. 'IS' is the abbreviation for International Standard, as in IS8473. It's worth steering clear of that confusion. Beyond that, I just don't care which variant we choose. Regards Brian Carpenter On 2010-11-10 04:24, Dave CROCKER wrote: Folks, A few of us have formulated an alternative proposal for streamlining the IETF standards process. We hope that it at least adds to the mix of discussion in the community. d/ Original Message Subject: I-D Action:draft-crocker-ietf-twostage-00.txt Date: Tue, 09 Nov 2010 07:15:02 -0800 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d-annou...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Two-Stage IETF Standardization Author(s) : S. Dawkins, et al. Filename: draft-crocker-ietf-twostage-00.txt Pages : 8 Date: 2010-11-09 RFC 2026 specifies a three-stage Standards Track. As currently practiced, IETF standards track documents typically attain only the first stage. This proposal discusses the problems caused by the disparity between documented procedures and actual practice, and proposes a simplified, two-step standard track, which will streamline the IETF standardization process, with distinct benefits for each stage. Clarification of the criteria for handling documents re- submitted as Proposed Standard is also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crocker-ietf-twostage-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Provider-Aggregated vs Provider-Independent IPv6 addressing
On 2010-11-09 13:54, Templin, Fred L wrote: During the IPv6 panel at the plenary last night, representatives of several major service providers discussed their experiences with IPv6. It became clear that many of their experiments involve technologies that delegate Provider-Aggregated (PA) IPv6 prefixes to the customer instead of Provider-Independent (PI) ones. This fact did not seem to be at the forefront of the service providers' use case considerations, and perhaps needs to be brought to a level of awareness in the community. Many years ago, there was an extended debate on this list regarding PA vs. PI. Emotions ran high, and in the end there seemed to be a consensus favoring PI. Have we forgotten about that? Is it time to re-open the debate? Not on this list, please. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
On 2010-11-08 15:26, The IESG wrote: The IESG is seriously considering a WG and BOF scheduling experiment. The goal of the experiment is to provide WG agenda sooner and also provide more time to craft BOF proposals. The proposed experiment includes three parts. First, schedule all BOFs for Monday afternoon. Hmm. How many non-overlapping time slots? It would be extremely frustrating if there was a lot of overlap between BOFs. Some of us are interested in almost any new topic. My first reaction is to prefer the BOFs spread out. I'm not sure that concentrating them will reduce the problem of clashes. Second, schedule WGs before we know which BOFs will be held. That is a feature of concentrating the BOFs, but I'm not sure that it's particularly valuable. It moves the clashing problem, but doesn't remove it. Finally, provide an additional four weeks to deliver BOF proposal to ADs. Do you mean: make the BOF request cutoff later? If so, that is a feature, but since people are deadline driven, I'm not sure that moving the deadline is a major advantage. Please let us know whether you support this experiment. Discussion is welcome on the mail list and the plenary on Wednesday evening. It depends on my first question: how many BOF-BOF clashes would we get as a result? Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 2010-10-26 13:22, Barry Leiba wrote: I'd like to hear from the community about pushing forward with this proposal or dropping it. I see disagreement with the proposal, but we'll see disagreement with any proposal. I see enough support to continue pursuing it, in my opinion, and trying to find a balancing point that enough of us can agree with. I am happy to agree to what the draft currently says. We've sliced and diced this many times over the years, and this seems very close to the least-unpopular view. That's the best we can hope for, imho. Brian I'd like to see work continue. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 2010-10-13 12:46, Phillip Hallam-Baker wrote: The original idea seems to have been that IPSEC would be a big enough incentive to upgrade. I've been keeping out of this conversation because I have other things to do, like working on effective technologies for v4/v6 coexistence, but I have to protest at this version of the IPv6 is more secure myth. I don't think anybody ever advanced this as a serious technical incentive. What was always pointed out is that IPv6 use of IPsec doesn't have to deal with NAT traversal, which was an issue for IPv4 use of IPsec, until RFC 3948 came along in 2005. Since then, even the weak form of the more secure myth has been indefensible. I am of course discounting bogus marketing arguments. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Another +1 from me. And with respect to the alleged mistake made 15 years ago, two facts may help: 1. The transition model was complete - because it was based on vendors and ISPs supporting dual stack globally well *before* IPv4 exhaustion. It's because that didn't happen that we have a bit of a panic now. It didn't happen because short term economic incentives triumphed over enlightened self interest. Fine, lesson learned, let's move on, which the ISPs are now doing. 2. There is, mathematically and logically, no 'backwards compatible' IP with bigger addresses than IPv4. That's because IPv4 doesn't contain any provision for extensible addresses. So please let's not hear complaints that IPvN isn't backwards compatible; it never could have been and never will be, and that is the fault of the IPv4 design. So the issue of interworking between legacy IPv4-only systems and the world of bigger addresses is an unavoidable fact of the physical universe. Which is why BEHAVE is currently doing NAT64. Regards Brian Carpenter On 2010-10-09 06:02, james woodyatt wrote: everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
On 2010-10-09 11:42, Martin Rex wrote: Brian E Carpenter wrote: 1. The transition model was complete - because it was based on vendors and ISPs supporting dual stack globally well *before* IPv4 exhaustion. Huh? Hardly anyone support IPv6 these days. Sorry Martin, to write it more clearly: The transition model in 1995 was based on the assumption that vendors and ISPs would support dual stack globally well *before* IPv4 exhaustion. The fact that this did not happen is the problem. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
existing (and questionable) application designs [was Re: US DoD and IPv6]
On 2010-10-07 13:57, Fernando Gont wrote: On 06/10/2010 05:40 p.m., Keith Moore wrote: It's perfectly reasonable for applications to include IP addresses and port numbers in their payloads, as this is the only way that the Internet Architecture defines to allow applications to make contact with particular processes at particular hosts. Some might see this as a deficiency in the Internet Architecture, but that's the best that we have to work with for now. If anything, the fact that this is is the only way that the Internet Architecture defines... doesn't make it reasonable. So basically you're arguing to impair the ability of applications to function, just so that network operators can futz around with addresses. No. I'm arguing that you should not blame NATs for broken application designs, and that you should not assess reasonable-ness based on existing (and questionable) application designs. The problem is that the creation of disjoint addressing realms (due to NAT and to IPv4/IPv6 coexistence) has made distributed application design almost impossible without kludges. See draft-carpenter-referral-ps-01 Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 2010-10-01 16:14, James M. Polk wrote: At 09:59 PM 9/30/2010, Brian E Carpenter wrote: Since you asked, I'd like to see this move forward as quickly as possible. Just one practical issue seems to be hanging. The draft says: This document makes no change to the current STD practice; however, this topic deserves further discussion by the whole community. Fair enough. But what happens to the existing STD numbers on the transition day? - Do existing full Standards keep their existing STD number as they are renamed Internet Standard? (I suggest: yes.) - Do existing Draft Standards acquire an STD number as they are renamed Internet Standard? (Pragmatically, I suggest no, unless they already obsolete or update an existing STD.) Brian I'm not sure I agree on your second point (specifically on your position of no). You're misunderstanding my no. I fully agree that we are moving existing DSs and existing STDs into a single bucket. It's just a practical matter - the existing STDs each have an STD number, and the existing DSs don't have an STD number. I'm simply suggesting that on transition day, we don't bother to synthesise an STD number where none exists. That may be what Russ intended to say, but is wasn't clear when reading the text. What happens later w.r.t. STD numbers is off topic. Brian DSs have achieved a demonstrable hurdle that PS couldn't - by definition - by achieving independent interoperability. TO group DSs back with PSs is unfair and IMO, rather inappropriate. Said another way, when looking at the current PS, DS and FS within the standards track - what sufficiently differentiates these 3 into two groups? I would argue provable interoperability is that differentiation, which is why I wouldn't back-step DSs into the category that PSs will move into. I would progress them into where FSs are going, i.e., the Internet Standard category. of course, other opinions may think otherwise... James Regards Brian Carpenter On 2010-09-02 08:02, Russ Housley wrote: Dear IETF community: I just posted an update to draft-housley-two-maturity-levels. I tried to reflect what I heard during the plenary discussion in Maastricht. Please review and comment. Thanks, Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 2010-09-28 13:59, Marshall Eubanks wrote:
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29, 2003,
which said that:
the DoD has established the goal of transitioning all DoD networking to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case to
convert, it will happen, but otherwise not'.
Does this surprise anyone with experience with the DOD ? It doesn't me.
It sound to me like a case for the phrase often used by my late colleague
Mervyn Hine at CERN, when the management performed a U-turn: Aha! Reality has
broken in again.
The fact is that official mandates are not a very good reason for
upgrading systems. Running out of a resource is a much better one.
http://www.potaroo.net/tools/ipv4/
Brian
Regards
Marshall
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which said
that:
... waiver submissions for programs not transitioning to IPv6 by FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be required.)
I suppose that technically the seeming current course fits within that
updated
policy, but it still seems to be a change in emphasis and direction.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Phill,
On 2010-09-28 16:25, Phillip Hallam-Baker wrote:
The US DoD is running out of IPv4 space?
Where did I say that?
I very much doubt it.
Maybe, maybe not... how would we know?
Problem with the idea that resource depletion will drive adoption of IPv6 is
that it ignores the fact that people who have plenty of IPv4 addresses may
not be that worried about the inability of others to get hold of them.
Sure, and those people can live in their own little world, until
something changes. Then, they either have a plan in place, or they panic.
And some people are going to see ways of keeping out the competition. Their
view of IPv4 will like the view of the medallion owners who keep New York
Taxis expensive and hard to find even though there is no shortage of drivers
willing to work.
Yes, just as incumbent telcos fought against the Internet twenty years
ago, until something changed.
The reason IPv6 is still at the project stage is that the designers had the
wrong view of economics. You don't make IPv6 attractive by making it
different to IPv4, you make it attractive by eliminating all the
differences.
If only life was that simple, Phill. In any case, we can't rewrite history,
and many operators are well beyond project and well into plan.
Content providers who aren't into plan have a problem coming up if they
still want to grow their audience a few years from now.
Brian
On Mon, Sep 27, 2010 at 10:20 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 2010-09-28 13:59, Marshall Eubanks wrote:
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris
Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need
or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the
Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29,
2003,
which said that:
the DoD has established the goal of transitioning all DoD networking
to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case
to
convert, it will happen, but otherwise not'.
Does this surprise anyone with experience with the DOD ? It doesn't me.
It sound to me like a case for the phrase often used by my late colleague
Mervyn Hine at CERN, when the management performed a U-turn: Aha! Reality
has
broken in again.
The fact is that official mandates are not a very good reason for
upgrading systems. Running out of a resource is a much better one.
http://www.potaroo.net/tools/ipv4/
Brian
Regards
Marshall
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from
August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which
said
that:
... waiver submissions for programs not transitioning to IPv6 by
FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be
required.)
I suppose that technically the seeming current course fits within that
updated
policy, but it still seems to be a change in emphasis and direction.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom 2010-2011: READ THIS: Important Information on Open Disclosure
Tom, On 2010-09-22 04:29, NomCom Chair wrote: Hi Folks, A few folks have submitted some very helpful comments and I'd like to share the answers publicly. Q: If the List is Open why does it require a Login? A: As interpreted by this NomCom, the list is disclosed to the IETF community but remains confidential within the IETF community. Note the wording in RFC 5680: The NomCom may disclose a list of names of nominees who are willing to be considered for positions under review to the community, in order to obtain feedback from the community on these nominees. The disclosure is only to the community. You must have a community login to see the list. ... Q: Can I disclose the Open List of Willing Nominees outside the IETF community? Can I copy and distribute it or make it publicly available outside the community? A: Well, I am not a lawyer but I would advise not to. This NomCom interprets the Open Disclosure as disclosing confidential information to the community as supported by the wording in RFC 5680. Maybe this is a bit over simplified, but if I tell you (i.e., the Community) something confidential that does not mean you (i.e., a member of the Community) can tell others. NomCom is doing the disclosing to the group known as the IETF Community. The IETF Community members are not authorized by this NomCom to disclose it further. Keep the list within the community. I am a bit mystified. Since the IETF is open to anyone who cares to participate, there is no finite community within which to keep this list (or any other non-confidential information). Once the list of willing candidates is released, it is just as public as anything else in the IETF, as far as I can see. RFC 5680 is pretty clear about this: The process change described in this document allows the NomCom to openly solicit information about nominees who are willing to be considered. and The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom 2010-2011: Open disclosure of willing nominees
On 2010-09-21 14:07, NomCom Chair wrote: Hi Folks, The first open disclosure of willing nominees for the IETF open positions is now available at https://wiki.tools.ietf.org/group/nomcom/10/input/ Now I am a little more confused. When I follow this link and use my tools login, I find the GUI for providing confidential feedback to NomCom, as I have seen it for the last few years. Of course that still has to exist, and requires acceptance of the confidentiality of such feedback. Logging in to give feedback is entirely appropriate. But it's not the simple publication of a list, which is what 5680 added. My expectation was that this would just be posted at http://www.ietf.org/nomcom/ Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Time Shifting of Internet Traffic
On 2010-09-14 13:46, Phillip Hallam-Baker wrote: I am not finding the net neutrality debate according to K-Street to be very useful or stimulating. +1. No, +100. At the end of the day we have a limited amount of bandwidth available and we can help matters if people co-operate where it is in their interests. Whether or not we choose to do so does not in any way justify using the fact that I have limited choices in bandwidth provider to ensure that my options for content and/or VOIP telephone service are similarly limited. One area that might be fruitful for cooperation is in bulk time shifting of traffic. I am not so much talking about packet level prioritization here. I am thinking more of when I choose to back up my systems over the net. RFC 3662 is aimed at this sort of application. Whether it has been usefully deployed, I cannot say. Brian The way I look at it, the net is a bit like the power grid in that there is an opportunity to reduce capacity requirements by shifting tasks from peak to off-peak. In particular I have several RAID arrays that I would like to back up with a total of something like 2Tb of data. At present there is no incentive for me to play nice other than the risk that my activities will clog my local net. In fact it is arguably in my interest to do at least some of my backups at peak time when I am not using the net since that encourages my ISP to upgrade their circuits. I don't actually do that but others might. It would be nice if there was some way that really high bandwidth apps that can tolerate long latency could negotiate a good time to do this sort of thing so as to minimize inconvenience. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On 2010-09-15 04:36, Bob Braden wrote: On 9/14/2010 8:11 AM, Florian Weimer wrote: * Noel Chiappa: I actually vaguely recall discussions about the TOS field (including how many bits to give to each sub-field), but I can't recall very much of the content of the discussions. If anyone cares, some of the IENs which document the early meetings might say more. See RFC 760, which seems remarkably up-to-date: A few networks offer a Stream service, whereby one can achieve a smoother service at some cost. That might have been only a sideways acknowledgment of ST-II. Not to mention that at the time, the great competitor for all this new-fangled connectionless datagram stuff was X.25, a pay-per-connection and pay-per-byte stream service. As PHB says, intentions back then hardly matter anyway. Maybe we can leave this debate to some USA local discussion list where it belongs? Those of us in the economies where there is competition on the local loop are not that interested. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Revised IAOC Administrative Procedures draft
On 2010-09-13 02:21, Henk Uijterwaal wrote: Adrian, I have absolutely no doubt of the integrity of the IAOC and its chair, but this rule is somewhat vague and open to interpretation. It is like using the word appropriate in a protocol spec! Yes, true, but this is really a rare exception. In the 1.5 years that I've been on the IAOC, I don't remember a case where expenses were made and reimbursed. That makes it hard to be more precise here. Could you look at qualifying this in some way to scope the exceptional circumstances. Perhaps payment of expenses would be made only if the payment has been agreed before the expense was incurred? If the IAOC members wanted to claim expenses that should not be reimbursed, this rule would be easy to circumvent. If this is a concern, then I'd suggest that the IAOC simply publishes what expenses were paid. Yes, RFC 4071 (BCP 101) says The IAOC shall set and publish rules covering reimbursement of expenses, and such reimbursement shall generally be for exceptional cases only. iirc this was originally put in to cover corner cases such as an IAOC member suddenly finding him/herself between jobs and needing to attend a meeting, or something like that. But it does appear that the IAOC is obliged to publish rules. I suggest doing that as a separate document. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The Evils of Informational RFC's
On 2010-09-09 09:08, Richard L. Barnes wrote: s/Informational RFCs/independent stream/ If what you're after is RFC == IETF, shouldn't we be eliminating the independent submission process instead of informational RFCs in general. Things like RFC 3693 or draft-ietf-geopriv-arch, which don't specify a protocol, but describe an architecture, seem to properly be Informational, but still reflect IETF consensus. Er, this whole discussion is hardly new, and is the reason that both RFC 1796 and RFC 5741 were produced. I think we all understand why there need to be non-normative IETF documents; RFC 2475 is a good example. Therefore, RFC /= normative. We also have good reasons for publishing IAB and IRTF documents, which by their very nature cannot be normative. Therefore, RFC /= IETF. Finally, we are an open community encouraging a diversity of views, and it's sometimes necessary (and often desirable) to publish material from the community that meets none of the above criteria. Hence the Independent stream of RFCs. As everyone should know, the independence of the Independent stream is now guaranteed by a much more robust process than before (RFC 4846 and RFC 5620). Since RFC 4846 gives a complete explanation of why the Independent series exists, I won't repeat it here. Incidentally it took me quite a while to accept the last point. My own initial reaction to the Independent Submission stream was that it enabled end runs. However, there are solid mechanisms in place to prevent that. I think arguments given in RFC 4846 are convincing. In any case, you can't put this toothpaste back in the tube. Brian (all IMHO, but I am a member of both the RSAG and the ISEB, which are explained at http://www.rfc-editor.org/RFCeditor.html) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The Evils of Informational RFC's
On 2010-09-09 11:25, Richard L. Barnes wrote: Finally, we are an open community encouraging a diversity of views, and it's sometimes necessary (and often desirable) to publish material from the community that meets none of the above criteria. Hence the Independent stream of RFCs. As everyone should know, the independence of the Independent stream is now guaranteed by a much more robust process than before (RFC 4846 and RFC 5620). Since RFC 4846 gives a complete explanation of why the Independent series exists, I won't repeat it here. Echoing somewhat Eric's original point -- we have the web now. There are a multitude of fora in which material that doesn't meet the above criteria can be published. Why does it need to be part of the RFC series, other than the fact that we've always done it? In one word: archival. In several words: systematic archival rather than the vagueness of transient URLs and search engine caches. Obviously, that presupposes a judgment that the document is worthy of archival, which is why there is an editor and an editorial board. Brian I fail to find any of the justifications in RFC 4846 all that persuasive. Choosing a few examples: o Discussion of Internet-related technologies that are not part of the IETF agenda. o Critiques and discussions of alternatives to IETF Standards-Track protocols. The potential for such critiques provides an important check on the IETF's standards processes and should be seen in that light. o Informational discussions of technologies, options, or experience with protocols. o Technical contributions (e.g., RFC 1810 [RFC1810]). These discussions happen all the time, all over the Internet. My favorite recent example: http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars One venue more or less for these discussions isn't going to make a huge difference, and using the RFC stream for them simply causes confusion as to what's a real RFC. o Informational publication of vendor-specific protocols. Nowadays, vendors have web sites that describe their protocols. See, for example: http://code.google.com/apis/gears/geolocation_network_protocol.html --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
Sigh. It's hard to resist tendentious messages. I have two questions for Mr Bennett. Q1. message from our public relations agency To whom or what does our refer in this phrase? Q2. Does your signature block: Richard Bennett Senior Research Fellow Information Technology and Innovation Foundation Washington, DC imply that you are making a statement on behalf that foundation? Regards Brian Carpenter (writing only for himself) On 2010-09-08 11:26, Richard Bennett wrote: I think you should have shared the message from our public relations agency that started this incident, Russ. Here's what it said: -- IETF Chair speaks on Paid Prioritization - Thursday, September 2, 2010 I note the recent discussion in the U.S. media in connection with 'paid prioritization' of Internet traffic and the claim that RFC 2474 'expressly contemplating paid prioritization.' This characterization of the IETF standard and the use of the term 'paid prioritization' by ATT is misleading. The IETF's prioritization technologies allow users to indicate how they would like their service providers to handle their Internet traffic. The IETF does not imply any specific payment based on prioritization as a separate service. Melissa Kahaly Assistant Vice President http://www.fd.com/ 88 Pine Street, 32nd Floor New York, NY, 10005 T +1 (212) 850-5709 F +1 (212) 850-5790 M +1 (732) 245-8491 www.fd.com http://www.fd.com/ A member of FTI Consulting Inc. - This clearly isn't Russ Housley speaking as an individual, this is the IETF Chair making an official statement. The statement is misleading as RFC 2474 neither *implies any specific payment* nor *denies any specific payment*. RFC 2475, RFC 2638, and RFC 3006 are plenty clear on the relationship of technical standards to commercial arrangements. And yes, the Architecture RFCs are classified as Informational but that doesn't stop the Proposed Standards from referencing their requirements as RFC 3246 does: In addition, traffic conditioning at the ingress to a DS-domain MUST ensure that only packets having DSCPs that correspond to an EF PHB when they enter the DS-domain are marked with a DSCP that corresponds to EF inside the DS-domain. *Such behavior is as required by the Differentiated Services architecture* [4 http://tools.ietf.org/html/rfc3246#ref-4]. It protects against denial-of-service and theft-of-service attacks which exploit DSCPs that are not identified in any Traffic Conditioning Specification provisioned at an ingress interface, but which map to EF inside the DS-domain. [Footnote 4] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, An Architecture for Differentiated Services, RFC 2475 http://tools.ietf.org/html/rfc2475, December 1998. I don't have any desire to limit Russ Housley's free speech rights, but it's clear from all the evidence that he approached the press as the Chairman of IETF with a statement to make about the argument between ATT and Free Press, and it's the statement in the official capacity that bothers me. I wouldn't take up the IETF's time with a personal disagreement between Russ' interpretation of DiffServ and anyone else's, but this issue is clearly far beyond that. Finally, the term paid-prioritization wasn't coined by ATT, it comes from the statement by Free Press that ATT was criticizing. In Free Press' usage it means any departure from FIFO behavior for a fee. RB On 9/7/2010 3:52 PM, Russ Housley wrote: Richard: Russ said to the press that he considers ATT's belief that the RFCs envisioned payment for premium services implemented over DiffServ or MPLS to be invalid. This is not what I said. I said 'misleading.' The letter from ATT jumbles some things together. ATT makes many correct points, but in my opinion, a reader will get a distorted impression from the parts of the letter where things get jumbled. Adding to this situation, it is clear to me that the term paid prioritization does not have the same meaning to all readers. If you read the ATT letter with one definition in your head, then you get one overall message, and if you read the letter with the other in your head, then you get a different overall message. I tried to make this point. This was captured pretty clearly in the article by Eliza Krigman: | The feud boiled down to what it means to have paid | prioritization, ... As I said on Friday, I made the point that DiffServ can be used to make sure that traffic associated with applications that require timely delivery, like voice and video, to give preference over traffic associated with applications without those demands, like email. Unfortunately, it is not simple, and I said so. I used an example in my discussion with Declan McCullagh. I think that Declan captured this point in his article, except that he said 'high priority', when I
Re: My comments to the press about RFC 2474
On 2010-09-08 11:26, Richard Bennett wrote: I think you should have shared the message from our public relations agency that started this incident, Russ. Here's what it said: As Marshall indicated, this seems to have no public existence outside of the present thread. However, let's assume it has gone through some dark side media channels... -- IETF Chair speaks on Paid Prioritization - Thursday, September 2, 2010 I note the recent discussion in the U.S. media in connection with 'paid prioritization' of Internet traffic and the claim that RFC 2474 'expressly contemplating paid prioritization.' This characterization of the IETF standard and the use of the term 'paid prioritization' by ATT is misleading. The IETF's prioritization technologies allow users to indicate how they would like their service providers to handle their Internet traffic. The IETF does not imply any specific payment based on prioritization as a separate service. Melissa Kahaly Assistant Vice President http://www.fd.com/ 88 Pine Street, 32nd Floor New York, NY, 10005 T +1 (212) 850-5709 F +1 (212) 850-5790 M +1 (732) 245-8491 www.fd.com http://www.fd.com/ A member of FTI Consulting Inc. - This clearly isn't Russ Housley speaking as an individual, this is the IETF Chair making an official statement. The word official is really overloaded. Nothing the IETF does is official; all our standards are voluntary standards; they all fall under a DISCLAIMS ALL WARRANTIES boilerplate. So, we can discuss whether Russ was quoted in his capacity as IETF Chair; and if so, I have no problems with that, because... The statement is misleading as RFC 2474 neither *implies any specific payment* nor *denies any specific payment*. I really do not see any respect in which the quote from Russ is in any way misleading. Your statement about RFC 2474 is true. So is Russ' statement. They are simultaneously true. Russ is simply stating what I said the other day: the IETF says nothing about business practices or prices; RFC 2474 is an example of saying nothing. RFC 2475, RFC 2638, and RFC 3006 are plenty clear on the relationship of technical standards to commercial arrangements. For 2475, see my comment below. 2638 is a for the record publication of some pre-IETF work; it is not an IETF document. 3006 is irrelevant - it relates to intserv, not diffserv. And yes, the Architecture RFCs are classified as Informational but that doesn't stop the Proposed Standards from referencing their requirements as RFC 3246 does: In addition, traffic conditioning at the ingress to a DS-domain MUST ensure that only packets having DSCPs that correspond to an EF PHB when they enter the DS-domain are marked with a DSCP that corresponds to EF inside the DS-domain. *Such behavior is as required by the Differentiated Services architecture* [4 http://tools.ietf.org/html/rfc3246#ref-4]. It protects against denial-of-service and theft-of-service attacks which exploit DSCPs that are not identified in any Traffic Conditioning Specification provisioned at an ingress interface, but which map to EF inside the DS-domain. I really don't understand why you are picking this particular nit, but you are picking it all wrong. Unfortunately this RFC predates the practice of separating normative and informative references, but the normative statement in the above is the sentence containing MUST. You do not need to read RFC 2475 to understand the normative statement. Therefore, RFC 2475 is not a normative reference. The sentence starting Such behavior is explicative, not normative. Not that it matters, anyway. Nowehere in the diffserv documents is there any substantive discussion of pricing. The most I can find is this single sentence in 2475: Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service. Full disclosure: I was co-chair of the diffserv WG, so I know both the intent and the content of the documents quite well. And as co-chair, I whacked down any attempt to discuss pricing whenever it came up in discussion. Excuse me shouting, but is it hard to understand that WE DON'T TALK ABOUT PRICING IN THE IETF? http://en.wikipedia.org/wiki/Sherman_Act [Footnote 4] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, An Architecture for Differentiated Services, RFC 2475 http://tools.ietf.org/html/rfc2475, December 1998. I don't have any desire to limit Russ Housley's free speech rights, but it's clear from all the evidence that he approached the press as the Chairman of IETF with a statement to make about the argument between ATT and Free Press, and it's the statement in the official capacity that bothers me. I wouldn't take up the IETF's time with a personal disagreement between Russ' interpretation of DiffServ and anyone else's, but
Re: My comments to the press about RFC 2474
Richard, Diffserv deals with multiple different queuing disiplines, which may or may not be priority based. Please read RFC 2475 and if you like, B.E. Carpenter and K. Nichols, Differentiated Services in the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494. Brian On 2010-09-04 07:57, Richard Bennett wrote: DiffServ is a prioritization scheme, Brian, how can you say it's not? IntServ is a reservation scheme, and DiffServ attempts to provide desired PHBs in practice by sorting packets into priority queues and invoking appropriate Link Layer facilities, which are in most cases priority-based, such as 802.11e traffic classes. What on earth could the value of DSCPs be if they didn't map to traffic classes in the data link? RB Brian E Carpenter brian.e.carpen...@gmail.com wrote: Russ, It has been consistently hard to explain that diffserv is not a prioritisation scheme, even within the technical community, let alone to the regulators and the media. I think your comments as quoted are as good as we can expect from journalists. It should be a matter of concern to all of us here that the US FCC isn't confused into regulating the technology. It would set a bad precedent for regulators in other countries. I am making no comment as to whether they should regulate carrier's charging practices; that's entirely a national matter that shouldn't concern the IETF in any way. Regards Brian Carpenter On 2010-09-03 05:47, Russ Housley wrote: I want the whole community to be aware of the comments that I made to the press yesterday. Clearly, these comments do not represent IETF consensus in any way. They are my opinion, and the reporter was told to express them as my opinion. One thing that I said was not captured quite right. The article says: With services that require certain speeds to operate smoothly, such as Internet telephony, calls are given precedence over TV, Housley said. I actually said that DiffServ can be used to make sure that traffic associated with applications that require timely delivery, like voice and video, to give preference over traffic associated with applications without those demands, like email. The whole article is copied below, and it is online here: http://www.nationaljournal.com/njonline/tc_20100902_7144.php Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
On 2010-09-04 08:13, Richard Bennett wrote: Thank you for replying Brian. I've not only read the requisite RFCs, I've also implemented DiffServ over 802.11e. My implementations, like those of everyone else who has done this, invoked the prioritization mechanisms in 802.11e. This is a very common case. Another common case implements DiffServ using 802.1d priorities. Diffserv is about layer 3 queuing mechanisms. It isn't about mapping to primitive layer 2 prioritisation. We did keep backwards compatibility with IP Precedence in diffserv, and I suppose one could implement those particular PHBs by mapping them to layer 2 prioritisation. But the more subtle PHBs like EF and AF simply cannot be mapped to preemptive priority queues without destroying their defined semantics. If you want to say that DiffServ is not itself a priority scheme but rather a system for selecting the use of priority schemes at the Data Link (or comparable facilities,) you're making a distinction that's too fine for the press. No, I am not saying that. That is IMHO a faulty interpretation of the intent of diffserv. In particular, I don't see how one can read RFC 2597 and RFC 3246 and imagine that they can be mapped to layer 2 priority. As Russ is now invoking your message to support his view that payment for premium service is contrary to the wishes of IETF, that's a problem. He's not saying that. He's effectively saying what I'm saying: payment models are outside the scope of the standards, which don't require any particular payment model in order to perform their job. Brian RB On 9/3/2010 1:06 PM, Brian E Carpenter wrote: Richard, Diffserv deals with multiple different queuing disiplines, which may or may not be priority based. Please read RFC 2475 and if you like, B.E. Carpenter and K. Nichols, Differentiated Services in the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494. Brian On 2010-09-04 07:57, Richard Bennett wrote: DiffServ is a prioritization scheme, Brian, how can you say it's not? IntServ is a reservation scheme, and DiffServ attempts to provide desired PHBs in practice by sorting packets into priority queues and invoking appropriate Link Layer facilities, which are in most cases priority-based, such as 802.11e traffic classes. What on earth could the value of DSCPs be if they didn't map to traffic classes in the data link? RB Brian E Carpenterbrian.e.carpen...@gmail.com wrote: Russ, It has been consistently hard to explain that diffserv is not a prioritisation scheme, even within the technical community, let alone to the regulators and the media. I think your comments as quoted are as good as we can expect from journalists. It should be a matter of concern to all of us here that the US FCC isn't confused into regulating the technology. It would set a bad precedent for regulators in other countries. I am making no comment as to whether they should regulate carrier's charging practices; that's entirely a national matter that shouldn't concern the IETF in any way. Regards Brian Carpenter On 2010-09-03 05:47, Russ Housley wrote: I want the whole community to be aware of the comments that I made to the press yesterday. Clearly, these comments do not represent IETF consensus in any way. They are my opinion, and the reporter was told to express them as my opinion. One thing that I said was not captured quite right. The article says: With services that require certain speeds to operate smoothly, such as Internet telephony, calls are given precedence over TV, Housley said. I actually said that DiffServ can be used to make sure that traffic associated with applications that require timely delivery, like voice and video, to give preference over traffic associated with applications without those demands, like email. The whole article is copied below, and it is online here: http://www.nationaljournal.com/njonline/tc_20100902_7144.php Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
Er, exactly what in your quotation is incompatible with what I wrote: Diffserv deals with multiple different queuing disiplines, which may or may not be priority based. ? Regards Brian Carpenter On 2010-09-04 09:34, Richard Bennett wrote: Brian's paper on DiffServ confirms the fact that prioritization is part of the standard. Here are the two relevant quotes: In the original design of IP [33], a byte known as the “type of service (TOS) octet” was reserved in the header of every packet. This was defined to contain two important fields: a three-bit “precedence” value and three TOS bits. The precedence was intended as a simple priority marker, where priority 0 got the worst treatment and priority 7 got the best. (p. 1480) The Diffserv working group has taken the approach that a few fundamental PHBs should be standardized early. These should derive from some existing experience (primarily from limited deployment and experimentation with use of the IP precedence field to select forwarding behaviors) and might be implemented using a variety of specific mechanisms. The PHBs standardized so far are as follows... • Class selector behaviors: here seven DSCP values run from 001 000 to 111 000 and are specified to select up to seven behaviors, each of which has a higher probability of timely forwarding than its predecessor. *Experts will note that the default behavior plus the class selectors exactly mirror the original eight IP Precedence values.* (p. 1487) This is very straightforward. RB On 9/3/2010 1:06 PM, Brian E Carpenter wrote: Richard, Diffserv deals with multiple different queuing disiplines, which may or may not be priority based. Please read RFC 2475 and if you like, B.E. Carpenter and K. Nichols, Differentiated Services in the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494. Brian On 2010-09-04 07:57, Richard Bennett wrote: DiffServ is a prioritization scheme, Brian, how can you say it's not? IntServ is a reservation scheme, and DiffServ attempts to provide desired PHBs in practice by sorting packets into priority queues and invoking appropriate Link Layer facilities, which are in most cases priority-based, such as 802.11e traffic classes. What on earth could the value of DSCPs be if they didn't map to traffic classes in the data link? RB Brian E Carpenter brian.e.carpen...@gmail.com wrote: Russ, It has been consistently hard to explain that diffserv is not a prioritisation scheme, even within the technical community, let alone to the regulators and the media. I think your comments as quoted are as good as we can expect from journalists. It should be a matter of concern to all of us here that the US FCC isn't confused into regulating the technology. It would set a bad precedent for regulators in other countries. I am making no comment as to whether they should regulate carrier's charging practices; that's entirely a national matter that shouldn't concern the IETF in any way. Regards Brian Carpenter On 2010-09-03 05:47, Russ Housley wrote: I want the whole community to be aware of the comments that I made to the press yesterday. Clearly, these comments do not represent IETF consensus in any way. They are my opinion, and the reporter was told to express them as my opinion. One thing that I said was not captured quite right. The article says: With services that require certain speeds to operate smoothly, such as Internet telephony, calls are given precedence over TV, Housley said. I actually said that DiffServ can be used to make sure that traffic associated with applications that require timely delivery, like voice and video, to give preference over traffic associated with applications without those demands, like email. The whole article is copied below, and it is online here: http://www.nationaljournal.com/njonline/tc_20100902_7144.php Russ -- Richard Bennett Senior Research Fellow Information Technology and Innovation Foundation Washington, DC ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
Richard, This will be my last message on these points, which were beaten to death in the diffserv WG some years ago. assured or expedited services, except nobody really knows how that might actually work in a real scenario (or maybe they do, and it's just us humble developers who don't.) I can't speak for those who have implemented EF and AF queuing algorithms; they will have to speak for themselves. Am I missing something when I find a gap in the dialog? I don't see the gap. There are a few references to possible differential payments in some of the informational documents concerning diffserv, and nobody denies that differential pricing is possible. There are no elements in the normative specifications of diffserv that serve in any way to support accounting, pricing or charging. We can't control what choices the carriers in one particular country such as the USA adopt; and it's not our business. The fact that journalists don't read the bit at the beginning of each RFC that defines its status is something that we've been used to for many years. Regards Brian On 2010-09-04 10:36, Richard Bennett wrote: Let's go back to your original comment, the one that Russ has quoted elsewhere. You said: It has been consistently hard to explain that diffserv is not a prioritisation scheme, even within the technical community, let alone to the regulators and the media. Your clarification is that DiffServ deals with multiple queuing disciplines, which may or may not be priority based and you get into EF and AF that in most implementations will end up using dedicated facilities of some sort, although service providers may be able to use these dedicated facilities for generic traffic if there's no EF or AF to send. I can see why it's hard to explain this subtle distinction. You're saying here on the list that DiffServ is a higher level abstraction than prioritization that neither requires nor precludes prioritization to implement premium services. That's fine, but if you want to say that DiffServ is *completely removed from the realm of prioritization,* you have to explain away the grandfathering of IP Precedence into the standard. I think that you mean to say that DiffServ is *more than* a prioritization scheme, it's a general architecture for Internet QoS. But even that's not correct. In fact, DiffServ is an Internet QoS architecture that explicitly offers priority-based services by design, and may also offer other types of assured or expedited services, except nobody really knows how that might actually work in a real scenario (or maybe they do, and it's just us humble developers who don't.) Russ said to the press that he considers ATT's belief that the RFCs envisioned payment for premium services implemented over DiffServ or MPLS to be invalid. I find this puzzling as there are numerous references to payment for premium services in the RFCs ATT cites, such as RFC 2638: At the risk of belaboring an analogy, we are motivated to provide services tiers in somewhat the same fashion as the airlines do with first class, business class and coach class. The latter also has tiering built in due to the various restrictions put on the purchase. A part of the analogy we want to stress is that best effort traffic, like coach class seats on an airplane, is still expected to make up the bulk of internet traffic. Business and first class carry a small number of passengers, but are quite important to the economics of the airline industry. The various economic forces and realities combine to dictate the relative allocation of the seats and to try to fill the airplane. We don't expect that differentiated services will comprise all the traffic on the internet, but we do expect that new services will lead to a healthy economic and service environment. Am I missing something when I find a gap in the dialog? RB On 9/3/2010 3:11 PM, Brian E Carpenter wrote: Er, exactly what in your quotation is incompatible with what I wrote: Diffserv deals with multiple different queuing disiplines, which may or may not be priority based. ? Regards Brian Carpenter On 2010-09-04 09:34, Richard Bennett wrote: Brian's paper on DiffServ confirms the fact that prioritization is part of the standard. Here are the two relevant quotes: In the original design of IP [33], a byte known as the “type of service (TOS) octet” was reserved in the header of every packet. This was defined to contain two important fields: a three-bit “precedence” value and three TOS bits. The precedence was intended as a simple priority marker, where priority 0 got the worst treatment and priority 7 got the best. (p. 1480) The Diffserv working group has taken the approach that a few fundamental PHBs should be standardized early. These should derive from some existing experience (primarily from limited deployment and experimentation with use of the IP precedence field to select
Re: My comments to the press about RFC 2474
Russ, It has been consistently hard to explain that diffserv is not a prioritisation scheme, even within the technical community, let alone to the regulators and the media. I think your comments as quoted are as good as we can expect from journalists. It should be a matter of concern to all of us here that the US FCC isn't confused into regulating the technology. It would set a bad precedent for regulators in other countries. I am making no comment as to whether they should regulate carrier's charging practices; that's entirely a national matter that shouldn't concern the IETF in any way. Regards Brian Carpenter On 2010-09-03 05:47, Russ Housley wrote: I want the whole community to be aware of the comments that I made to the press yesterday. Clearly, these comments do not represent IETF consensus in any way. They are my opinion, and the reporter was told to express them as my opinion. One thing that I said was not captured quite right. The article says: With services that require certain speeds to operate smoothly, such as Internet telephony, calls are given precedence over TV, Housley said. I actually said that DiffServ can be used to make sure that traffic associated with applications that require timely delivery, like voice and video, to give preference over traffic associated with applications without those demands, like email. The whole article is copied below, and it is online here: http://www.nationaljournal.com/njonline/tc_20100902_7144.php Russ = How Neutral Is The Internet?: Existing Limits Are In The Spotlight As ATT And A Consumer Advocacy Group Squabble Over Net Traffic by Eliza Krigman Thursday, Sept. 2, 2010 Whether the Internet is truly a democratic forum was called into question this week in a dispute about Internet traffic management between ATT and the consumer advocacy group Free Press. The feud boiled down to what it means to have paid prioritization, a phenomenon viewed as anathema by advocates of Internet openness, and to what extent preferential treatment of content already takes place. The issue is at the very heart of a broader debate about what regulatory steps are necessary, if any, to ensure the Internet remains an engine of economic growth and a platform of equal value to people across the socioeconomic spectrum. ATT, in a letter filed with the Federal Communications Commission on Monday, argued that paid prioritization of Internet traffic, contrary to claims made by Free Press, is already a common practice of Web management and consistent with protocols set by the Internet Engineering Task Force. Largely unknown to people outside the technology field, IETF is a professional organization composed of engineers that develop standards for the Internet; for over two decades, it has played an integral role in the management of the Internet. The current chair of the IETF, Russ Housley, disagrees with ATT's assessment. ATT's characterization is misleading, Housley said. IETF prioritization technology is geared toward letting network users indicate how they want network providers to handle their traffic, and there is no implication in the IETF about payment based on any prioritization. Dedicated lines of service, according to ATT, are examples of current paid prioritization schemes, a concept Free Press flatly disagrees with. ATT constructed bogus interpretations of 'paid prioritization' that reflect no arguments or statements made by the FCC or any proponents of net neutrality, said S. Derek Turner, research director of Free Press. The group calls paid prioritization an anti-consumer practice where third-party content owners can pay an Internet service provider to cut to the front of the line in Web traffic. It's a practice that would lead to a pay-to-play scenario where only big business could afford the premium channels needed to compete, net neutrality advocates say, thereby squeezing the little guys out of the market. But ATT dismisses those assertions, saying Free Press' acceptance of dedicated lines of service as a management practice is hypocritical given its stance against paid prioritization. We understand why Free Press is upset with our letter, said Michael Balmoris, spokesman for ATT. We outed them by shedding light on their inconsistencies. After all, for years Free Press has used empty rhetoric and faux-technical mumbo jumbo to demonize any paid prioritization. In the conclusion of its letter, ATT implored the FCC not to limit or ban paid prioritization, positing that it would be contrary to the goals of innovation, investment, and growth and contrary to the interests of small, medium-sized, and minority-owned businesses. Most professionals in the telecommunications and Internet field acknowledge that some content already does get right of way on the Web. The debate hinges on to what extent it is appropriate and whether paying for priority
Re: Is this true?
It's certainly true that you need to use security products that support IPv6 as well as they support IPv4. If they don't, change vendors. Apart from that, it's scare-mongering. Consider that the basic model for IPv6 is not fundamentally different than IPv4; why would the underlying security vulnerabilities be fundamentally different? I happen to be aware that a serious independent analysis of IPv6 security is being carried out, and hopefully will appear in the not too distant future. It will not be scare-mongering, judging by the draft I've seen. Regards Brian Carpenter On 2010-08-27 08:51, jean-michel bernier de portzamparc wrote: IPv6 in the press http://www.theregister.co.uk/2010/08/06/ipv6_security_nightmare/ Portzamparc Internet User ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Is this true?
On 2010-08-27 11:10, Dave CROCKER wrote: On 8/26/2010 2:27 PM, Brian E Carpenter wrote: Apart from that, it's scare-mongering. Consider that the basic model for IPv6 is not fundamentally different than IPv4; why would the underlying security vulnerabilities be fundamentally different? well, just to give that question its due, interesting changes in details can sometimes produce interesting changes in the behavior of a model and therefore of its implications. in this case, the vastly larger address space of IPv6 permits attackers to switch to new addresses at a rate that was not possible with IPv4. this is likely to defeat the substantial infrastructure of attack-tracking that is address-based, such as for anti-spam. True, but the same property means that scanning attacks are infeasible against IPv6 subnets. Attack tracking based on subnets may work fine, though. Swings and roundabouts. Anyway - nobody is saying that there are no security issues with IPv6. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Is this true?
On 2010-08-27 11:36, Dave CROCKER wrote: On 8/26/2010 4:24 PM, Brian E Carpenter wrote: On 8/26/2010 2:27 PM, Brian E Carpenter wrote: why would the underlying security vulnerabilities be fundamentally different? ... True, but the same property means that scanning attacks are infeasible against IPv6 subnets. Attack tracking based on subnets may work fine, though. Swings and roundabouts. Your original comment was about differences in vulnerabilities. You asserted that there was no fundamental difference and I was observing that one difference that is clear and is already of concern to the anti-spam/anti-abuse community does quality as a fundamental difference. (It is likely to render and entire infrastructure of address-based white- and black-listing useless.) Anyway - nobody is saying that there are no security issues with IPv6. How is your statement, above, not saying /exactly/ that? We must interpret the word fundamental differently. The fundamental issue we are getting at in your example is basically that it's trivial to forge layer 3 addresses in a connectionless datagram network running without cryptograhic signature of every packet. The exact exposures and countermeasures differ between IP versions, of course. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
DPE and Nomcom [was Re: IETF Attendance by continent]
On 2010-08-08 03:11, Doug Ewell wrote: Marshall Eubanks tme at americafree dot tv wrote: We do have some data on this point - the day pass experiment (DPE) has shown pretty conclusively IMO that the IETF does not get a lot of truly local ad-hoc participants. Most day pass attendees appear to be regular attendees who could only make it to that particular IETF for one day for whatever reason, not local people who just wanted to sample an IETF meeting. It has long been known that IETF meetings have a local attendance effect. I thought, before the DPE, that this indicated a potentially large number of observers, presumably interested, but not interested enough to travel long distances due to the cost and time required for longer trips. This, to me, suggested that day-passes, at a reduced rate, would bring out a lot of new people (as the time and financial burden would be even less). This did not happen, on any of the 3 continents where the DPE has been run. At least on the surface, this does make it appear that the decision to exclude day-pass attendees from NomCom, on the basis that such attendees would not have the requisite experience, is driven by financial considerations after all. Not at all. Firstly, it's only now that there are even marginally enough data to analyse the impact of day passes - previously, all we had was guesswork. Secondly, the argument is quite clear - people who parachute into an IETF week for one day, for whatever reason, cannot possibly gain the experience of a full week's participation (for example, witness the breadth and depth of an AD's work, or properly understand the interaction of WG meetings, BOFs, Bar BOFs and corridor discussions). That undermines the whole purpose of measuring meeting attendance as a Nomcom qualification. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
On 2010-07-30 08:47, Dave CROCKER wrote: On 7/29/2010 10:00 PM, Fred Baker wrote: If we're going to continue this avalanche of ad hoc meetings that we call Bar BOFs, I would recommend that the Secretariat provide a web page for requesting them. The title of the web page should be Poorly Planned Meetings or something like that. In other words, let's make unofficial, ad hoc meetings be formal and scheduled. Fred, like you, I'm delighted to see the activity. However just because there is interest in having formal, scheduled activities that are not qualified to be BOFs, we do not need to have IETF administration support them with extra services. Let's let these self-initiated efforts remain what they are. If they can garner attendees, that's fine. If they can't, better luck next time. Even with the excellent title you suggest, the web page will move these activities down the slippery slope of formality. The way to make a more rational schedule for the week is to schedule less, not more. I learned a lesson in, now where was it?, oh yes, Anaheim. I decided to have a Bar BOF, decided that the Hilton bar really wasn't convenient, borrowed a room from Marcia, invited a few people, was asked to advertise it on the wiki, and ended up with every seat taken in quite a big room. The discussion was good, but not overwhelmingly successful, and a lot of people just sat there quietly. (Admittedly, there was very little else to do in Anaheim for those over ten years old.) I wish it had just been six of us at the bar. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
Hi, I'm only going to comment on the suggested changes to the BCP. The other recommendations all seem to be reasonable additions to the general guidance for future Nomcoms. RECOMMENDATION -- Selective Exclusion * The Nomcom Chair may selectively exclude any participant from a single Nomcom activity. This action may be overridden by a majority of Nomcom Voting Members. In my own (limited) Nomcom experience I didn't see a case where this would be relevant. In fact, it seems more likely that an individual would tend to dominate *all* discussions, and this rule doesn't allow for exclusion of a member from all activity. However, I guess it does allow for handling a case of clear prejudice for or against a particular candidate. I would suggest building in a bit more check-and-balance by making it * The Nomcom Chair may, after consulting with the previous Nomcom Chair, selectively exclude... RECOMMENDATION -- Selection Pool * There needs to be assurance of a minimum presence of Nomcom voting members who have meaningful knowledge of IETF decision and leadership processes. * Therefore, create a second pool of volunteers who satisfy more stringent Nomcom participation rules. * Volunteers in this 'expertise' pool must have been on the IESG, IAB or IAOC/Trust, or have been a working group chair. These positions require a degree of direct involvement in the process of IETF leadership. * Three (3) volunteers from the 'expertise' pool are selected first. Those who are not selected from that pool are then added to the general pool of volunteers, for the second round of selection. Nomcom is not limited to having only three of its members be experienced. * (Implementation) This is a formal change to Nomcom selection rules, which will require a modification to RFC 3777. I wouldn't seriously object to this proposal, but it doesn't help with a related fundamental problem that we have: asking engineers to select other engineers for managerial (IESG), strategic (IAB) and business/legal (IAOC/Trust) jobs. The problem with putting engineers in such positions is that they tend to do engineering, sometimes known as micro-management. Quite what we can do about this I don't know, but including three engineers in Nomcom who have personal experience of micro-managing isn't going to fix it ;-). RECOMMENDATION -- Confidentiality Agreement * Everyone participating in Nomcom needs to sign a formal Confidentiality Agreement. Good idea. RECOMMENDATION -- Interview Monitoring * Liaisons must not sit in on interviews without a specific invitation I do agree that the liaisons have no place in the interview process, but I found this section confusing as to exactly what is proposed as a change to the BCP. Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The anonymity question
John Levine asked: Some people have argued that it should be possible to participate in some or all IETF processes while remaining partly or completely anonymous. Is this a reasonable expectation? No. Anonymous or pseudonymous contributions would allow a scumbag patent troll to inject ideas into a standard for which s/he held an undisclosed patent. I don't see how we can draw a line between that and other types of contribution. Regards Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
On 2010-07-18 03:48, Dave CROCKER wrote: ... At: http://www.bbiw.net/recent.html#nomcom2010 there is a copy of the Full Proposal, and a Summary which primarily contains just the recommendations. Um, we have this new system called Internet-Drafts, whereby proposals are issued by a certain cutoff date so that people have a chance to read them before a meeting. Did you consider using that system? Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 2010-07-06 08:49, SM wrote: ... The author of the draft is the current IETF Chair. I have some reservations about the IETF Chair driving such a proposal through the process. Although the IETF Chair is also an IETF participant, it can be perceived as problematic when the person writes a non-technical proposal that has to be evaluated by the IESG. It could be, but if the proposal is a matter of common sense and blindingly obvious simplification, it isn't, IMHO. Let's just do it; there is no down side. There may be many other issues, as suggested by John, but this simplification can only help everybody. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-01
On 2010-06-26 02:49, Russ Housley wrote: Phillip: Obviously, I was not General AD when this happened. However, I was Security AD at the time, so I was involved in the discussions that included the whole IESG. I made my reply to your posting because I want people to realize that there is another side to the story. We need to learn from the history, but we need to act toward improving the future. The IESG spent a huge amount of time on the NEWTRK documents in retreat. The ISD proposal hit the IESG in a very bad way. The ISD proposal required the IESG spend a lot of time that the individuals simply did not have. Further, this came at a very, very bad time. Admin-Rest had consumed way to many cycles. Perhaps the 1-step or 2-step proposals could have been separated from ISDs, but that was not the path that was taken. I do not know the reasons. I was General AD at the time. There was certainly no meeting of the minds between NEWTRK's rough consensus for the ISD proposal and the IESG's understanding of what ISDs would mean in practice. Also there was no sign of consensus in NEWTRK for moving to a 1-step or 2-step standards process as a first step, rather than ISDs as the first step. So basically we got collectively stuck. I tried setting up a special design team to unstick us and that didn't work either. Which is why, basically, I support the latest 2-step proposal, as a way to unstick this discussion and move in the direction of simplicity. Brian Russ On 6/24/2010 6:11 PM, Phillip Hallam-Baker wrote: My point is that I am unable to have any characterization whatsoever since nobody has ever told me the reason that the changes did not go ahead. And since I have asked for reasons in a plenary and never got any statement that was not phrased in the passive voice, I don't think it is unfair to describe the decision as having been made in private. If the history is not confidential then I want to know what it was. Otherwise I don't see why it is inaccurate to describe the process as top down. If the process is going to be described as consensus based and bottom up then at a minimum the people who take the decision have to be prepared to state their reasons. On Thu, Jun 24, 2010 at 3:10 PM, Russ Housley hous...@vigilsec.com mailto:hous...@vigilsec.com wrote: I strongly disagree with this characterization. In my view, too many things got bundled together, and the thing that was unacceptable too the whole bundle down. Russ On 6/24/2010 2:52 PM, Phillip Hallam-Baker wrote: Last time the reforms were blocked without the IETF at large even knowing who was responsible. It was a decision the IESG took in private as if it only affected them and they were the only people who should have a say. So much for bottom up organization. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The IPv6 Transitional Preference Problem
On 2010-06-25 20:08, Carsten Bormann wrote: On Jun 25, 2010, at 09:56, Brian E Carpenter wrote: trying v6 for a couple of seconds before trying v4 in parallel I don't think this is realistic for applications like the Web, where people are now creating Youtube-Spots with high-speed cameras that show, in slow-motion, a potato cannon fired in parallel with a web page loading (the web page is faster than the potato, of course). Shaving 50 ms off the HTTP latency is a major improvement in user experience for a Web user. I think we're talking about the initial phase of contact with a server. Obviously, once a best path is chosen, you will stick to it until there is a glitch. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-01.txt
It's been amusing to see the same old arguments going past for the Nth time. Maybe we can have a side-thread about the value of N. That said, my comment on this proposal is: ship it. It's simple, simple to implement, and it aligns RFC 2026 with current practice. So let's just do it. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 2010-05-28 04:51, David Conrad wrote: ... Well, no. While that is a problem, I suspect the real issue is: 'Within 18 months it is estimated that the number of new devices able to connect to the world wide web will plummet as we run out of IP addresses' I strongly suspect that Daniel said connect directly, which is certainly true when an ISP runs out of global IPv4 addresses. and this quote: The internet as we know it will no longer be able to grow, That's just factually incorrect Today, most users are *not* behind ISP NAT or some other form of global address sharing. A double-NATted Internet is very different from a single-NATted Internet as we know it today. and sensationalistic hype. Whether it is counter-productive depends on whether people simply dismiss it out of hand as yeah, yeah, just like the world will end at Y2K. IPv4 free pool runout simply means connecting to the Internet is going to get more expensive. No, it means it is going to require double NAT unless providers deploy IPv6. That is the message that needs to be got across. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
Patrik, Of course, the exact depletion date experienced by an ISP will vary very widely. 2015 is the date *most frequently* cited by the ISPs reported on in draft-ietf-v6ops-isp-scenarios. Regards Brian Carpenter On 2010-05-28 17:04, Patrik Fältström wrote: I also think 2015 is very optimistic for some players. Specifically cellphone providers that provide data access over for example 3G or 4G. The growth is so fast that the block allocations from the RIRs are hard to compute. I helped one at the last RIPE meeting in Prague, and then will now get a /13 that will help them through calendar year 2010. They will definitely not be able to get today the addresses they need until 2015. And they definitely do not have it. And that is in Sweden, only 9 million people. Patrik On 27 maj 2010, at 22.02, jason.w...@cox.com wrote: 2015 seems awfully optimistic. I wouldn't want to be the poor soul responsible for their ISP network who built a transition plan based on a 2015 depletion and then realized I was wrong by a few years. Jason -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, May 27, 2010 12:14 PM To: Ole Jacobsen Cc: Noel Chiappa; ietf@ietf.org Subject: Re: IPv4 depletion makes CNN On 2010-05-28 02:44, Ole Jacobsen wrote: I guess my point was more that this article actually quotes a *real* expert rather than someone we've never heard of --- a more common practice for the press. Whether or not you agree with Daniel, he does at least have extensive experience in these matters. The major problem with the story is that it confounds IANA runout (objectively predicted for 2011) with when ISPs run out of IPv4 space (which is not so easy to predict, but 2015 is a popular estimate). The rest is pretty good for a story in the non-technical media, IMHO. You can find Daniel's recent talk at http://www.ipv6.ie/summit2010/. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 2010-05-29 03:01, David Conrad wrote: On May 28, 2010, at 1:29 AM, Brian E Carpenter wrote: Today, most users are *not* behind ISP NAT or some other form of global address sharing. An interesting assertion. I'd agree on the ISP NAT part. Not sure about the other form of global address sharing part, since single NAT is address sharing. Do you have any data? Sorry, I should have written subscribers instead of users. Most subscribers get global addresses on the outside of their domestic gateway, but of course that gateway is unfortunately a NAT in most cases. IPv4 free pool runout simply means connecting to the Internet is going to get more expensive. No, it means it is going to require double NAT unless providers deploy IPv6. I've been told on numerous occasions that multi-layer NAT will significantly increase opex. Yes. It will also significantly increase breakage at application level. I understand there is plenty of running code proof of this, for example in India. That is the message that needs to be got across. I suspect your message will result in a response of Double whasis? I can still get my pr0n, right?. I'd imagine a message that says you're going to end up paying more for your pr0n will get more people's attention. In fact I think the message now should be to content *providers*, because they will bear the costs unless they pressure their ISPs into doing the right thing. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 2010-05-28 02:44, Ole Jacobsen wrote: I guess my point was more that this article actually quotes a *real* expert rather than someone we've never heard of --- a more common practice for the press. Whether or not you agree with Daniel, he does at least have extensive experience in these matters. The major problem with the story is that it confounds IANA runout (objectively predicted for 2011) with when ISPs run out of IPv4 space (which is not so easy to predict, but 2015 is a popular estimate). The rest is pretty good for a story in the non-technical media, IMHO. You can find Daniel's recent talk at http://www.ipv6.ie/summit2010/. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
On 2010-05-07 11:20, Dave CROCKER wrote: On 5/6/2010 3:58 PM, Marshall Eubanks wrote: On May 6, 2010, at 6:45 PM, John C Klensin wrote: This seems completely reasonable. And to me too. +1 +1 Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Post-Last-Call document-RFC Changes
Bob, I hope we all agree with that. There can be a difficulty, however, if the apparently obvious and correct technical fix actually has implications beyond the obvious that might be picked up by renewed WG discussion or even a repeat Last Call. But I think we would be foolish to legislate on this or to mandate the overhead of a new draft in every case. Let's leave it to the judgment of the RSE, document authors, shepherd and cognizant AD to decide if wider discussion is needed in a particular case. Brian On 2010-04-23 08:23, Bob Braden wrote: If I may comment from my position as ex-RSE, the RFC Editor's policy for at least the past 10 years has been to fuss at authors who ask for substantive changes in AUTH48, but then to follow the dictum: better to get it right than get it early. In other words, the RFC Editor did push back but generally did not refuse suhstantive changes in AUTH48. Bob Braden John Klensin wrote, in part: The one change that, IMO, might be worth making in this regard would be to explicitly empower the RFC Editor to push back, if necessary by going back to the community, if, in their judgment, substantive changes that deviate from the approved document are requested at AUTH48. My own view is that they have always had the ability to do that although I don't believe it has been exercised since the AUTH48 procedures were created. I have no opinion as to whether there are cases in which it should have been. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP
I see that this (still the same version) is On agenda of 2010-05-06 IESG telechat, and I must say I'm a little surprised, since I counted seven clear objections to the document and no strong supporting comments. Also, IANA said IANA does not understand the implications of the IANA Actions requested. That would seem to be a problem. I hate to say this, knowing from personal experience how hard it is to get consensus on any such topic, but I really don't see how this can go forward without considerable modification. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Rationale for public, non-subscribable mailing lists
On 2010-04-19 08:29, Florian Weimer wrote: I've recently tried to subscribe to the SECDIR list. Apparently, this list is public (it's archived on the web), but one cannot subscribe to it. The question is: Why would anyone configure things this way? It's really, really odd. (It was suggested to me that I posted something to the SECDIR list, that's why I tried to subscribe to it first. It's not that I care very much about this particular mailing list. I'm just curious about the phenomenon in general.) Because IETF teams should operate in public view as much as possible, and particularly teams whose main job is document review. But by simple logic, only team *members* will actually be on the list. I agree, it occasionally leads to list moderation issues. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Public musing on the nature of IETF membership and employment status
On 2010-04-09 07:08, Donald Eastlake wrote: On Thu, Apr 8, 2010 at 7:14 AM, Roni Even ron.even@gmail.com wrote: If this is true it make me wonder why does the IETF care about the affiliation of WG chairs and ADs Roni Even The reason traditionally given that IETF participants in general give their affiliation is for purposes of individual identification. The reason there is concern about too many people with the same affiliation in positions where they judge consensus or the like is to avoid situations where the organization with which they are affiliated would appear to or would have the possibility to dominate. There is that, and there is the issue of making it harder to pack a WG, so that when a hum or straw poll is taken, a particular company's preferred choice is over-represented. It's perfectly reasonable for a WG Chair who is judging a consensus call to reduce the weight of support for a particular option if s/he *knows* that all its supporters just happen to work for the same company. Otherwise, the rough consensus process could be subverted. We don't always feel comfortable talking about this, but that doesn't make it untrue. Brian (whose recent IETF trips have been funded by Huawei, not by my university) The only hard and fast rules about this in the IETF that I know about are that nomcom volunteers are required to give their affiliation and no more than two voting nomcom members can have the same affiliation. Whether this rule is good or bad is a matter of judgement but it was adopted after multiple cases where more than two randomly selected voting nomcom members had the same affiliation and some people felt this created the impression of dominance. Thanks, Donald *From:* ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] *On Behalf Of *Mark Atwood *Sent:* Tuesday, April 06, 2010 7:17 PM *To:* ietf@ietf.org *Subject:* Public musing on the nature of IETF membership and employment status Much of what makes the IETF work is how it is very different from other standards bodies (such as IEEE, ANSI, ISO, NIST, ITU, etc etc). One key difference is that groups do not join the IETF. Cisco, IBM, MCI, or Linden Lab are not a members of the IETF. No agency of the US government, or of any other government, is a member of the IETF. No university, non-profit, PIRG, PAC, or other concerned citizens group, is a member of the IETF. Only individual people can be members of the IETF. And membership is mostly defined as who shows up on the mailing list and who shows up at the meetings. There have been many cases in the history of the IETF where well known members who are in the middle of writing standards or of chairing various important working groups, who have worked for well-known large companies, will change employers, to other companies, to startups, or to personal sabbaticals switch around between industry, academia, research, and government, and this will not, does not, and should not, affect their position inside the IETF at all. It appears that sometimes people, inside and outside of the IETF, need to be reminded of this. If you want to write standards like the IEEE and ITU do it, you know where you can find them. But when you choose to participate in the IETF process, that is how it works. And if someone feels that anyone's change in employment status should affect their standing in any part of the IETF process, that person has missed the point, and needs to be pointedly reminded of their mistake. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Public musing on the nature of IETF membership and employment status
On 2010-04-07 05:57, Melinda Shore wrote: On Apr 6, 2010, at 9:56 AM, Andrew Sullivan wrote: I thought we didn't have members? I've always liked to refer to people doing work here as participants for exactly that reason. Right. Or contributors when they contribute and therefore subject themselves to our IPR rules. BTW please look at the paragraph headed Participation at http://www.ietf.org/newcomers.html, which I drafted. Do people agree with that summary? Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP
Olafur, In my mind there are basically three kinds of IETF working groups: 1) New protocols/protocol extensions frequently with limited attention to operations. 2) Protocol maintainance groups 3) Operational groups RFC2119 words are aimed at the first type, and can to limited extend be used by the third type, in the case the recommendations are static. As the second and third types of groups will become more common and contentious it is important to think about how to clearly allow these groups to express guidance in selecting options. I'm all in favour of making things easier for people trying to use our standards. I don't believe that adding duplicative terminology to the IANA registries is the right way to do it; I believe that will only *increase* confusion and the risk of ambiguity. Something like draft-ietf-newtrk-repurposing-isd seems much more hopeful but never reached IETF consensus. Meanwhile, to repeat myself, why don't WG's write Applicability Statements as defined in 1996 by BCP 9 (RFC 2026) section 3.2? We've had this mechanism for 14 years, maybe it's time to test it. Regards Brian Carpenter On 2010-03-20 06:58, Olafur Gudmundsson wrote: On 19/03/2010 12:14 PM, Paul Hoffman wrote: At 10:33 AM -0400 3/19/10, Olafur Gudmundsson wrote: Well here a proposed problem statement for the requirement: How does an implementer of a protocol X, find which ones of the many features listed in registry Y, he/she needs to implement and which ones are obsolete. and How does an evaluator of an implementations assess if implementation Z is compliant with current recommended state of protocol X. The second problem my draft is addressing is: How to express the implementation and operational level of support. RFC2119 words only apply to IMPLEMENTATIONS. This problem statement does not match the one in the draft. The one here is a better problem statement, and it already has a simple solution: write an RFC that say This RFC defines X; a sending implementation must be able emit A and SHOULD be able to emit B; a receiving implementation must be able to process A and SHOULD be able to process B. This has nothing to do with the IANA registry other than A and B had better be listed there. Well it benefits from comments from the many good people that have commented on the draft after the LC started :-) I still do not believe that Publish a new RFC is the solution. It still leaves the issue of matching operations to current best practices, your statements only reflect interoperability out of the box, not what we recommend that people operate/disable/plan-for/etc. The +- words are on the right track but I think they do not go far enough. Further, there is nothing in your draft that says that X is a protocol. The draft is completely vague as to what is being conformed to. Because the definitions are trying to cover both implementations and operations. As how things have been done I think that process is broken thus I want people to figure out a better way to provide this information. So do many of us, but it is not from lack of many well-intentioned people trying to fix it: it is from a lack of consensus. The question is how do we make the system more user friendly, remember we have over 5700 RFC's published so far and we are generating almost an RFC/day. It is not unlikely that we will have RFC 9000 published before 2020! Why is this any more true now that a few years ago when the newtrk work failed? The pain is greater than it was, proposals for changes seem to get traction when certain pain threshold is reached. Have we reached it? In my mind there are basically three kinds of IETF working groups: 1) New protocols/protocol extensions frequently with limited attention to operations. 2) Protocol maintainance groups 3) Operational groups RFC2119 words are aimed at the first type, and can to limited extend be used by the third type, in the case the recommendations are static. As the second and third types of groups will become more common and contentious it is important to think about how to clearly allow these groups to express guidance in selecting options. Olafur ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Sip] Last Call: draft-ietf-sip-ipv6-abnf-fix (Essential correction for IPv6 ABNF and URI comparison in RFC3261) to Proposed Standard
Cullen, I believe that the RFC 3261 ABNF *is* plain incorrect. It allows the generation of text representations including ::: and that is clearly not intended to be allowed by the description in RFC 4291. (Being precise, it says The :: can only appear once in an address. whereas I can find it twice in :::.) Actually there is another bug too, as first noted by Markku Savela in February 1999: However, appears that this doesn't allow ::123.222.2.22 type of addresses. On the other hand, it would pass dubious things like FFF:::ip4, so I'm still looking for the correct syntax... History: the faulty ABNF first appeared in RFC 2373 but was dropped from RFC 3513 because it was known to be wrong. Unfortunately RFC 3261 picked it up from 2373. Impact: http://[2001:4860:b006:::67] fails (with Firefox and IE; I have no easy way to check it in a SIP implementation). It should fail, and should never be generated. However, I do agree that we could state in the document that implementations which *cannot* generate the faulty ::: construct do not need to be changed and that implementations that *can* accept the faulty ::: construct do not need to be changed. Implementations that disallow ::IPv4 would need to be fixed, but I suspect that is highly unlikely and a very marginal case. Regards Brian On 2010-03-19 07:11, Cullen Jennings wrote: I'm very support of this draft and think it should move forward but I have a NIT to pick with it. It says the ABNF in 3261 is incorrect and this one corrects it. I don't believe that is correct. I believe the ABNF in this draft is more specific than the one in 3261 but they are both correct. I think this is an important distinction that should be corrected in the draft and I will try and motivate why. The ABNF is what helps an implementor know what sort of parse they need to write such that it can successfully parse over unknown extensions. It also constrain what future syntax extensions can use. There is a constant pressure to make it explicitly represent the current semantic limitations of the protocol. But the ABNF is not what defines the protocol, the text in the RFC does that. For example, most ABNF that have a port number would allow a number that was greater than 2^16. We could write ABNF that limited the port number to a 16 bit integer but typically we don't and instead define the port in the text. As far as I can tell, there is nothing wrong with the ABNF in 3261, it is just less specific than we would like and this new ABNF is more specific will limit future RFC and extensions to conform with the range of syntaxes allowed by this extortion. Because of this I don't believe this should update 3261. Every time we have an update to 3261 vendors have to go thought a huge exercise and discussion with customers if their products are still compliant etc. In the case of this draft that would be a huge waste of time as clearly no code is changed by this. Cullen in my individual contributor role On Mar 5, 2010, at 4:30 PM, The IESG wrote: The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'Essential correction for IPv6 ABNF and URI comparison in RFC3261 ' draft-ietf-sip-ipv6-abnf-fix-04.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16959rfc_flag=0 ___ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use sip-implement...@cs.columbia.edu for questions on how to develop a SIP implementation. Use dispa...@ietf.org for new developments on the application of sip. Use sipc...@ietf.org for issues related to maintenance of the core SIP specifications. Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP
Christian, On 2010-03-19 05:31, Christian Huitema wrote: If the real reason for this draft is to set conformance levels for DNSSEC (something that I strongly support), then it should be a one-page RFC that says This document defines DNSSEC as these RFCs, and implementations MUST support these elements of that IANA registry. Then, someone can conform or not conform to that very concise RFC. As the conformance requirements change, the original RFC can be obsoleted by new ones. That's how the IETF has always done it; what is the problem with doing it here? Second that. Let's not overload the registry. As Edward Lewis wrote in another message, The job of a registry is to maintain the association of objects with identities. If the WG wants to specify mandatory-to-implement functions or algorithms, the proper tool is to write an RFC. Third that. In fact, this exactly the purpose of applicability statement standards track documents, as defined in RFC 2026 for many years. I have lingering sympathy for the ISD idea that John Klensin referred to, but without changing any of our rules or procedures, an applicability statement Proposed Standard could be drafted immediately. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP
In my opinion this is not ready for prime time. Basically: it's inconsistent with the requirements part of RFC 2026 and inconsistent with RFC 2119. I don't think we should create confusion by such inconsistency. There are three main aspects of this inconsistency: 1. 3.1. MANDATORY This is the strongest requirement and for an implementation to ignore it there MUST be a valid and serious reason. That is in effect the meaning of SHOULD as defined in RFC 2119: 3. SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. There is no way we can reasonably equate MANDATORY as defined in the new draft with SHOULD as defined for the last 13 years (and very widely used by other SDOs; RFC 2119 is, I believe, by far the most widely cited RFC). MANDATORY can only resonably be equated with MUST, which is defined in RFC 2119 thus: 1. MUST This word, or the terms REQUIRED or SHALL, mean that the definition is an absolute requirement of the specification. There is no escape clause. It is quite clear there must be no escape clause for MANDATORY. However, the RFC 2119 adjective that maps MUST is REQUIRED, and that should be used to map MUST into an IANA registry. There's no need to confuse people with a new word. 2. With that fixed, the draft doesn't contain a term equivalent to SHOULD. There's a perfectly good adjective for that in RFC 2119: RECOMMENDED. 3. The draft adds confusion by attempting to map the very dubious terms SHOULD+, MUST- and SHOULD-. These are not defined in our standards process and have been used in a very debatable way (IMHO), both in a handful of IETF documents and elsewhere. I simply cannot see the value of deviating from REQUIRED, RECOMMENDED and OPTIONAL. These are clear, self-defining and widely used words. There is value in adding OBSOLETE and RESERVED for use in IANA registries. There is value in the concept behind the proposed AVAILABLE: 3.7. AVAILABLE This is a value that can be allocated by IANA at any time. Implementations: Implementations SHOULD NOT use these values... However, the choice of keyword is poor. An outsider seeing that protocol number 143 is AVAILABLE might be delighted to start using it. The current word used by IANA is UNASSIGNED and that is much better. Bottom line, I am completely against this draft in its current form. It will create nothing but confusion. Regards Brian Carpenter On 2010-03-18 06:45, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Definitions for expressing standards requirements in IANA registries.' draft-ogud-iana-protocol-maintenance-words-03.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-04-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ogud-iana-protocol-maintenance-words-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19259rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP
Ah, yes, Paul is quite correct. My implicit assumption was that such keywords would be added to an IANA registry only in as far as they echo IETF standards track documents (including the deprecation or obsolescence of such documents). Of course, IANA itself cannot add normative requirements - only an IETF standards action can do that. Regards Brian On 2010-03-18 12:10, Paul Hoffman wrote: At 9:43 AM +1300 3/18/10, Brian E Carpenter wrote: In my opinion this is not ready for prime time. I agree with all of Brian's issues, and add another one that is equally, if not more, significant. This document talks about an IANA registry having entries for compliance, but does not describe what the compliance is applied to. 3.1. MANDATORY This is the strongest requirement and for an implementation to ignore it there MUST be a valid and serious reason. Implementations: To be considered compliant, all implementations MUST support this registry entry. Operations: To be considered compliant, operations MUST use at least one of the mandatory entries. Note 1: There can be more than one MANDATORY requirement. Note 2: The requirement applies only to new or future implementations on the day the requirement is released. In many cases existing implementations can become compliant via software upgrade or point release. Look at an IANA registry such as the one that prompted this draft, http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml. If there is an algorithm that is now marked MANDATORY, and your implementation did not have it, you would not be in compliance with the registry. The IETF has never had a concept of compliance to an IANA registry, which is a good thing. Suggesting that we should start doing that now is just plain wrong. It is *fine* to have an RFC specify which algorithms must be implemented / supported / whatever for compliance to the RFC; we do that now just fine. When the community agrees on changes to what is needed to comply with an RFC, you update the RFC; we now do that just fine as well. Putting new words in an IANA registry will make things more confusing, not less. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On 2010-03-16 05:42, Doug Ewell wrote: ... Note that I am not arguing in favor of plain text as the IETF standard. I just want to keep this part of the discussion real. There is no requirement anywhere that plain-text files may contain only ASCII characters. That requirement is explicit for RFCs. This was originally in RFC 2223 and its predecessors back to RFC825. Now it's in http://www.rfc-editor.org/rfc-style-guide/rfc-style Since we failed to get consensus even on the minor step proposed by http://tools.ietf.org/id/draft-hoffman-utf8-rfcs, I really don't see this conversation converging on a radical change. Also, PHB's list of options is tendentious (by referring contemptuously to teleprinter format) and ambiguous (since there is no such thing as the HTML format for RFCs). As an archival format, I am still very happy with ASCII. Guaranteed layout, trivially searchable. The tools team HTML markup is nice, but redundant as far as archiving goes. Brian (who will once again regret having risen to the bait) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What day is 2010-01-02
On 2010-03-14 10:58, Scott Brim wrote: These technical answers are all great for use in Internet protocols [3339] but the scope of the question is web pages destined for humans to read and understand ... and some humans don't understand them. You could justify what's there now and ignore their problem, or (if your goal is communication) you could figure out how to write dates in ways that ordinary humans find unambiguous. I usually write something like 2010 Jan 02. It's not sortable but it's understood even by non-IETFers. In Russia, China, Arabic-writing countries, etc.? I've preferred the 2010-03-14 format (with or without the hypens) since 1977, when I found myself installing the 770517C release of an operating system. OK, that abbreviation does incorporate the Y2K bug, but when working in an industry generally befuddled by the ambiguity between European and American date order, it's without a doubt the best we can do for a globally understandable format. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.
Andrew, Thankyou for spending time on this. On 2010-03-12 06:16, Andrew Sullivan wrote: ... It is instead an appeal that the documents were not published with disclaimers attached. Interesting. Since we're being legalistic, all IETF documents carry the standard disclaimer (by reference in recent RFCs) which says, among other things: ... DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. That seems to cover most angles. I can't see why the IESG could be expected to add technical disclaimers to a consensus document. In fact, doing so would probably be a process violation in itself. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.
I agree with Sam, for cases which would otherwise result in an endless DISCUSS - although normally I'd expect the argument to be complex enough that a separate RFC would be needed to explain the dissent. Brian On 2010-03-12 09:58, Sam Hartman wrote: Andrew == Andrew Sullivan a...@shinkuro.com writes: Andrew On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote: That seems to cover most angles. I can't see why the IESG could be expected to add technical disclaimers to a consensus document. In fact, doing so would probably be a process violation in itself. Andrew Well, ok, and yes it probably would be a violation. But to Andrew defend the appelant, there might be a serious (though in my Andrew view totally wrong) point in the appeal. For what it's worth, I think it is entirely reasonable for the IESG to add text raising technical concerns to a consensus document. The IESG note, unlike the rest of the document reflects IESG consensus, even in cases where the document is intended to reflect IETF consensus. Here's a case where I think it would be entirely appropriate for the IESG to do so. The current process--both internal IESG procedure and RFC 2026 requires some level of agreement from the IESG to publish a document. If we had a case where it was clear that there was strong community support for something that the IESG had serious concerns about, I think it would be far bettor for the IESG to include its concerns in an IESG note than to trigger a governance problem by declining the document. Another option also open to the IESG would be to write up its concerns in an informational document published later. Without knowledge of specifics I cannot comment on which I'd favor. I have not read the current appeal and doubt that adding an IESG note is the right solution to an appeal on technical grounds about a consensus document. I simply don't want a legitimate case where adding an IESG note to come up years later and people dig through this discussion and find no objections to the claim that adding such a note would be a process violation. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal to the IESG concerning the approbation of the IDNA2008 document set.
On 2010-03-11 13:09, David Kessens wrote: On Wed, Mar 10, 2010 at 03:42:12PM -0800, Dave CROCKER wrote: The prudent action is to return it to the appellant, stating that it cannot be processed until it has been made clear and concise. I fully support such an approach (and did propose the same strategy to the IESG while I was a member of the IESG myself). I agree. Our process may be complicated, but a deviation from due process that requires 145 pages of description is simply not possible. We have specific rules in RFC 2026 and RFC 2418 (and various updates) and it should be possible to describe specific alleged deviations from those rules in a page or two. If the appeal merely reflects the fact that the appellant disagrees with the WG consensus, that is not a ground for appeal. I do not believe the IESG is under any obligation to spend its precious time digesting such a mass of text to discern any actual grounds for appeal. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sip-ipv6-abnf-fix (Essential correction for IPv6 ABNF and URI comparison in RFC3261) to Proposed Standard
I'd like to note that the authors are aware that draft-ietf-6man-text-addr-representation-07 is now proposed for the standards track, and this may mean it becomes a normative reference for sip-ipv6-abnf-fix (and applicable to SIP implementations). Brian Carpenter On 2010-03-06 12:30, The IESG wrote: The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'Essential correction for IPv6 ABNF and URI comparison in RFC3261 ' draft-ietf-sip-ipv6-abnf-fix-04.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16959rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Announcing Clouds bar BoF during IETF-77 (March, 2010, Anaheim, CA)
On 2010-02-23 07:07, Michael Richardson wrote: Dan == Dan Romascanu Romascanu writes: A new alias has been created for discussion on this topic: Dan clo...@ietf.org mailto:clo...@ietf.org . Dan Do you mean a mail list? Can you provide subscribe information? The participants are aware of the work occuring in the Open Grid Forum, in the OCCI WG? My thought exactly. The distinction between cloud computing and open grid computing is very small (or possibly zero) and we have a sister standards body that has been working in this area for years. David Chadwick is the IETF liaison to the OGF. I can see an argument for additional work on the *implications* of grid/cloud computing on IETF protocols. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Announcing Clouds bar BoF during IETF-77 (March, 2010, Anaheim, CA)
Well yes, everybody's right in this area, since the terminology is so fuzzy and so infected by marketing noise. In any case, I am not for a moment saying: don't hold a Bar BOF. It seems like an excellent idea to talk about it. What I am saying is: our sister standards body the OGF seems like the natural home for this topic, and we have to be very precise in defining scope to avoid overlap and confusion. Regards Brian On 2010-02-23 10:15, Ole Jacobsen wrote: I agree with Dave and offer the following article (in two parts) for further background reading. (The second part will be available in printed form in Anaheim): http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-3/123_cloud1.html and http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-4/124_cloud2.html (Whole issues can also be downloaded in PDF format). We now return to our regular scheduled programming and discussions about how to get from various airports to Disneyland. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Mon, 22 Feb 2010, Dave CROCKER wrote: Having recently gone through the exercise of trying to understand what these different terms actually meant, I discovered that the underlying problem is that you are both right, as are a variety of other people who have other views... As already noted, the term 'cloud' is now used in many different ways, including as a synonym for 'network' and for 'Internet', even amongst technical folk. (Really.) There are some people who have very specific and nuanced technical definitions, including distinguishing cloud from grid. But no set of definitions seems to have a broad base of support. For defining 'cloud', one group I'm participating in decided it was happy with the NIST language: http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Announcing Clouds bar BoF during IETF-77 (March, 2010, Anaheim, CA)
Chuckle? Not really. This is depressing. So maybe the IETF should smile and stand back politely. Brian On 2010-02-23 14:05, Jeff Wheeler (jewheele) wrote: actually in the DMTF Telco WG we're completing a 3-month study of the metrics and data artifacts used by the various SDOs, consortia and forum currently involved in their own formal cloud standards and the count is 27, that without the vendors inter-cloud management interfaces. chuckle -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Tim Bray Sent: Monday, February 22, 2010 4:45 PM To: Scott Brim Cc: Ole Jacobsen (ole); ietf@ietf.org; clo...@ietf.org; dcroc...@bbiw.net; David Chadwick Subject: Re: Announcing Clouds bar BoF during IETF-77 (March, 2010, Anaheim, CA) If you're proposing OGF you should look at the 6 or 7 other SDOs doing useful work on clouds, e.g. the DMTF. It's a complex situation. I would have said ridiculous actually. So much standards energy, so little shipping technology. -Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On 2010-01-12 07:11, Dean Willis wrote: On Jan 11, 2010, at 11:18 AM, Paul Hoffman wrote: At 10:32 PM -0600 1/10/10, Dean Willis wrote: Very interesting, from an IETF-hosting perspective. snarkI cannot imagine going to an IETF meeting and not being able to read Wired magazine while I am there./snark So, are there likely to be problems with paper copies of the magazine at customs? Is it available at English-language newsstands? Well, it is just as relevant to suggest that you don't take the last Economist for 2009 to Malaysia for the next APRICOT meeting (naked Adam and Eve on the front cover) and don't carry pseudoephedrine tablets on your next vacation in New Zealand. Oh, and don't travel to the Anaheim IETF from Nigeria. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Announcement of the new Trust Legal Provisions (TLP 4.0)
On 2009-12-29 16:02, Sam Hartman wrote: Julian == Julian Reschke julian.resc...@gmx.de writes: Julian Marshall Eubanks wrote: ... This message is to announce that the IETF Trustees have adopted on a new version of the Trust Legal Provisions (TLP), to be effective 28 December, 2009. The Grace period for old-boilerplate will begin on that date, and last through 1 February, 2010. ... Julian So, unless xml2rfc gets updated in time, people using that Julian tool won't be able to submit Internet Drafts after February Julian 1 without additional post-processing? Why the early cut-over Julian date, compared to the last change (which had a 2+ month Julian transition period) Wait, I had assumed that the grace period had been negotiated with the tools maintainers. If not, the Trustees need to hold that negotiation and then adjust the grace period accordingly. I thought we had learned the hard way to do this every time. (Hence I have with some reluctance added to the cross-posting of this thread.) I'd like to take this a step further: why do we need to update our boiler plate at all? It's my understanding that the incoming rights have not been changed at all here; that should and I think does require a BCP. The trust is updating what rights they give others outside the IETF process. I guess Ic can see why that might affect the boiler plate the RFC editor uses. However, I don't understand why I as an internet draft author should have to join the boiler plate of the month club. I thought one reason we set up the inbound vs outbound split was to avoid exactly this sort of mess. My understanding, as a bystander, is that we really couldn't achieve that state of nirvana until the recent batch of related RFCs was out (5741 through 5745), so that all the streams, and not just the IETF stream, are covered. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate, exactly as for the Trust-maintained boilerplate. For now, there are indeed weasel words such as: However, this is not intended to specify a single, static format. Details of formatting are decided by the RFC Editor. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. I think this gives the RSE, in conjunction with the tools maintainers, reasonable flexibility. I also note: The changes introduced by this memo should be implemented as soon as practically possible after the document has been approved for publication. which is presumably intended to allow the tools some time to catch up, again requiring RSE/tools coordination. Regards Brian Carpenter On 2009-12-22 23:50, Olaf Kolkman wrote: Julian, You wrote: This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? We are at a point where making trivial changes to headers and boilerplates leads to discussion about more substantive matters and causes even more delay, folk wanted it done. It is unfortunate that the stutter (I agree its there and that its ugly) remains in the document. Headers and boilerplates lives on this tangent between community wishes, RFC oversight, and RFC Editor series continuity and style. Having learned from getting HB done, I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input. FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. --Olaf [top-post, full context below.] On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote: Julian Reschke wrote: ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see http://tools.ietf.org/html/draft-reschke-hab-01, in particular http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt (diffs). ... I just heard that the RFC 5741-to-be is not going to be fixed with respect to the stutter in the boilerplate, such as in: -- snip -- 3.1.6.2. Text of 'Status Of This Memo' This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc. -- snip -- (see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2). This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? Best regards, Julian ___ rfc-interest mailing list rfc-inter...@rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Most bogus news story of the week
On 2009-12-19 06:26, John C Klensin wrote: --On Friday, December 18, 2009 12:10 -0500 Marshall Eubanks t...@americafree.tv wrote: What's so bogus about wanting to charge for traffic? Where I would raise a flag is, charge whom ? This sounds very much like the way that international long distance used to be done. That the Internet does not support that is to me, at least, not a bug but a very desirable feature. Maybe, but charging per byte and charging more for offshore bytes are both entirely feasible for ISPs to do, and have been for many years. Therefore, it's entirely feasible for governments to tax such charges. So I'm not sure there is actually any news here. Whether you'd be willing to trust IPFIX as the way to measure traffic is another story, but really a detail. What somebody (ISOC?) should do is counter the absurd meme that the ITU is the United Nations body in charge of internet standards. But, from the perspective of many of the participants in the ITU (and some of the countries), that old regime was profoundly attractive: easy to regulate, easy to tax, easy to decide who gets to carry traffic in and out of the relevant country, etc. This goes hand-in-hand with nostalgia for various forms and properties of circuit-switched networks, especially wrt QOS, emergency services, and network management. Probably that means that precisely the things that contribute to your seeing it as a feature are things they consider bugs... or at least appropriate only for research networks. Absolutely. Charging was at the root of the old PTT monopolist's hatred of IP and their love of X.25. But that war was over many years ago. Apparently a few soldiers have just emerged from hiding in the forest, thinking the war is still in progress. Brian And then we wonder why we have trouble communicating with the ITU and assorted bellheads :-( john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-xli-behave-ivi (The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition) to Experimental RFC
Hi, I'm in favour of publishing this document. I'm wondering which of the two relevant guidelines for Experimental status in http://www.ietf.org/iesg/informational-vs-experimental.html applies in this case. Looking at the writeup in the tracker: This document presents a working example of the v4/v6 Stateless translation in an operational network, which provides useful information for the interested community. I seem to see a much closer match to guidelines 2 or 3, which lead to Informational. Regards Brian Carpenter On 2009-12-05 03:43, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition ' draft-xli-behave-ivi-05.txt as an Experimental RFC 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 2010-01-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-xli-behave-ivi-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17439rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
On 2009-12-01 23:57, Simon Josefsson wrote: Scott Brim scott.b...@gmail.com writes: Simon Josefsson allegedly wrote on 11/30/2009 10:11 AM: There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. Simon, from rfc3979: l. Reasonably and personally known: means something an individual knows personally or, because of the job the individual holds, would reasonably be expected to know. This wording is used to indicate that an organization cannot purposely keep an individual in the dark about patents or patent applications just to avoid the disclosure requirement. But this requirement should not be interpreted as requiring the IETF Contributor or participant (or his or her represented organization, if any) to perform a patent search to find applicable IPR. I don't see how this modifies anything? The legal obligation is on the IETF participant, not on the organization. The organization is not bound by this text. IANAL. But if the participant is acting as an agent of the employer, it seems to me that the employer is bound. In any case, you'd have to be a brave or reckless employee not to assume that to be the case. You'd also have to be a very obtuse employer to fund your employees to participate if you didn't like the IETF's rules. At least, that's how it's worked for the last 12 or 13 years. Brian Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
On 2009-12-01 06:03, Thierry Moreau wrote: Simon Josefsson wrote: Brian E Carpenter brian.e.carpen...@gmail.com writes: On 2009-11-24 06:44, Steven M. Bellovin wrote: On Mon, 23 Nov 2009 08:16:49 -0500 Scott Brim scott.b...@gmail.com wrote: Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM: John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose. Precisely. The conflict Simon mentions was of course known to most of the WG; that's one reason we have that clause. IMHO, BCP79 creates no particular problem for corporate lawyers who are instructed by their corporate management to ensure that the company behaves as a good citizen in its standards activities. This is strongly in the company's interests, anyway, since failure to disclose when required by a standards process threatens the validity of the patent. There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. Replying first to Simon: The requirement is indeed on individual participants and only if they reasonably and personally know about the IPR. But employees participating in an activity for their employer are (afaik, IANAL) acting as agents of their employer, and it's standard practice in most companies for them to have their legal obligations such as IPR disclosure handled by a company lawyer or IPR specialist. So the distinction really doesn't matter. I believe that we included reasonably and personally known exactly because of the problem of employees of one department of a big company not knowing what other departments were doing, and to avoid the onerous cost of a patent search for employees of companies holding tens of thousands of patents. I believe that this setting of the rules has worked well since the disclosure requirement was introduced in 1996. Hi Simon, This is certainly correct in principles. But to which extent the IETF disclosure approach is easy to work around by having two persons ... is a matter of appreciation. My understanding is that it is not easy to arrange protocol engineer rolls in such a way. I'm quite sure you don't have a clear case which you can refer to support the opposite view. The reason I am confident is that both inventor status and an IETF contributor require creativity in general. The IETF collective engineering faces technological challenges like any other design group. I guess it is not realistic to expect managers to send protocol engineers with little creativity traits to the IETF in order to preserve the ability to file patent applications without disclosure. It really is not the IETF's problem. It is a problem for a company that chooses not to behave as a good citizen. The situation remains that the IETF does not have any mechanism to apply pressure on organizations to disclose patent information. This is certainly correct, but I am afraid the cause is more profound than the above IPR disclosure work around. Specifically, the Qualcom vs Broadcom case on JVT over H.264 IPR would have taught corporate lawyers that a standardization body membership contract binding to the corporation is a must for IPR disclosure enforcement against the corporation. (I am not a lawyer ...) The IETF does not use this approach. Replying to Thierry: Again, IANAL, but I understand that participants and their employers are bound by the IETF rules by the simple fact of participation, with no need for an explicit contract. The famous Note Well text is simply a reminder of that. The IETF doesn't need to enforce anything; patent holders who break the rules will have to explain why to a judge, if someone challenges their patent in court. Of course, we can underline the point by choosing to rescind a standard if a participant is found to have broken the rules. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART LC review of draft-dusseault-http-patch-15.txt
I'm quite happy for the subject matter experts to decide between these two approaches. Thanks Brian On 2009-11-27 01:46, Julian Reschke wrote: Roy T. Fielding wrote: On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote: These are the sort of changes that would, I believe, give sufficient indication to a would-be user of PATCH of how to make it somewhat safe. Personally I'd prefer to see it made more prominent by starting with something like: Clients requiring to verify the consistent application of a patch document to a known entity SHOULD first acquire an ETag... Rationale: the use of a normative keyword will draw the attention of implementors who might otherwise not think about this issue. It would also be wrong, because it is neither a requirement for interoperation nor a potential for causing harm (RFC 2119). Aside from which, it makes the original purpose of PATCH non-compliant with its own specification. The purpose of PATCH is to request that the server apply a set of changes to the current state of the target resource. The assumption that these changes will be dependent on a specific prior representation of that resource is false. The server is fully capable of detecting and reporting conflicts when they occur with the current state, as only truly known by the server. In other words ... If the client wants to prevent the PATCH method from being applied to a resource for which the state has changed since the last state known by the client, then it SHOULD use one or more of the conditional request mechanisms of HTTP (If-Match and If-Unmodified-Since request headers [RFC2616]) or WebDAV (If request header [RFC4918]) with the associated metadata from that prior resource state. However, if the patch media type contains its own mechanism for detecting conflicts, such as embedded context or metadata designed to allow non-overlapping changes to be safely applied, then the conditional request mechanisms SHOULD NOT be used with PATCH because they would interfere with collaborative applications, such as shared editors and whiteboards. FTR, the prior sentence, that PATCH is somehow more likely to result in corrupted state than a PUT, is simply false for any patch format that contains context or post-application integrity checks. The only reason it was in the spec is because earlier versions assumed a patch format that contains nothing but byte-vector manipulations. It should be removed, or at least altered to be factual. Roy In the meantime, a new draft was published, see http://tools.ietf.org/html/draft-dusseault-http-patch-16 and http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-16.txt for the diffs. The new text is: A PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes from collisions between two PATCH requests on the same resource in a similar timeframe. Collisions from multiple PATCH requests may be more dangerous than PUT collisions, because some patch formats need to operate from a known base point or else corrupt the resource. Clients using this kind of patch application SHOULD acquire a strong ETag [RFC2616] for the resource to be modified, and use that ETag in the If-Match header on the PATCH request to verify that the resource is still unchanged. If a strong ETag is not available for a given resource, the client can use If-Unmodified-Since as a less-reliable safeguard. This text is still problematic, in that 1) It suggests that the client is in control of the etag (...acquiere a strong etag...); however, the client has no control over this at all; it's the server who decides, and also it's the server who's in charge in deciding what type of etags it accepts in which operations. 2) It doesn't mention that WebDAV defines another conditional header which doesn't have the limitations of If-Match (per RFC2616, not HTTPbis). I found Roy's proposal both easy to understand and correct, and like to see it (or something more similar to it than the current text) being used. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
On 2009-11-24 06:44, Steven M. Bellovin wrote: On Mon, 23 Nov 2009 08:16:49 -0500 Scott Brim scott.b...@gmail.com wrote: Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM: John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose. Precisely. The conflict Simon mentions was of course known to most of the WG; that's one reason we have that clause. IMHO, BCP79 creates no particular problem for corporate lawyers who are instructed by their corporate management to ensure that the company behaves as a good citizen in its standards activities. This is strongly in the company's interests, anyway, since failure to disclose when required by a standards process threatens the validity of the patent. It really is not the IETF's problem. It is a problem for a company that chooses not to behave as a good citizen. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART LC review of draft-dusseault-http-patch-15.txt
Roy, At this point I think we're arguing in a circle, so I will simply wait to see what the authors and Area Director want to do next. A Gen-ART review has no more standing than any other Last Call comment. Regards Brian Carpenter On 2009-11-18 15:18, Roy T. Fielding wrote: On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote: These are the sort of changes that would, I believe, give sufficient indication to a would-be user of PATCH of how to make it somewhat safe. Personally I'd prefer to see it made more prominent by starting with something like: Clients requiring to verify the consistent application of a patch document to a known entity SHOULD first acquire an ETag... Rationale: the use of a normative keyword will draw the attention of implementors who might otherwise not think about this issue. It would also be wrong, because it is neither a requirement for interoperation nor a potential for causing harm (RFC 2119). Aside from which, it makes the original purpose of PATCH non-compliant with its own specification. The purpose of PATCH is to request that the server apply a set of changes to the current state of the target resource. The assumption that these changes will be dependent on a specific prior representation of that resource is false. The server is fully capable of detecting and reporting conflicts when they occur with the current state, as only truly known by the server. In other words ... If the client wants to prevent the PATCH method from being applied to a resource for which the state has changed since the last state known by the client, then it SHOULD use one or more of the conditional request mechanisms of HTTP (If-Match and If-Unmodified-Since request headers [RFC2616]) or WebDAV (If request header [RFC4918]) with the associated metadata from that prior resource state. However, if the patch media type contains its own mechanism for detecting conflicts, such as embedded context or metadata designed to allow non-overlapping changes to be safely applied, then the conditional request mechanisms SHOULD NOT be used with PATCH because they would interfere with collaborative applications, such as shared editors and whiteboards. FTR, the prior sentence, that PATCH is somehow more likely to result in corrupted state than a PUT, is simply false for any patch format that contains context or post-application integrity checks. The only reason it was in the spec is because earlier versions assumed a patch format that contains nothing but byte-vector manipulations. It should be removed, or at least altered to be factual. Roy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
How about the IESG simply rescinds its decision in this week's meeting? I don't see any need for an appeal; if there's a prima facie violation of the disclosure rules, it's just a management item. Much less bother than an appeal. Of course, the rescission would be subject to appeal, but that's another story. Brian On 2009-11-19 15:02, Cullen Jennings wrote: On October 8, the IESG approved the registration of application/3gpp-ims+xml Media Type. On Nov 2, RIM filed an IPR disclosure related to this at https://datatracker.ietf.org/ipr/1219/ The associated patent, filed Oct 2008, is at http://www.google.com/patents?id=Mk7GEBAJ and the related draft is http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling I will note John-Luc Bakker from RIM is an author of both the patent and and the draft. The draft has been widely discussed at IETF with no mention of IPR before this. As an IESG member, I was not aware of this IPR at the time the approval was made and I do not believe any other IESG members were aware of it. I do believe the discussion would have been different had the IESG been aware of this IPR. If anyone thinks this is, ah, inappropriate, I would recommend they appeal the IESG decision to approve this. (see section 6.5 of RFC 2026 for how this works). An IETF LC on this in the future would allow the community to make an decision that was informed of the IPR. Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART LC review of draft-dusseault-http-patch-15.txt
These are the sort of changes that would, I believe, give sufficient indication to a would-be user of PATCH of how to make it somewhat safe. Personally I'd prefer to see it made more prominent by starting with something like: Clients requiring to verify the consistent application of a patch document to a known entity SHOULD first acquire an ETag... Rationale: the use of a normative keyword will draw the attention of implementors who might otherwise not think about this issue. Brian On 2009-11-18 05:03, Julian Reschke wrote: John C Klensin wrote: ... 1) the client can't control whether the etag will be strong, and weak etags may work just fine in certain instances, so just be silent about the type Silent, no. But saying can't control... certain instances explicitly would be fine. I'd be even happier with an explanation of what such an instance might look like, but don't see that as a requirement. ... It's up to the server to decide whether it provides strong or weak etags. And it's also up to the server to decide whether you can use them in a conditional PATCH request (RFC 2616 disallowed this, but HTTPbis is lifting that restriction, and furthermore WebDAV never had it). I think not stating this explicitly is the simplest approach (as this is true for any HTTP method), but I wouldn't object to have more text either (as long as that text wouldn't have to revised when HTTPbis is done). BR, Julian ___ Gen-art mailing list gen-...@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
In fact, lightning talks are SOP at most operator group meetings. I think that would be an excellent experiment. Brian On 2009-11-17 22:39, Eliot Lear wrote: As a life-long fan of the Gong Show, I think it'd be cool to have a big Gong on the dias, where perhaps after a bunch of loud hums, an AD or IAB member finally satisfies the audience. This could happen sooner or later, depending on whether we're talking about topic (1) NATs, (2) The standards process, or (3) Venue location. But perhaps there's another approach that won't be quite so, well, base. To me, if someone wants more than 2 minutes to make a point, perhaps that person should request a short agenda slot. Here's a little process experiment: why not slot 20 minutes for such time at one of the plenaries, allowing for a 5 minute presentation and 5 minute discussion? NANOG has been doing something like this- the Lightning presos. You could even imagine someone carrying over a topic from this IETF discussion list or the previous meeting. This gives people an opportunity to collect their thoughts, perhaps even post a draft, and then give a quick summary of it. Some would say that the moment may have passed, and that decisions will be taken. But 2 minutes is more than enough time for someone to say -1 or +1, or to make a very brief point as to why someone should be -1 or +1. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Question about draft-housley-iesg-rfc3932bis-12
On 2009-11-18 11:15, Andrew Sullivan wrote: So I'd find it really useful to know what problem this dispute resolution mechanism is actually supposed to solve. Since we're (presumably) trying to write rules that will work when common sense has failed, it seems prudent to have a clear path for disputes of an unknown nature. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt
This version satisfies all my concerns with previous versions. Thanks! Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
On 2009-11-17 09:12, Bob Hinden wrote: Reaction to the timers was quite mixed, going all the way from love to hate; we never did a survey of the participants afterwards, I think. We probably should have. I was one of the folks who hated it. I view the open mikes as the time for the community to speak to the leadership (IESG, IAB, and now the IAOC). IMHO a timer sends the message that the I* does't want to listen to the community. Note, I don't like the long rants either, but in this case the cure is worse than the disease. I agree that the I* should listen to the community, but then the community should regulate itself. Maybe we need a new tradition - something like a polite hum when someone has been ranting for long enough, and a loud hum when they have been ranting for too long? Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt
On 2009-11-13 20:19, Julian Reschke wrote: Brian E Carpenter wrote: As far as I can tell, the proposal places the burden for ensuring atomicity entirely on the server. However, PATCH is explicitly not idempotent. If a client issues a PATCH, and the server executes the PATCH, but the client then fails to receive an indication of success due to an extraneous network glitch (and TCP reset?), then what prevents the client issuing the same PATCH again? In other words, absent a two-phase commit, there appears to be no transactional integrity. How is this different from PUT or POST? If you need repeatability of the request, just make the request conditional using if-match... PATCH seems more dangerous than those simply because it is partial update of a resource, and I don't feel it's sufficient to say that there might be a way of detecting that it has failed to complete, if you're executing a series of patches that build on one another. Talking about transactional integrity in the IETF has always been hard, for some reason. But something described as patch is exactly where you need it, IMHO. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt
Julian, On 2009-11-13 23:35, Julian Reschke wrote: Brian E Carpenter wrote: On 2009-11-13 20:19, Julian Reschke wrote: Brian E Carpenter wrote: As far as I can tell, the proposal places the burden for ensuring atomicity entirely on the server. However, PATCH is explicitly not idempotent. If a client issues a PATCH, and the server executes the PATCH, but the client then fails to receive an indication of success due to an extraneous network glitch (and TCP reset?), then what prevents the client issuing the same PATCH again? In other words, absent a two-phase commit, there appears to be no transactional integrity. How is this different from PUT or POST? If you need repeatability of the request, just make the request conditional using if-match... PATCH seems more dangerous than those simply because it is partial update of a resource, and I don't feel it's sufficient to say that there might be a way of detecting that it has failed to complete, if you're executing a series of patches that build on one another. POST can be a partial update as well, for the simple reason that POST can be *anything*. As a matter of fact, people are using POST right now, as PATCH was removed in RFC 2616. I wasn't involved in reviewing RFC2616 (or in the original design of POST, even though it happened about 20 metres from my office at that time). But yes, POST also lacks transactional integrity. Incidentally, that recently caused me to donate twice as much as I intended to the relief fund for the tsunami in Samoa, although the direct cause was a network glitch. Talking about transactional integrity in the IETF has always been hard, for some reason. But something described as patch is exactly where you need it, IMHO. PATCH does not need to be special, and shouldn't be special. That being said, it wouldn't hurt to clarify that PATCH can be made repeatable (idempotent) by making it conditional. I would make that a SHOULD and, as I said originally, be more precise about how to use strong ETags to achieve it. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
