Re: Last calling draft-resnick-on-consensus
As Dave Crocker pointed out, this document is, at best, revisionist history. Dave's original RFC 1603 text (that I carried forward into RFC 2418) bears little resemblance to the process/considerations described in this ID. This ID may be describing how we should start to view the meaning of the term rough consensus , but I do wish that the ID took care to propose it as new concept rather than pretend that it has always been what the IETF has done. The process in the ID is not what was followed when I was an AD and it not what I have described by the meaning of the term rough consensus in my newcomers tutorials (which I have been giving since at least IETF 57 in 2003). Thus I do not consider this ID ready for publication and call for it to be revised to clearly state that it is proposing a redefinition of the concept and term rough consensus then re-last called. Scott
Re: Last Call: draft-ietf-roll-terminology-13.txt (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC
On Oct 3, 2013, at 6:34 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Terms used in Ruting for Low power And Lossy Networks' draft-ietf-roll-terminology-13.txt as Informational RFC Ruting - Rüting is a municipality in the Nordwestmecklenburg district, in Mecklenburg-Vorpommern, Germany the first sentence in the abstract says routing - maybe the title is in need of Vana White? Scott
Re: Last Call: draft-ietf-roll-terminology-13.txt (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC
that is what I thought at first which caused me to quickly take a look since the topic seemed to be a bit out of scope, even for the quite broad IETF official scope (though I'm not sure what SDO would be a an appropriate venue for standardization in this field) Scott On Oct 3, 2013, at 8:00 AM, Dave Cridland d...@cridland.net wrote: On Thu, Oct 3, 2013 at 12:49 PM, Scott O Bradner s...@sobco.com wrote: On Oct 3, 2013, at 6:34 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Terms used in Ruting for Low power And Lossy Networks' draft-ietf-roll-terminology-13.txt as Informational RFC Ruting - Rüting is a municipality in the Nordwestmecklenburg district, in Mecklenburg-Vorpommern, Germany the first sentence in the abstract says routing - maybe the title is in need of Vana White? I'd assumed that they'd misspelt rutting, and was quite disappointed in the document as a result. Dave.
Re: [Tools-discuss] independant submissions that update standards track, and datatracker
1 April RFCs excepted Scott On Oct 2, 2013, at 10:10 AM, Barry Leiba barryle...@computer.org wrote: because all IETF document are examined by IESG No they're not. See RFC4844. Lloyd, it *is* true that all documents in the IETF stream are reviewed and approved by the IESG. I would take IETF documents to refer to documents in the IETF stream. (In fact, documents in the IRTF and Independent streams are also examined by the IESG, but only for conflict review, according to RFC 5742. The only RFCs that the IESG doesn't look at in any formal way are those in the IAB stream.) Barry, Applications AD
Re: PS Characterization Clarified
John covered why I said that Pete's assertion is factually incorrect that said, I agree that being accurate here (that the IESG is the final decider and the body that changed the review from what was described in RFC 2026) may be counter productive when the document is reviewed outside of the IETF so changing most of the IESG reverences to read IETF is the right thing to do the one that should not be changed is the one that Olaf calls out at the end of the included message Scott On Sep 18, 2013, at 4:59 AM, Olaf Kolkman o...@nlnetlabs.nl wrote: On 18 sep. 2013, at 01:54, John C Klensin john-i...@jck.com wrote: Pete, I generally agree with your changes and consider them important -- the IESG should be seen in our procedural documents as evaluating and reflecting the consensus of the IETF, not acting independently of it. Agreed…. Of the various places in the document in which IESG now appears, only one of them should, IMO, even be controversial. It is tied up with what I think is going on in your exchange with Scott: --On Tuesday, September 17, 2013 18:10 -0500 Pete Resnick presn...@qti.qualcomm.com wrote: Section 2: ... the IESG strengthened its review ... The IETF as a whole, through directorate reviews, area reviews, doctor reviews, *and* IESG reviews, has evolved, strengthened, ensured, etc., its reviews. I believe that change would be factually incorrect Which part of the above do you think is factually incorrect? The issue here --about which I mostly agree with Scott but still believe your fix is worth making-- is that the impetus for the increased and more intense review, including imposing a number of requirements that go well beyond those of 2026, did not originate in the community but entirely within the IESG. It didn't necessarily originate with explicit decisions. In many cases, it started with an AD taking the position that, unless certain changes were made or things explained to his (or occasionally her) satisfaction, the document would rot in the approval process. Later IESG moves to enable overrides and clarify conditions for discuss positions can be seen as attempts to remedy those abuses but, by then, it was too late for Proposed Standard. And, fwiw, those changes originated within the IESG and were not really subject to a community consensus process either. However, because the document will be read externally, I prefer that it be IETF in all of the places you identify. If we have to hold our noses and claim that the community authorized the IESG actions by failing to appeal or to recall the entire IESG, that would be true if unfortunate. I would not like to see anything in this document that appears to authorize IESG actions or process changes in the future that are not clearly authorized by community consensus regardless of how we interpret what happened in the past. But one of the things that we should try to maintain in making that change is the notion that the IESG does have a almost key-role in doing technical review. You made the point that that is an important distinction between 'us' and formal SDOs. Therefore I propose that that last occurrence reads: cross-area technical review performed by the IETF, exemplified by technical review by the full IESG at last stage of specification development. I think that this language doesn't set precedence and doesn't prescribe how the review is done, only that the IESG does do review. In full context: In fact, the IETF review is more extensive than that done in other SDOs owing to the cross-area technical review performed by the IETF,exemplified by technical review by the full IESG at last stage of specification development. That position is further strengthened by the common presence of interoperable running code and implementation before publication as a Proposed Standard. Does that work? --Olaf
Re: PS Characterization Clarified
1/ I believe that change would be factually incorrect 2/ I do not see that being factually correct about what happened says anything about the community opinion about any future IESG decision to change processes. Scott On Sep 17, 2013, at 6:48 PM, Pete Resnick presn...@qti.qualcomm.com wrote: On 9/17/13 11:27 AM, Olaf Kolkman wrote: I just posted the third version of the draft at: http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02 I would like to change IESG to IETF in five places: Section 1: the IESG has evolved its review processes Section 2: IESG Reveiew of Proposed Standards the IESG strengthened its review last chance for the IESG to ensure the quality cross-area technical review performed by the IESG The IETF as a whole, through directorate reviews, area reviews, doctor reviews, *and* IESG reviews, has evolved, strengthened, ensured, etc., its reviews. Saying the IESG in these places implies precedent setting that I think would be bad. If the IETF capitulated to the IESG changing the rules on its own in the past, so be it, but I think it would be bad to indicate in a BCP that we think it's OK for the IESG to do so unilaterally. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: PS Characterization Clarified
On Sep 13, 2013, at 2:32 PM, Olaf Kolkman o...@nlnetlabs.nl wrote: On 13 sep. 2013, at 19:17, S Moonesamy sm+i...@elandsys.com wrote: The intended status would have to be BCP instead of Informational. Correct…. fixed on trunk. In Section 3.1: A specific action by the IESG is required to move a specification onto the standards track at the Proposed Standard level. I suggest standards instead of specific action if you (and the other authors) decide that BCP is appropriate. I have used exactly the same term as RFC2026. I have no idea if 'standards action' is defined somewhere. I do not think we should move away from the ted used in RFC 2026 Scott
Re: Last Call: draft-resnick-retire-std1-00.txt (Retirement of the Internet Official Protocol Standards Summary Document) to Best Current Practice
looks good to me except that maybe using the IETF Announce list rather than IESG minutes as the publication of record Scott On Sep 5, 2013, at 1:10 PM, Pete Resnick presn...@qti.qualcomm.com wrote: Having seen no further comments, Jari has asked me to post -01 with the changes. Done. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: PS Characterization Clarified
thank you - clarity does help but such an effort will not remove the need for this document imo Scott On Sep 3, 2013, at 9:20 AM, Jari Arkko jari.ar...@piuha.net wrote: Olaf, John, Scott, In fact, going back to the language of RFC2026 for Full (now Internet) Standard. It confirms that popularity (significant implementation) is one necessary but not sufficient criterium. Sorry. I was careless when I wrote about the effort. I didn't mean to suggest that we have an effort to classify standards merely based on popularity. What I meat that we have an effort to move a particular set of specifications to Internet Standard, and will use the usual criteria when deciding whether the documents are ready. While that particular set of specifications happens to be popular, that was just an observation, not a (sole) reason of moving them forward. Hope this clarifies. I would hope that any concerns about technical maturity or significant benefit to the Internet community are taken into account when making the decision. If it is the case that members of the community assess that a specification lacks interoperability that should be sufficient grounds to not advance until data proofs otherwise. Yes, of course. Jari
Re: PS Characterization Clarified
fwiw - I would love for the IESG to exercise flexibility here but I have not seen that in many years - so I think we are already there without a discernible path back Scott On Sep 3, 2013, at 4:40 PM, Barry Leiba barryle...@computer.org wrote: I mostly agree with this draft, but I have a concern. Let's anchor that concern off of this bit that Jari said: Secondly, the other obvious action we could take is to go back to the original mode of operation, i.e., making PS RFCs truly early and somewhat untested specifications. I am personally opposed to that on the following grounds. First, it would not change the fact that a large part of Internet technology today runs on PS RFCs, and Olaf's problem with getting these RFCs recognised would continue. Second, while I think we need to keep adjusting the level of review performed by the IESG and in IETF Last Call (we sometimes overdo it), I think broad review is actually useful. It's certainly clear to all of us that most PS specs are far more mature than what we thought about when we wrote RFC 2026. The only concern I have is that once we do this -- declare that PS is always more mature than that -- we can't go back. Do we *really* want to say that we will never again approve a PS spec that's partially baked? This is painting us into the room where PS is mature and robust. If we like being in that room, that's fine. But it removes the IESG can put fuzzy stuff out as PS if it thinks that's the right thing to do option. It says that IETF PS specs are at least as mature as final standards from other SDOs. Mostly, that's true. But it doesn't have to be. After this, it would have to be, always, for every PS spec. Are we *sure* that's what we want? Barry
Re: PS Characterization Clarified
On Sep 2, 2013, at 10:23 AM, Jari Arkko jari.ar...@piuha.net wrote: Olaf, Scott, Apologies for a late reply on this (I was on vacation after the IETF). But thank you for writing this draft. My general comment is that the draft makes what in my mind is an accurate correction to our documents, aligning the documents to the current reality. I'd be happy to take the document forward. In fact, I think we need to make this change even if we made other, more long term changes. There is at least one ongoing effort right now that has the potential to reclassify a large set of Proposed Standard RFCs that form the basis of widely used technology. These types of efforts can have a relatively big effect on the standards status of the most commonly used RFCs. Do we want to do more? Can we do more? seems like a quite bad idea (as Randy points out) take extra effort and get some interoperability data Secondly, the other obvious action we could take is to go back to the original mode of operation, i.e., making PS RFCs truly early and somewhat untested specifications. I am personally opposed to that on the following grounds. First, it would not change the fact that a large part of Internet technology today runs on PS RFCs, and Olaf's problem with getting these RFCs recognised would continue. Second, while I think we need to keep adjusting the level of review performed by the IESG and in IETF Last Call (we sometimes overdo it), I think broad review is actually useful. imo - not a chance in hell of the IESG going back to the original meaning of PS it is not in the IESG genetics, nor has it been for quite a while But enough about my opinions. What do the rest of you think? In terms of specific text, I also wrote a few observations, below. These are purely personal comments. First, I think you assumed this but never made it explicit. While the new characterisation recognises the often final role of PS RFCs, it does not take away the possibility of publishing Internet Standard specifications. Can this be clarified? In the two decades after publication of RFC 2026 [RFC202] the IESG has evolved its review processes of Proposed Standard RFCs and thus RFC 2026 section 4.1.1 no longer accurately describes IETF Proposed Standards. I'd prefer saying the IETF review processes Proposed Standard RFCs have evolved. And leave the details to Section 2. 2. IESG Reveiew of Proposed Standards Review In response, the IESG strengthened its review of Proposed Standards, basically operating as if the Proposed Standard was the last chance for the IESG to ensure the quality of the technology and the clarity of the standards document. That is part of it, but I think the situation is more complicated than that. The world changed around us, and suddenly Internet was big business, global, and we got more careful about impacts to it. The process has evolved, including the number of steps in the ladder. Review practices in general have changed quite a lot, we now have a fairly broad review of RFCs. Progression has also varied, mostly downwards. But as noted, it also seems very much affected by specific initiatives. Here's what I'd say: Initially it was assumed that most IETF technical specifications would progress through a series of maturity stages starting with a relatively early Proposed Standard, then progressing to Draft Standard then, finally, to Internet Standard (see RFC 2026 section 6). Over time, for a number of reasons, this progression became less common. At the same time, the review for Proposed Standard RFCs was strengthened. This strengthening was partially a response by the IESG for the above, and in part a consequence of the growth in the importance of the Internet and broader interest in reviewing new Internet technology. At the time of this writing, the IETF operates as if the Proposed Standard was the last chance for the to ensure the quality of the technology and the clarity of the standards document. The result is that IETF Proposed Standards approved over the last decade or more have had extensive review. Because of this change in review assumptions, IETF Proposed Standards should be considered to be at least as mature as final standards from other standards development organizations. In fact, the IETF review is more extensive than is done in other SDOs due to the cross-area technical review performed in the IETF. wfm Jari
Re: IESG Considering a Revision to NOTE WELL
correct - except that the IRTF has adopted the same disclosure requirements Scott On Nov 6, 2012, at 4:56 PM, Stephan Wenger st...@stewe.org wrote: On 11.6.2012 16:17 , Scott O Bradner s...@sobco.com wrote: On Nov 6, 2012, at 10:54 AM, Fred Baker (fred) f...@cisco.com wrote: Not being a lawyer, I can't comment on the legal details of IPR cases. What I am looking at is the understandability of a statement. A lawyer that I was speaking with recently told me that the IETF IPR policy is ambiguous; one must file IPR statements for standards, but not for informational documents. We wound up wandering through the details of legal statements, in which I felt he was working pretty hard to make words stand on their heads. in case anyone wonders one might have been able to read that into RFC 2026 but that was very carefully fixed in the current documents - disclosures are required for ALL contributions ALL IETF contributions. NOT all contributions to the RFC editor, and not all RFCs. (Which is of a certain relevance given, for example, the VP8 codec definition RFC) And, only if the IPR in question is yours or your employer's. Stephan Scott
Re: Recall petition for Mr. Marshall Eubanks
I have not signed the petition because I did not think it was proper to do so (as a IAOC member - see Russ's message and RFC 3777) but, that aside, I do support the petition - I feel that the IAOC has given Marshal the full opportunity to start participating again or to resign and he has done neither - it is time to move Scott On Nov 1, 2012, at 10:22 PM, Michael StJohns mstjo...@comcast.net wrote: At 06:01 PM 11/1/2012, Bob Hinden wrote: While the IAOC has not discussed this formally, I agree with you. The situation did change when we were able to talk with Marshall. I assume at this point the IAOC would like to pursue the recall option? If not, please be very clear about it to the list as I haven't actually seen a request from the IAOC for that process to proceed as far as I can tell. If you'd rather just wait from him to resign, if in fact he does, then please indicate that. I believe neither you nor Dave Crocker nor Scott Bradner (the only IOAC members that I think have commented on this issue on list so far) have actually specifically asked for or signed the recall on the list. Mike I too hope he will resign. Bob
Re: ISOC BOT and Process BCPs
Sam - The ISOC BoT has generally (with some slip-ups) accepted IETF process documents as describing the IETF process - this has been seen as a good idea for the insurance coverage there is no requirement in the IETF process that such RFCs be approved by the ISOC board nor that they are accepted as describing IETF process before the RFCs become active see, for example, Resolution 2006-36 http://www.internetsociety.org/who-we-are/board-trustees/list-resolutions Scott On Oct 26, 2012, at 7:20 AM, Sam Hartman hartmans-i...@mit.edu wrote: SM == SM s...@resistor.net writes: So, I'm puzzled by this. my claim was that ISOC needed to approve process related BCPs. If you take a look at RFC 2031, it supports that claim. However, I'd kind of expect the other half of this to be in RFC 2026. I certainly recall us sending things like BCP 101 before the ISOC BOT. I also think we sent a couple of other documents there because they were process documents. However this is clearly more complex than I thought it was. Scott, or anyone else with more history, can you tell us a story about how this works?
Re: Hasty procedural changes (was: Re: [RFC 3777 Update for Vacancies])
On Oct 25, 2012, at 11:03 AM, John C Klensin john-i...@jck.com wrote: (ii) The IESG could use its implied authority to interpret RFC 2026 (an authority it has at least implicitly applied many times in the past). It could interpret the 2026 variance procedure as applying to all bodies to which 2026 applies, whether they were created earlier enough to be enumerated in 2026 or not. (FWIW, I personally believe that interpretation would be correct relative to the intentions 16 years ago.) That procedure could then be used to treat the current situation as a resignation without creating any unfortunate precedents. for some additional context about the variance procedure - it originally came from RFC 1871 Scott
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
in addition since there is no admissions control on IDs I would think that the IESG would want to reserve the option to remove an ID that contained clear libel or inappropriate material (e.g., a pornographic story published as an ID as part of a DoS attack on the IETF) once the IESG had been given notice of such material Scott On Sep 3, 2012, at 9:29 PM, Sam Hartman hartmans-i...@mit.edu wrote: I strongly urge the IESG to be significantly more liberal in the cases where an I-D will be removed from the archive. I can think of a number of cases where I'd hope that the IESg would be cooperative: 1) the IETF recieves a DMCA take-down notice or other instrument indicating that a third party believes an I-D infringes their copyright. Forcing such third parties to take the IETF to court does not seem to benefit the community. 2) An author realizes that an I-D accidentally contains proprietary information, infringes someone else's copyright, failed to go through external release processes for the author/editor's organization, etc. Obviously factors like how long after the I-D is submitted might need to be considered. In conclusion, I believe there are a number of cases where the interests of the community are better served by being able to ask for removal from the archive. Being able to easily repair mistakes is likely to facilitate more free discussion and more speedy updating of I-Ds. Yes, I'm aware that organizations other than the IETF mirror the i-ds and some of these organizations will be less sympathetic to these concerns.
Re: Last Call: Modern Global Standards Paradigm
singing this statement is the right thing to do Scott (responding to a sorta-last-call) On Aug 11, 2012, at 2:10 PM, Paul Hoffman wrote: On Aug 11, 2012, at 5:05 AM, Randy Bush wrote: The IETF Chair and the IAB Chair intend to sign the Affirmation of the Modern Global Standards Paradigm, which can be found here: http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-15.pdf no brainer. Even with a brain, the document is obviously good. Please sign it. --Paul Hoffman
Re: Last Call: Modern Global Standards Paradigm
ah yes - Mac Mail being helpful (again) :-) On Aug 11, 2012, at 7:14 PM, Carsten Bormann wrote: On Aug 12, 2012, at 00:51, Scott O Bradner s...@sobco.com wrote: singing this statement is the right thing to do For 0.29 seconds, I imagined you in front of a microphone in a recording studio, singing Modern Global Standards Paradigm to the tune of All the young dudes. For 0.29 seconds... Grüße, Carsten
Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
:-) its a label not a process (in this case) i.e., according to 2804 the label on the rfc should not be standards track Scott On Jul 30, 2012, at 1:33 PM, Randy Bush wrote: 2804 does not say not to talk about such things - or that such documents should not be published as RFCs - 2804 says that the IETF will not do standards work in this area for those of us who are easily confused, could you differentiate between working on douments and publishing them as rfcs from doing standards work? randy
Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
2804 does not say not to talk about such things - or that such documents should not be published as RFCs - 2804 says that the IETF will not do standards work in this area Scott On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote: Under the long-standing IETF policy defined in RFC 2804, I trust we will not be discussing this draft, or draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF. Regards Brian Carpenter On 30/07/2012 09:26, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Label-based Provider-Provisioned Lawful Intercept for L3 VPNs Author(s) : Shankar Raman Balaji Venkat Venkataswami Gaurav Raina Vasan Srini Bhargav Bhikkaji Filename: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt Pages : 12 Date: 2012-07-30 Abstract: In models of Single-AS and inter-provider Multi- Protocol Label Switching (MPLS) based Virtual Private Networks (VPNs) Lawful Intercept is a key requirement. For example, MPLS-based Layer 3 VPN models like VPLS and the like do not have any provider provisioned methods of lawful intercept that are comprehensive, quick and easy to provision from one single point. More particularly the auto- provisioning of lawful intercept for all sets of streams travelling between VPN sites and consequent re-direction of these streams to the appropriate government network has not been covered without multiple instances of having to configure the intercept at various points in the network both in the Single-AS case and the Inter-Provider VPN case. this paper, we propose a technique which uses a set of pre-defined labels called Lawful Intercept labels and a method for provisioning lawful intercept amongst the various PE devices using these labels both in the Single-AS and the inter-provider VPN cases. A single point of configuration is the key to this idea. The intercepted traffic is mirrored on a PE or a whole set of PEs or on all the PEs participating in the VPN. A technique called the Domino-effect provisioning of these Label-based Provider Provisioned Lawful Intercept mechanism is also outlined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis There's also a htmlized version available at: http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Re: [IAOC] Feedback Requested on Draft Fees Policy
I did it once - it took 2 or 3 hours *it was quite a while back and I do not remember) there were no significant expenses - the depo was in Boston my only expense was a few hours parking - the depo was done in the office of the law firm that was providing the IETF with pro-bono legal services at the time Scott On Jul 22, 2012, at 3:58 PM, John R Levine wrote: For people with unique skills or knowledge, $800/hr is not unusual. So long as the rate is published ahead of time, you're not going to get much argument. (Yes, we know it's high. But we've already told you how to download stuff yourself for free.) Please note : out of pocket expenses (if someone has to travel to a hearing, say) would be reimbursed, but IETF volunteers will not be paid from these fees. If you know, how often have people been deposed on behalf of the IETF, and how long does it typically take? My thought is that in a depo or trial, the other side pays both for the expenses and the time of the person being deposed, so it would be good idea to say up front here's what it'll cost if you want a live witness. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly.
Re: [IAOC] Feedback Requested on Draft Fees Policy
I did not do them any favor - I did the IETF a favor (as the then ISOC VP for Standards) Scott On Jul 22, 2012, at 4:43 PM, John R Levine wrote: I did it once - it took 2 or 3 hours *it was quite a while back and I do not remember) there were no significant expenses - the depo was in Boston my only expense was a few hours parking - the depo was done in the office of the law firm that was providing the IETF with pro-bono legal services at the time If the opposing party didn't pay you for your time in the depo, you did them an unnecessary favor. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly.
Re: Last Call: draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC
what John said with one caveat - ITU-T consensus to modify an IETF protocol rather than bringing requirements to the IETF should not escape the gatekeeper function Scott On Mar 1, 2012, at 6:04 PM, John C Klensin wrote: --On Thursday, March 01, 2012 18:39 + Stewart Bryant stbry...@cisco.com wrote: ... FWIW, this seems entirely appropriate to me. If we do it this way, I think it is important to note --for the benefit of those more historically involved with the ITU and others-- that we routinely block our own documents on normative references to work that is still in progress and, usually, do not do related code point allocations until the blocking referenced documents are ready. Once the present I-D is judged to be sufficiently ready, this approach would therefore be IETF approval and a formal guarantee to the ITU that a code point will be allocated if an when G.8113.1 is approved and published, but not assignment of that code point until the referenced base document is finished. Completely normal procedurally. ... To be clear John our normal requirement would be that the technical community achieved consensus that the base document was ready. I have never seen ITU-T consensus on the contents of G.8113.1 at any meeting that I have observed. What in your view is the criteria for determining that G.8113.1 has achieved consensus? Stewart, I don't think so. Let me suggest that there are two entirely separate issues here and that talking about technical community consensus obscures both of them. (1) Whether, given the JWT and other agreements, the ITU has any business developing G.8113.x at all, or whether they should be simply submitting ideas to the IETF for consideration. Many of us think that, under that agreement, the G.8113 activity is inappropriate. But the ITU has obviously decided otherwise and we have no enforcement capability to prevent them from doing so (whether we should or should not is pretty much irrelevant at this point, at least IMO). Whether the technical community has achieved consensus is not relevant either, the only thing that matters is whether G.8113.1 is, or will be, fully approved by the ITU under ITU procedures. (2) Whether it is reasonable or appropriate for the IETF to use our responsibility for code point assignments and consequent relationship with IANA to try to keep protocols that are not consistent with our design judgment and aesthetics --no matter how grounded in experience and good engineering-- off the Internet. That is the Internet gatekeeper function about which, as you know, I've expressed concern in other contexts. I think the answer has got to be we can, should, and always will exercise quality control on stable specifications and normative references but, unless we can justify being sure of our own infallibility, we cannot and should not try to prevent another body from deploying a specification on the Internet by using our control of the registration model. Telling people why we think their ideas are sub-optimal is fine, as is identifying any risks we see in appropriate and visible places, but telling another group what they can't do because the IETF doesn't like the idea isn't. And I think that distinction is entirely consistent with Russ's suggestion. best, 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: Another last call for draft-weil
+1 On Feb 14, 2012, at 1:25 PM, Ross Callon wrote: +1. Ross From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Owen DeLong Sent: Monday, February 13, 2012 2:06 PM To: ietf@ietf.org Cc: draft-bdgks-arin-shared-transition-space@tools. org Subject: Re: Another last call for draft-weil I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already. Owen On Feb 13, 2012, at 10:09 AM, Chris Grundemann wrote: Fellow BDGKS Authors, FYI: draft-weil is in another Last Call following an update that was requested by IESG Ads (on their December telechat, some ADs asked us to turn our request into a request for more 1918 space, but with a few caveats to home router manufacturers about not breaking when exposed to a CGN environment.). At this point we don't expect to change any minds. Basically everyone who is against the draft has spoken up. Now it is just a numbers game, we need to demonstrate significant support for the draft. If you do support this I-D and the allocation of the /10 for shared CGN use, please consider posting a statement of support. Something as simple as I support this draft as updated or I think the updated draft is more flexible, and would satisfy additional use cases that don't work with RFC1918 space would be very helpful. You can respond to the Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP thread or post individually to ietf@ietf.org. Also, please feel free to encourage anyone else you know who supports the draft to make a similar post. Every statement we can gather is vital right now. Last call ends on Thursday, so reply's must be made before then. Thank you. Cheers, ~Chris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
fwiw - the last time I looked at this law 1/ the IETF did not qualify as a SDO under the law 2/ the law only protected employees of the SDO, not participants Scott On Nov 28, 2011, at 4:13 PM, Richard Shockey wrote: +1 It would be helpful in the non normative statement to the community to cite what suits were are involved, what was the cause of action and what if any decisions were rendered in these cases. US antitrust law, for instance has specific exemptions for SDO’s. http://en.wikisource.org/wiki/Public_Law_108-237/Title_I There are some requirements under this act that SDO’s need to file a statement of purpose. I don’t know if we ever did that. In general, however this sounds like a sound and valuable move. From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ted Hardie Sent: Monday, November 28, 2011 2:27 PM To: IETF Chair Cc: IETF; IESG Subject: Re: An Antitrust Policy for the IETF On Mon, Nov 28, 2011 at 11:10 AM, IETF Chair ch...@ietf.org wrote: Sorry, can you expand on the threat model here? Are we developing one in order to defend against some specific worry about our not having one? Because it has become best practice in other SDOs? Because the insurance agent wishes to see something in particular? I hesitate to develop something that we have not needed in the past unless it is clear what benefit it gives us. In particular, if we develop one without some particular characteristic, do we lose the benefits of being where we are now? Recent suits against other SDOs is the source of the concern. The idea is t make it clear which topics are off limits at IETF meetings and on IETF mail lists. In this way, if such discussions take place, the good name of the IETF can be kept clean. Russ Hmm, I would characterize our previous policy as a quite public statement that no one is excluded from IETF discussion and decision making, along with with reminders that what we are deciding is the technical standard, not the resulting marketplace. What we can say beyond that without diving into national specifics is obscure to me. I agree with Dave that the first work product of an attorney should be a non-normative explanation to the community of how having such a policy helps and what it must say in order to get that benefit. (I have to say that my personal experience is that prophylactic measures against law suits tend to change the terms of the suits but not their existence. In this case, suing someone because they did not enforce the policy or the policy did not cover some specific jurisdiction's requirements perfectly, seems like the next step. Your mileage may vary.) regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 82 Audio Streaming
how about - when the URLs get added to http://www.ietf.org/meeting/82/remote-participation.html#audio they are URLs that bypass the spy features of meetecho? Scott On Nov 1, 2011, at 6:37 AM, Simon Pietro Romano wrote: ...forgot to include the list in my response. Sorry about that. Simon Simon Pietro Romano sprom...@unina.it ha scritto: Hi Randy, you can skip such a fat frelling chance, if you want; just choose to either attach to the RTSP stream, or to the landline phone bridge. Cheers, Simon Randy Bush ra...@psg.com ha scritto: For general remote participation including meetecho support see: meetecho seems to require me to let a java applet have its way with my machine. fat frelling chance. does the ietf really want to recommend such a practice? randy 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-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
I'm having a hard time understanding just what this document is trying to do I understand from the title that it is supposed to be telling the reader why a single OAM solution is a good idea for MPLS-TP if that is the case I'm not all that sure what the purpose of sections 4 and 5 are for - they seem to be exploring land outside the reservation - how about just addressing the topic in the title? Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pre-IETF RFCs to Historic (not really proposing)
I'm fully supportive of reclassifying any RFCs that pose a risk to the Internet to historic but fail to see the usefulness of doing so for RFCs that describe unused but non-harmful technologies - seems like busywork and useless at best. Scott On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev wrote: Dear all, I've recently received a message from Ronald Bonica, one of the ADs, proposing undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic. However, I initially had a concern regarding community consensus on such effort, and whether it will be accepted so that the IESG may claim the former. Since I've already suggested a very similar proposal, and there was a negative reaction of community, I assumed the same would happen in the case Ronald pursued the work and forwarded it to the IESG. So am I right? Mykyta ___ 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: Pre-IETF RFCs to Historic (not really proposing)
ps - as Keith points out - a round of this type of effort was undertaken by the newtrk working group a while back (I was the chair and did not see much reason to do so at the time but there was consensus in the WG to proceed) - I will note that it took quite a bit of work to ensure that technologies were actually unused Scott On Sep 15, 2011, at 2:36 PM, Scott O Bradner wrote: I'm fully supportive of reclassifying any RFCs that pose a risk to the Internet to historic but fail to see the usefulness of doing so for RFCs that describe unused but non-harmful technologies - seems like busywork and useless at best. Scott On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev wrote: Dear all, I've recently received a message from Ronald Bonica, one of the ADs, proposing undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic. However, I initially had a concern regarding community consensus on such effort, and whether it will be accepted so that the IESG may claim the former. Since I've already suggested a very similar proposal, and there was a negative reaction of community, I assumed the same would happen in the case Ronald pursued the work and forwarded it to the IESG. So am I right? Mykyta ___ 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: Conclusion of the last call on draft-housley-two-maturity-levels
On 2011-09-11 08:11, Sam Hartman wrote: snip I do not think the following types of comments should be considered as objections when judging this sort of consensus: 2) This will not do any good now lets see, this argument seems to be that the fact that a particular process change is useless should not stop the IETF from adopting the change this argument would be nonsense if applied to a proposal for a technical standard - i.e. the IETF should adopt a technical standard that is known to be useless -- it is no less nonsense when applied in this case - changes for the sake of publishing new bits should not be what the IETF spends its time on Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Conclusion of the last call on draft-housley-two-maturity-levels
Jari Arkko sed I also saw a couple of opposing opinions, though some of them were more about a desire to do something else than specific objections about this proposal. for the record in case Jari is confused - I have specific objection to this proposal imo - it fixes no known problem - it only adds additional fuzz to a surface understanding of what causes few RFCs to be advanced on the standards track - I see no reason to think that this proposal will have any significant effect on that problem (nor any insignificant effect) Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
I've been traveling so have not had a chance to do anything but watch the discussion on a RFC 2119 update. a few thoughts 1/ I am far from convinced that there is a need to update RFC 2119 there is a bug in the boilerplate (as has been mentioned) and some people seem to have a hard time understanding what (to me) seem like clear descriptions of (for example) MUST SHOULD - but the issues do not seem serious enough to warrant replacing what is, basically, a simple dictionary usage constraint 2/ it seems like a very Bad Idea to move 2119 to historic- we move RFCs to historic when no one uses them or when they are a Bad Idea in light of updated technology - I do not think that makes much sense in this case - in addition it makes the status of RFCs that have a normative reference to a historic document a bit funky - if an update is actually needed there is no reason that I can come up with that it could not just be that -- an update 3/ I doubt that I'll ever catch up with Postel as the most referenced RFC author so that is not a consideration (for me) I wrote RFC 2119 (most using text from RFC 1122) because people were using MUST without saying what they meant, an update, if people think that one is actually needed, will serve that purpose as well as 2119 has. When I posted the original ID it was pointed out that I should also address when such terms should be used (i.e. try to limit the use to where it actually made sense protocol-wise) - I tried to do that but that part may not have been as successful as it might have been - any update might try to be clearer in this area that RFC 2119 is. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Review: Last Call draft-ietf-p2psip-base-17.txt
fwiw - the author of 2119 thinks that less is more when it comes to the use of these terms see, as Cullen points out, Section 6 but there is a balance - for example, if you define a structure and say that all fields are required, it is redundant to use MUST with each example of using the structure Scott On Aug 11, 2011, at 8:43 PM, Cullen Jennings wrote: Thanks for the detailed review - you caught some good stuff. Most of this makes essence but we should probably talk about usage of 2119 language. On Aug 9, 2011, at 16:05 , Mary Barnes wrote: simple === Document: draft-ietf-p2psip-base-17 Reviewer: Mary Barnes Review Date: 9 August 2011 IETF LC End Date: 22 July 2011 Summary: Not Ready. Comments: The document is very a dense (with detailed technical information) and long (150 page) specification for a Peer-to-peer signaling protocol. While the overall technical functionality seems fairly correct and thoroughly specified, the primary issue is a tremendous lack of normative language in the main body of the document. Non-inclusive details of such are included below. The 2119 MUST/SHOULD/MAY terms are simply abbreviations for some words defined in 2119, and different WGs have different styles about how extensively they should be used. P2PSIP has obviously been on the more sparing side of that spectrum. This isn't to say that there aren't any places where it would be useful to add such language, but rather that our policy has been to add it principally where there is likely ambiguity, rather than everywhere where behavior is defined. I'll work thought these and see where they might help reduce the chance of a an implementers doing the wrong thing but in generally when we define a structure in something like ASN.1 or ABNF, if the structure always has a field X, we just use the language like ASN.1 or ABNF to indicate it always has that. We don't also say it MUST be there. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
it looks so - maybe it would be good to have a pointer in this doc Scott On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote: Scott - Didn't RFC 5657 address your point 2? The current proposal no longer requires this report during advancement, but it does not disallow it. I hope it's obvious that I believe these reports are valuable, but I am willing to accept the proposed structure, with the hope and expectation that communities that are serious about producing and refining protocols will be producing these reports anyhow. RjS On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote: this is better than the last version but 1/ I still see no reason to think that this change will cause any significant change in the percent of Proposed Standards that move up the (shorter) standards track since the proposal does nothing to change the underlying reasons that people do not expend the effort needed to advance documents 2/ one of the big issues with the PS-DS step is understanding what documentation is needed to show that there are the interoperable implementations and to list the unused features - it would help a lot to provide some guidance (which I did not do in 2026 - as I have been reminded a number of times :-) ) as to just what process is to be followed could be a spread sheet showing features implementations an assertion by the person proposing the advancement that the requirements have been met or something in between Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Scott Bradner Harvard University Information Technology Security | Policy, Risk Compliance +1 617 495 3864 29 Oxford St., Room 407 Cambridge, MA 02138 www.harvard.edu/huit ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
this is better than the last version but 1/ I still see no reason to think that this change will cause any significant change in the percent of Proposed Standards that move up the (shorter) standards track since the proposal does nothing to change the underlying reasons that people do not expend the effort needed to advance documents 2/ one of the big issues with the PS-DS step is understanding what documentation is needed to show that there are the interoperable implementations and to list the unused features - it would help a lot to provide some guidance (which I did not do in 2026 - as I have been reminded a number of times :-) ) as to just what process is to be followed could be a spread sheet showing features implementations an assertion by the person proposing the advancement that the requirements have been met or something in between Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: External IPR Disclosures vs IPR disclosures in the document.
see RFC 3979 section 4 A - a note like Mike asks for is called for but the other Scott is also right - do not be specific - see section 11 of the same RFC Scott On Jun 22, 2011, at 3:56 PM, Michael StJohns wrote: At 11:42 AM 6/22/2011, Scott Brim wrote: On Wed, Jun 22, 2011 at 11:11, Michael StJohns mstjo...@comcast.net wrote: A quick couple of questions to the list based on a document I saw recently. If a document (an ID in this case) contains encumbered material (in this case consists of 90%+ encumbered material), and the document is authored by the organization (or members of the organization) that holds the encumbrance, should the document contain an IPR disclosure itself or is it sufficient to submit a IPR disclosure through the IETF web interface? IPR statements are never put in RFCs unless on occasion they are informational transplants from outside. The IPR claims or other aspects might change over time and the right place to track all that is in the IPR disclosures. Hmm.. even though this was labeled like a normal run of the mill ID, it really was an informational transfer from the outside - at least at this point in the process. I.e. - single corporate author, long held IPR as opposed to here's something brand new and never seen before and while parts of it may derive from work from company A, this use of it is new and people from company B and C are figuring out new ways to work with it. I think tracking disclosures via the IPR system is reasonable for most documents, but something like This document consists primarily of intellectual property claimed to owned by . Please consult the IETF disclosures section for the current terms and conditions for this IPR. may be useful.It's pretty hard to tell from any given document whether or not consulting the IPR disclosures is useful or somewhat necessary. Not a big problem, I guess, but somewhat dissonant to the process. Mike ___ 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-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
As I have stated before, I do not think that this proposal will achieve anything useful since it will not change anything related to the underlying causes of few Proposed Standards advancing on the standards track. I see it as window dressing and, thus, a diversion from the technical work the IETF should focus on. If it were up to me, I would not approve this ID for publication as a RFC (of any type) Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] xml2rfc and legal services RFPs
jck sed: Perhaps I'm the only member of the community who cares any more. he is not alone quite a few of us were quite worried when the IAOC was formed that it would tend to evolve into a management group that thought it knew best for the the IETF without getting around to asking. announcing RFPs without any chance for the IETF community to comment is just the sort of the thing that I, for one, was worried about. I have an easy time understanding that the IAOC migt find it a pain to consult with the community, and as John mentioned, many times there will be little or no comment, but please rethink your processes you may not see very much value in doing a community review for this but, I do not think that should be your call. Always consult is a better plan to ensure that the IAOC is not getting out of step with the part of teh community that does care. Scott ps - long before Wilmer-Hale it was Hale and Dorr I was involved in the first pick so might have an opinion on future ones ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
prerequisite for change (was Re: draft-housley-two-maturity-levels)
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
Re: draft-housley-two-maturity-levels
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) 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. 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 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. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[79all] IETF Badge
Some history Back when the IETF decided to charge for meetings ($100/meeting sometime in the early 1990s) Steve Coya said that the IETF would never check badges to block people from meetings. That, I think, was to indicate that people who could not afford to pay could still attend. But that was a very long time ago, and a few hundred dollars per meeting ago I find it hard to get too bent out of shape that the IETF has joined the world that every other conference I have gone to in the last 20 years has been in, and I find it hard to get too bent out of shape about a change in this level of meeting implementation detail not being subject to a discussion on the IETF list (there have been many other, much more important, changes in meeting implementation which have not, and properly so, been discussed by the community - e.g. the many tools.ietf.org support tools, the additional remote participation abilities etc) I find it amusing that there is more traffic on this topic on the IETF discussion list than any issue that anyone in the world would see as an actual issue. This seems to be this year's cookie crises. To me, that means that this meeting is going rather well. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [79all] IETF Badge
correction to history - it was Phill Gross not Steve Coya ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
The known problem is it takes well over four years to get anything published. ... What I *am* hoping is that with two, clearly defined maturity levels, we can go back to publishing Proposed Standards in about a year the only way that could happen is if the IESG were to change their ways a lot and permit less complete documents to be published as PS Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Russ asks Just to clarify, do you think that it would be better to document one step or do you think that the community should not spend time on this topic at all? I think the community should only change its processes with careful deliberation taking into account the interplay of the different factors I do not this particular document does this, nor would some other document that proposes one or 7 steps I think it is better to not fiddle, even if the current documents do not paint an accurate picture, I think we need to be serious when changing our basic rules. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
what is the problem? (was Re: draft-housley-two-maturity-levels)
some more thoughts first figure out what problem you are trying to solve is the problem: 1/ that the 3 step standards track described in RFC 226 and its predecessors does not describe what happens most of the time? 2/ (as Eric says) that it takes too long to get to the first stage 3/ too much of the Internet runs on Internet Drafts? 4/ ??? then analyze the problem to see what might be behind it e.g., for problem #1 1/ no real incentive to put more work into advancing a document 2/ too much effort required to advance 3/ no actual benefit in advancing 4/ the current IESG review ensures that the first stage document is rigorous enough that additional work on the technology is not needed 5/ requiring running code early in the game ensures that additional work on the technology is not needed (see James's note) 6/ ??? e.g., for problem #2 1/ see #4 above 2/ see #5 above 3/ working with busy volunteers e.g., problem #3 1/ see problem #2 if the problem is #1 then what to do about it: 1/ change the process to meet what you think is the normal case (i.e. define away that there is a problem) 2/ change the process to one that is not currently followed and provide no reason to think that the underlying reasons the current process is not followed will magically change to make the new process any more of an accurate description. (to me this is where Russ's ID sits) 3/ address some of the underlying reasons that the current description is not followed 4/ live with the current description and worry about things that can actually be fixed etc. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
what is the problem bis
while we are the topic of problems Russ basically proposes too change the maturity warning label on IETF standard track RFCs -- remove baby before folding carriage -- this hardly seems like our biggest problem The IETF publishes a lot of standards track RFCs each year. Mostly these are PS (186 in 2009), some DS (3 in 2009), and some S (6 in 2009). SOME of these technologies are just what the community needs and just when the community needs them. But too many are 1/ too late for the market - implementations based on IDs deployed or other technologies adopted 2/ unneeded by the market - does not meet a need that people think they have 3/ broken - flawed in some way that prevents actual deployment 4/ too complex - hard and costly to correctly implement 5/ unmanageable - cannot be run by humans Seems to me that the issue of how the IETF can be better at producing just what the community needs just when the community needs it is more important than maturity warning labels. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Barry coments Scott, I'm confused about one thing you say: You seem to be saying that we have to carefully deliberate, consider many factors, and be serious if we want to *change* the basic rules... but that it's OK to *ignore* the basic rules and do whatever we want, with no deliberation, consideration, or seriousness (this is what we're doing now). basically, yes - sometimes it is better to do nothing than to do something that will actually make no real difference As I see it, the reason we need to do *something* here -- and I think Russ's proposal is a good start for it -- is exactly that we're largely ignoring those basic rules and making up a new system without serious consideration. we have been ignoring some of these rules for a very long time - what makes now a good time to change them? Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Phillip politely says I think this is nonsense. We have been discussing this for over a decade. Time for debate is up. It is time to make a decision. since I see no reason to think that the proposed changes will do anything at all to address any of the problems that I, and others, have brought up (incuding the 'nothing progresses' problem) I have decided I see no reason that we should make a change that is very likely to not fix any known problem just because we have been talking about various ideas for change for a long time - length of debate is not an indication of usefulness of solution it would not be the end of the IETF if this gets published but it will also not be the begining of a better IETF - all of the problems will still be there and we would have a meaningless change just so we can say we made a change Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
I think that Phillip and I have agreed to disagree Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
US government and IPv6 (was US DoD and IPv6)
not the DoD but maybe of interest Scott http://www.cio.gov/Documents/IPv6MemoFINAL.pdf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-01
The ISD proposal required the IESG spend a lot of time that the individuals simply did not have. so the IESG insisted - that was not the opinion of the newtrk chair (who thought that ISDs would likely reduce the load on ADs Further, this came at a very, very bad time and that, apparently, kept (at least some) members of the IESG from seriously considering what was being proposed this was not the IESG's finest hour - lets leave it at that Scott (ex) newtrk chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Retention of blue sheets
the reason that the blue sheets were created was as part of maintaining a full record of the open standards process - the question of room size was never considered the basic idea is discussed in section 8 of RFC 2026 Each of the organizations involved in the development and approval of Internet Standards shall publicly announce, and shall maintain a publicly accessible record of, every activity in which it engages, to the extent that the activity represents the prosecution of any part of the Internet Standards Process. For purposes of this section, the organizations involved in the development and approval of Internet Standards includes the IETF, the IESG, the IAB, all IETF Working Groups, and the Internet Society Board of Trustees. 2026 does not specifically mention maintaining a list of who was at the meetings but that is clarly a part of a full record in addition, RFC 2418 section 3.1 requires obtaining a list of attendees All working group sessions (including those held outside of the IETF meetings) shall be reported by making minutes available. These minutes should include the agenda for the session, an account of the discussion including any decisions made, and a list of attendees. The Working Group Chair is responsible for insuring that session minutes are written and distributed, though the actual task may be performed by someone designated by the Working Group Chair. The minutes shall be submitted in printable ASCII text for publication in the IETF Proceedings, and for posting in the IETF Directories and are to be sent to: minu...@ietf.org Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Retention of blue sheets
Bill - sez Pointing this out for completeness sake, it is not currently required to sign said sheets to participate in WG sessions. no one is lording over you but it is expected that all people in the room will sign Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)
Aren't RFC 5377/5378 (and subsequent discussion) such a statement? sorry - I must have missed the announcement by the trust that they were responding to these RFCs Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)
Aren't RFC 5377/5378 (and subsequent discussion) such a statement? did I miss the posting that lists each of the proposed chages with a pointer to the specific request for change (or specific need for change) in these RFCs? Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions(TLP)
Some history that may explain some of my and some other reaction to the recent postings by the Trust When the Trust was formed a number of us were quite worried that it would begin to see itself as self directed and not as a function whose purpose was to act at the direction of and in support of the IETF. My own reaction to the recent postings from the Trust is that the Trust is moving in the direction that some of us were worried about -- the Trust posts a bunch of proposed changes out of the blue. Out of the blue because I did not see any posting that explained why they felt that they needed to make changes or that these specific changes were in response to particular IETF requests (or legal threats) - see the original posting at http://www.ietf.org/mail-archive/web/ietf/current/msg57276.html The reaction from the Trust to the comments from the community has not been reassuring. It is true that they modified some of their proposed changes but they do not seem to have understood the more basic issue that I expressed in my message to the Trust on Tue Jun 23 14:57:12. What I do not see in this message is pointers to where the IETF asked that the TRUST to make these changes it would be fine by me if the Trust were to send a note saying that we see the following problems - (and maybe, here are options we see) what whould you like us to do, it seems less fine for the Trust to get out ahead of the folks it is supposed to be working for in changing things (even if it provides a chance for the IETF to comment) The fact that there was no response to that message or to a number of other messages (in particular, messages from John Klensin) reinforces the worry about an out of control Trust. I think the Trust needs to press the reset button and start again. Start with a posting that says what problems they feel the IETF has asked them to fix and what other problems the feel need fixing, along with the specific change they propose to deal with each problem. We can then talk about each issue to determine if there is consensus that the problem needs fixing and if the proposed solution meets the needs. And, unless there is a specific legal threat that the Trust can point at this process should not be rushed. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)
Isn't this what has essentially happened in this case? I did not see a statement from the IETF asking for changes nor did I see a statement from the Trust saying that there are these issues that need to be fixed for legal or cosmetic reasons maybe there were such statements and I missed them what I did see was a bunch of changes without anything that said specifically what problem each change was trying to solve (not a justification for the change but a reason that any change is needed at all) we have been changing the IETF's IPR rules far too often (and I'm in no small way responsible for many of the changes) we should get out of that mode and only be making changes where there is a speific need to do so. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)
tme wrote: the comment period is extended to the 23rd of July. are we under some legal threat that requires this unseemly haste? Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)
I may have missed it but I did not see any response to my posting from when these changes were first proposed along the lines of what John just posted - I thought that the Trust was supposed to be responsive to requests from the IETF not go off on its own figuring out things to do I would like a clear statement of what the trust thinks its role is and if it not to be responsive to requests from the IETF I think we need to have a discussion on the IETF list to understand if any other role is one that is supported by the IETF community Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)
tme said: 6. Provide the rationale for proposed changes in the future, rather than a summary listing of the changes this, to me, is exactly the wrong way for the IETF Trust to work. I do not want a rationale for proposed changes it seems to me that the Trust should work in one of 3 ways depending on the situation 1st way: The IETF community provides the IETF Trust with a specific request and the Trust provides possible changes or new text to meet the specific request. The IETF request can come form a WG, in which case it should be in the form of a BCP (an IETF consensus document) or, with a public justification, from the IETF Chair (or maybe the IAB Chair). The Trust publishes the proposed changes with a 4-week last call and the changes are adopted if the IETF Chair determines that there is IETF consensus support for the specific changes. 2nd way: The IETF Trust determines that there is a specific legal risk that must be countered. In this case the IETF Trust posts a description of the specific risk and the proposed change to counter the risk. In this case the Trust publishes the proposed changes with a 4-week last call and adopts the changes if the IETF Chair determines that there is not IETF consensus against the specific changes. 3rd way: The IETF Trust determines that there are changes it would like to make that are not in response to a specific legal risk. In this case the Trust publishes a list of the reasons they feel that the changes are needed and the proposed changes. (Note: not a list of changes and the rationale for the changes - I think the IETF needs to agree that the problems are ones that need fixing first) The Trust publishes the proposed changes with a 4-week last call and the changes are adopted if the IETF Chair determines that there is IETF consensus support for each specific change. In no case does the IETF Trust adopt any changes without a public statement concerning IETF consensus by the IETF Chair. i.e., there is no default adoption of changes by the Trust. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
A more interesting question is if you can submit somebody else's public domain work to the IETF. I don't know the answer to that. Legally, yes; it's public domain. Academic honesty and common courtesy would demand an acknowledgment. more than that - the standards process requires an acknowledgment of all significant contributers so an acknowledgment is required Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Time for a sign-up campaign [Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary]
I'm disappointed at how few people have signed up. Even people who've been active in this debate haven't signed up to the old version. I signed the old form (on paper) and handed it in a while back but do not see my name on the list -- did a bit get dropped somewhere? Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
TSV Area review of draft-ietf-dime-qos-parameters
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. This ID describes some useful technology but I think it can be improved. My main issue is that the ID does not do a good enough job of making clear what the units of the parameters are or even what the meaning of some of the parameters are. Some of the information can be found by looking at the RFCs that are referenced but it would be cleaner to just include the information in this document. I was initially confused by the fact that section 3 contained no information on what the units of the parameters are but much of this is covered in section 4. (if it were up to me I'd put the units in section 3 as well - e.g. in section 3.2 I'd say that The Path Latency parameter (expressed in usec) refers to the accumulated latency ⦠) But not all of the units are explained in section 4 and some terms are left undefined. I'll only provide some examples here - I suggest that the authors step through the document and be sure that the units as well as the terms are defined in every case. For example, in section 3.1. The value large is not defined or explained, nor is the term policed unit. The document does not say what the units for rate (bytes per second?, packets per usec?) are or the units for bucket size (bytes?) - an educated guess can be made but it would be better if no guessing were needed. Another example, in section 3.2. The units for packet loss rate are not given (packets per second? % of packets?) Also, in section 4.5. It would be nice to have a few words say what 99.9%-ile means and how to calculate it for those who might not know nit: section 4.8 says A description of the semantic of the parameter values can be found in [RFC2212], [RFC2215]. Should this say [RFC2212] and [RFC2215]? nit: the first sentence under section 4.13.3 is not a sentence nit: section 6.1 - 4th pp says 1 to 511: Standards Action the pp following says range of 0-511 - should these be consistent? Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 2026 interpretation question
Worse, it is possible to read the current text of 2026 as requiring, especially in the absence of an ISOC newsletter, that a version of STD1 be published as an RFC before the clock starts running on the waiting period. I think that would violate common sense, especially given the interpretation of the second paragraph of RFC 2026 Section 6.2.4 as requiring a sixty-day waiting period between IESG action and RFC publication. I think that interpretation is clearly against the intent of 2026, as does the editor of 2026 Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Archives for closed WGs
Do we archive charters and complete millstones for closed WGs? see http://www.tools.ietf.org/wg/concluded ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Archives for closed WGs
ps - very impressive work by the tools group Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Archives for closed WGs
Oh gosh, I hope we're not archiving all those WG millstones... in the fiction department :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Removal of IETF patent disclosures?
it seems to be a real bad idea to let people actually remove
any type of IPR statement that might have been relied upon
by a WG in any way and since its hard to figure out if
thats the case, it seems like a real bad idea to let someone
remove a IPR statement at all
having a way for someone (properly verified) to mark the statement
as no longer in effect (with a reason as to why) might be OK
except that I find it hard to see why the IETF would want to
make it easier for an IPR holder to mislead a WG on the IPR
holder's intentions ('you can have it' 'oops, I did not mean that')
there could be a real issue if someone who did not have the
authority to do so committed a IPR holder to specific IPR
terms (like free) but that seems to be a problem for the
IPR holder to deal with internally since I'm far from sure
what the legal precident is for that sort of thing
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: new text for ID_Checklist sect 3, item 6
good stuff --- From [EMAIL PROTECTED] Wed Aug 13 06:54:56 2008 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] From: Bert Wijnen \(IETF\) [EMAIL PROTECTED] To: IETF Discussion ietf@ietf.org Subject: new text for ID_Checklist sect 3, item 6 Date: Wed, 13 Aug 2008 12:21:41 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion ietf.ietf.org List-Unsubscribe: https://www.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] List-Post: mailto:ietf@ietf.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://www.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; Format=flowed Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] The revision 1.8 of the ID-Checklist is at http://www.ietf.org/ID-Checklist.html Sect 3, item 6 in that revision states: 6. Addresses used in examples SHOULD use fully qualified domain names instead of literal IP addresses, and SHOULD use example fqdn's such as foo.example.com instead of real-world fqdn's. See [RFC2606] for example domain names that can be used. John Klensin has proposed new text, whcih was amended by Ted Hardie and the resulting text (if I understood it correctly) is: 6. Addresses used in I-Ds SHOULD use fully qualified domain names (FQDNs) instead of literal IP addresses. Working Groups or authors seeing exemptions from that rule MUST supply the rationale for IP address use with inline comments (e.g., Editor's note: or Note in Draft: that can be evaluated by the IESG and the community along with the rest of the document. Example domains in pseudo-code, actual code segments, sample data structures and templates, specifically including MIB definitions and examples that could reasonably be expected to be partially or entirely copied into code, MUST be drawn from the list reserved for documentary use in BCP32 (RFC 2606 or its successors). It is generally desirable for domain names used in other I-D discussion contexts to be drawn from BCP32 as well, if only as an act of politeness toward those who might be using the domains for other purposes at the time of publication or subsequently. Working groups or editors who are convinced that different names are required MUST be prepared to explain and justify their choices and SHOULD do so with explicit inline comments such as those described above. From the discussion on the list (that I have seen), people seem to be OK with that text. It is quite a bit longer, but so be it. Does anyone have objections to the above text as replacement for the current text? Bert Editor for ID_Checklist ___ 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: Proposed Experiment: More Meeting Time on Friday for IETF 73
an observation: With today's half day on Friday a good percentage of those people who chose to stay until noon can still catch a flight home that same day in most IETF meeting locations (except for people flying across some ocean). Moving the end time on Friday until 15:15 would cut that percentage considerably - so for many people this would mean an extra day in the hotel (and the expense of that) as well as ensuring a good chunk of another weekend day away from family. My prediction is that the attendance at the Friday afternoon sessions will likely be quite low. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
if indeed RFC 2606 (a.k.a, BCP 32) said all domain names in RFCs MUST use one of the following bases then a blocking DISCUSS by an IESG member would be a reasonable thing. RFC 2606 does not say that and, thus, a blocking DISCUSS is not reasonable if the IESG had posted a set of rules that said the same thing and asked for community comment and the comunity consensus supported the rules then a blocking DISCUSS by an IESG member would be a reasonable thing. But no such rules were posted and no such comunity consensus was shown. (Actually, I whoud hope that comunity consensus woud be against the idea of the IESG doing any such thing since such things should be left to normal IETF process rather that to management from the top.) Scott ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Blue sheet harvest
it started w/ folsk scanning the pages of the early bound copies of IETFF proceedings. the sheets are no longer included in the proceedings the process you describe has happend in recent memory at more than one IETF. at what scale? 100s of people? 10s? Scott ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Blue sheet harvest
and signing the sheet is strictly voluntary to date well, there are no guards with guns watching but someone who decides to not sign is not being honest about their participation Scott ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Blue Sheet Change Proposal
Ole guessed My understanding is that the blue sheet serves mainly as a record of who was in the room which I think is largely used to plan room capacities for the next meeting. the blue sheets are required as part of the basic openness process in a standards organization - there is a need to know who is in the room (see RFC 2418 section 3.1 for the actual requirement) the blue sheets become part of the formal record of the standards process and can be retrieved if needed (e.g. in a lawsuit) but are not generally made available as pointed out by Mark Andrews - email addresses can be useful in determining the actual identity of the person who scrawled their name on the sheet - so it is an advantage to retain them I'm trying to understand how the blue sheets contribute in any significant way to the spam problem - someone whould have to be surreptitiously copying them or quickly writing down the email addresses - both could happen but do not seem to be all that likely there are far more efficient ways to grab email addresses so, my question is is this a problem that needs solving? Scott ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Blue Sheet Change Proposal
that would test something but I'm not sure you could isolate the spam-fear factor Scott --- Date: Thu, 03 Apr 2008 17:44:47 -0700 From: Eric Rescorla [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Scott O. Bradner) Cc: ietf@ietf.org, [EMAIL PROTECTED] Subject: Re: Blue Sheet Change Proposal Content-Type: text/plain; charset=US-ASCII At Thu, 3 Apr 2008 20:10:12 -0400 (EDT), Scott O. Bradner wrote: Ole guessed My understanding is that the blue sheet serves mainly as a record of who was in the room which I think is largely used to plan room capacities for the next meeting. the blue sheets are required as part of the basic openness process in a standards organization - there is a need to know who is in the room (see RFC 2418 section 3.1 for the actual requirement) the blue sheets become part of the formal record of the standards process and can be retrieved if needed (e.g. in a lawsuit) but are not generally made available as pointed out by Mark Andrews - email addresses can be useful in determining the actual identity of the person who scrawled their name on the sheet - so it is an advantage to retain them I'm trying to understand how the blue sheets contribute in any significant way to the spam problem - someone whould have to be surreptitiously copying them or quickly writing down the email addresses - both could happen but do not seem to be all that likely there are far more efficient ways to grab email addresses so, my question is is this a problem that needs solving? The only reason I've heard is that some claim that people don't write their names on the blue sheets out of concern over spam. This actually seems like something we could test pretty easily by counting room entries and blue sheet entries and comparing the totals... -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call for two IPR WG Dcouments
My suggestion is to rewrite section 4 a bit to call out that this document does not cover the incoming rights for the independent and irtf stream and to use the terms ietf-stream and possibly iab- stream in the definitions. thats all well good for the independent stream since they have their own ruleset but gets tricky for irtf unless they do and splitting off iert iab from teh rest of the ietf seems a bit funky Scott ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the ..
sorry - it does not make any sense at all to last call this document it has had no meaningful discussion - we should not be updating our core process documents this flippantly Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the ..
Russ, I was specifically not commenting on the contents of this ID (I will soon) but on the process being followed I see no justification of issuing an IETF Last Call on a ID that is designed to modify our core process document where the document has gotten so little discussion or indication of support John's suggestion of a plenary discussion may be a reasonable path but I do not think that using the IETF Last Call process to ferment discussion is all that good a way to proceed (this is what I was calling flippent) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the ..
substantive review: I think that Brian has pointed out a number of areas where, if we were to produce a revised 2026, work needs to be done and I think that some number (but by no means all) of his suggestions are good, but 1/ I think a delta of this complexity makes the result unreadable - a new version of 2026 would make far more sense 2/ I do not think we are remotely ready to produce a revised 2026 (no matter how much I would like to) process- and discussion-wise that said, some notes as if this might move forward I'm not sure that tweaking STD is enough of a problem to fix - STDs are mostly ignored and thus do not get in the way re expired IDs: see, for example http://tools.ietf.org/id/draft-bradner-pbk-frame-00.txt i.e, expired IDs are available through tools.ietf.org (a good thing in my mind) but confuses the suggested text changes TS vs AS - it would be good to say that a TS can include an AS - but I'm not sure one needs to do much more than that I'm not sure much needs to be done in a delta document about requirement levels other than mention RFC 4897 renaming the standards levels a bit of history the first place I found that lists the standards levels is RFC 1083 (Dec 1988) - that lists Proposed Protocol, Draft Standard Protocol and Standard Protocol Proposed Protocol switched to Proposed Standard Protocol in RFC 1140 (May 1990) The current usage (dropping protocol) was established by the time that RFC 1310 was published (March 1992) so we have been using basically the same names since 1990 - I'd want to see a very good reason to change names with that amount of history behind them - and I do not see it here - I do think that we have issues with the 3-level process but tweaking the names in this way would: 1/ confuse 2/ not prevent deployment at the first IESG-approved stage (since we often get deployment at the Internet Draft stage) re: interoperability requirements - Brian details some real issues here and having a quick punt to the IESG to say what it mans may not be a bad idea but this is something that may deserve a separate document because the details of interpretation will change from time to time - and its easier to update a stand alone doc re: informational RFCs - proposed addition makes sense re - non WG. sponsored info exp RFCs - I do not like this process anyway when it is uses as a way around getting a nasty (in some people's minds) IESG note on their RFC (which can happen if it goes through the RFC Editor) - I'd rather this escape route were closed and the IESG note made more factual and less something that an author would want to avoid - if the path involves real IESG review then it would be good to note that in the RFC (and note the same in wg info exp RFCs) re: stale proposed draft standards - something like what Brian proposes makes sense re: appeals kickoff - if it applies to any decision whatever then how about document editor decisions? (document editors are not appointed by the IESG) or decisions by the IETF Trust or IAD (also not appointed by the IESG) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Harald sed: For the implementors, an I-D + the fact of approval is sufficient. For those who write other documents, it's not - they need the RFC number. including the folk in other SDOs that want to point to IETF documents Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
tools everywhere (was Daily Dose version 2 launched
Joel sed: The basic issue for me is that from the tools page I expect to find the tools. my basic issue is somewhat different in that its not a future issue why does tools have to show up in just about every IETF URL these days? nomcom feedback for example - yes its a tool but the key is that its related to the nomcom not that its a tool - some thing for id submission www.ietf.org/id/submit www.ietf.org/nomcom/feedback etc Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: tools everywhere (was Daily Dose version 2 launched
brian corrected: ID submission isn't at the tools server, it's at https://datatracker.ietf.org/idst/upload.cgi true but it shows my point as well why not www.ietf.org/id/submit datatracker is a meaningful as tools in this context Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Free? Software Foundation
it is interesting that the free software foundation is espousing censorship Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Free? Software Foundation
I seem to have hit a nerve you are asking the IETF to not publish an IETF doucment - what else can you call it? Scott --- On Mon, Oct 29, 2007 at 09:55:06AM -0400, Scott O. Bradner [EMAIL PROTECTED] wrote a message of 9 lines which said: it is interesting that the free software foundation is espousing censorship It is absolutely ridiculous to call censorship a call to NOT publish in *our* RFC series a document. Censorship would be if IETF exerciced powers (which it does not have) to prevent ANY publication of this document anywhere. If I do not publish your rants on my blog, for instance, it it not censorship, you can always publish it elsewehere. Your misusage of words could be excused only if english were not your native language. Such an outrageous claim is common on /. or similar sites but I did not expect it on an IETF mailing list (except by JFC or similar trolls). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt
we received similar comments during the transport directorate review of the IPFIX implementation guidelines. The new revision of the document, now available at: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guidelines-07.txt might address your concerns. I'm copying the UDP section here below for your convenience. this text is good as far as it goes, I'd suggest adding specific 'you may easily kill the network' language (along the lines of what I said in a previous message) - that warning is more implied than stated in the current text then it would be good to add a specific pointer to that section of the guidelines in the UDP section of the protocol document thanks Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-ietf-ipfix-protocol-26.txt
I reviewed draft-ietf-ipfix-protocol-26.txt as part of the Transport Area review effort. I did not find any particular issues in the described technology - a few nits: section 3.1 Export Time someday the IETF needs to stop using 32-bit seconds since 1 jan 1970 for timing - at least within in the next 31 years section 6.1.2 - it might be reasonable to add the IEEE 8-byte MAC address as an address type - this is used in ZigBee and may be in wider use in the future section 10.3.3 - a max packet size of 1280 could be used if the connection is known to be running in an IPv6-only environment I'm not sure why the packet size discussion is only listed for UDP - it seems like the same restriction should apply to all protocols - fragmentation is not your friend Historically the biggest issue with IPFIX has been that most implementers want to run it over UDP with consequences be dammed. - this was weaseled in the IPFIX Requirements document (RFC 3917) by requiring (in section 6.3.1) that For the data transfer, a congestion aware protocol must be supported. This draft meets that requirement by making the implementation of SCTP a MUST. That will not stop many implementers from ignoring the requirement for implementation or users to enable UDP and thus creating a potentially very high bandwidth non-congestion avoiding fire hose that can quite easily wipe out a net by misconfiguration or become a DoS engine by purposeful configuration. I'm not sure if anything can be actually be done about this risk - It might help some to say that UDP is a MUST NOT but I doubt it - in any case it would help somewhat, imho, to expand section 10.3 to be clearer about the threats posed by any use of a non-congestion avoiding transport protocol or to do that in the Security Considerations section Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt
yeh - I read that but am not convinced that the message is clear enough of what can happen if those rules are not followed Scott --- Date: Tue, 25 Sep 2007 23:02:52 +0100 From: Stewart Bryant [EMAIL PROTECTED] To: Scott O. Bradner [EMAIL PROTECTED] Cc: ietf@ietf.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt Scott Historically the biggest issue with IPFIX has been that most implementers want to run it over UDP with consequences be dammed. - this was weaseled in the IPFIX Requirements document (RFC 3917) by requiring (in section 6.3.1) that For the data transfer, a congestion aware protocol must be supported. This draft meets that requirement by making the implementation of SCTP a MUST. That will not stop many implementers from ignoring the requirement for implementation or users to enable UDP and thus creating a potentially very high bandwidth non-congestion avoiding fire hose that can quite easily wipe out a net by misconfiguration or become a DoS engine by purposeful configuration. I'm not sure if anything can be actually be done about this risk - It might help some to say that UDP is a MUST NOT but I doubt it - in any case it would help somewhat, imho, to expand section 10.3 to be clearer about the threats posed by any use of a non-congestion avoiding transport protocol or to do that in the Security Considerations section There is text in section 10.1 which states: UDP MAY be used although it is not a congestion aware protocol. However, the IPFIX traffic between Exporter and Collector MUST run in an environment where IPFIX traffic has been provisioned for or is contained through some other means. This sets out the set of conditions that MUST be fulfilled in order to run IPFIX over UDP safely. Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Streaming
I already have links to Agendas, Jabber-rooms, Meeting-materials, draft tarballs and room location on http://tools.ietf.org/agenda, so it seems like a good idea to add links to the audio streams, too (in addition to any mention which is added to the IETF69 Meeting page). seems to me that there should be a clear link on the meeting web page (http://www3.ietf.org/meetings/69-IETF.html) for both the audio and jabber services (unless the aim is to minimize use) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
If our consensus process is not independently and openly verifiable, we might as well close shop! a hum in a WG meeting is subject to the perceptions of the people in the room but its not clear that a fully verifiable process is needed since we specifically try to do rough consensus not majority vote - all we need to be able to verify is that most people support a path - if a proposal gets blocked by a secret whisper in the ear of the WG chair then things are very broken indeed if the result of a secret whisper results in the chair brings up topics for public discussion I'm not all that worried Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
free standards [was Re: Withdrawal of Approval and Second Last ...]
Simon sez: According to what definition of 'free standards'? I agree with the other Scott - please be clear in what you are wanting to write about there seem to be as many definitions of free standards as people writing about them - my definition revolves around how much money to I have to pay to get a copy of the standard - as in 'the ITU-T recomendations (a.k.a, standards) used to cost money to get but are now free' or 'I can download the IETF RFCs from the web for free.' if you want to write about standards that have no known patent licensing requirements then say that (observation: you can not write about standards that have no patent licensing requirements if you are talking about standards less than 20 years old because there is no way to know if a standard is in that set) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
But its Informational. My read of RFC 2026 says that the 4 week case applies to Standards Track only. rfc 2026 says what must be done in some cases - it does not say what can not be done in the cases it does not cover - specifically, RFC 2026 in no way would block a 4-week last call for an informational RFC - note that RFC 2026 does not require any last call for informationals fwiw - I agree with John - this doc warents a longer last call because it does impact how part of the IETF process will work and the draft did not get vetted in a normal working group process Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria
to follow up on Dave's note * The IETF as a whole does not have consensus on the technical approach or document. There are cases where individual working groups or areas have forged rough consensus around a technical approach which does not garner IETF consensus. An AD may DISCUSS a document where she or he believes this to be the case. While the Area Director should describe the technical area where consensus is flawed, the focus of the DISCUSS and its resolution should be on how to forge a cross-IETF consensus. what actual evidence must an AD present to indicate that the assertion of non-consensus is anywhere but in the one AD's mind? Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
