Re: Last Call: draft-kolkman-proposed-standards-clarified-03.txt (Characterization of Proposed Standards) to Best Current Practice
On 25 sep. 2013, at 12:44, Benoit Claise bcla...@cisco.com wrote: Reading this draft, I wonder: why would someone still want to go for Internet Standard, since PS is mature, as mature as final standards from other standards development organizations? Maybe you want to expand on this. There is a real difference IMHO. For an Internet Standard the IETF came back after some time and assessed that there were really no hurdles to gain interoperability. It is an IETF seal of an observed track-record.That is a _maintenance_ issue. An important piece of standardization is the maintenance of the standards suite. Not sure if that needs words in the draft. Thanks for the editorial nits. I'll safe them for after last call has finished. --Olaf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
Based on the conversation below I converged to: t While less mature specifications will usually be published as Informational or Experimental RFCs, the IETF may, in exceptional cases, publish a specification that still contains areas for improvement or certain uncertainties about whether the best engineering choices are made. In those cases that fact will be clearly and prominently communicated in the document e.g. in the abstract, the introduction, or a separate section or statement. /t I will be publishing version 02 shortly. --Olaf [This is a top-post, nothing but context below] On 16 sep. 2013, at 18:04, John C Klensin john-i...@jck.com wrote: --On Monday, September 16, 2013 10:43 -0400 Barry Leiba barryle...@computer.org wrote: ... I agree that we're normally requiring much more of PS documents than we used to, and that it's good that we document that and let external organizations know. At the same time, we are sometimes proposing things that we know not to be fully baked (some of these came out of the sieve, imapext, and morg working groups, for example), but we *do* want to propose them as standards, not make them Experimental. I want to be sure we have a way to continue to do that. The text Olaf proposes is, I think, acceptable for that. In case it wasn't clear, I have no problems with that at all. I was objecting to three things that Olaf's newer text has fixed: (1) It is a very strong assertion to say that the above is exceptional. In particular, exceptional would normally imply a different or supplemental approval process to make the exception. If all that is intended is to say that we don't do it very often, then commonly (Olaf's term), usually, or perhaps even normally are better terms. (2) While it actually may be the common practice, I have difficulty with anything that reinforces the notion that the IESG makes standardization decisions separate from IETF consensus. While it isn't current practice either, I believe that, were the IESG to actually do that in an area of significance, it would call for appeals and/or recalls. Olaf's older text implied that the decision to publish a not-fully-mature or incomplete specification was entirely an IESG one. While the text in 2026, especially taken out of context, is no better (and Olaf just copied the relevant bits), I have a problem with any action that appears to reinforce that view or to grant the IESG authority to act independently of the community. (3) As a matter of policy and RFCs of editorially high quality, I think it is better to have explanations of loose ends and not-fully-baked characteristics of standards integrated into the document rather than using IESG Statements. I don't think Olaf's new front page requirement is correct (although I can live with it) -- I'd rather just say clearly and prominently communicated in the document and leave the is it clear and prominent enough question for Last Call -- but don't want to see it _forced_ into an IESG statement. I do note that front page and Introduction are typically inconsistent requirements (header + abstract + status and copyright boilerplate + TOC usually force the Introduction to the second or third page). More important, if a real explanation of half-baked features (and why they aren't fully baked) may require a section, or more than one, on it own. One would normally like a cross reference to those sections in the Introduction and possibly even mention in the Abstract, but forcing the text into the Introduction (even with preferably given experience with how easily that turns into a nearly-firm requirement) is just a bad idea in a procedures document. We should say clearly, prominently, or both and then leave specifics about what that means to conversations between the authors, the IESG and community, and the RFC Editor. best, john signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
On 16 sep. 2013, at 17:31, John C Klensin john-i...@jck.com wrote: As actionable for this draft I take that I explicitly mention that Section 4.1 2026 is exclusively updated. While I understand your desire to keep this short, the pragmatic reality is that your non-IETF audience is likely to read this document (especially after you hand it to them) and conclude that it is the whole story. Since the natural question that immediately follows why should we accept your standards at all is why can't you hand them off to, e.g., ISO, the way that many national bodies and organizations like IEEE do with many of their documents. Suggestion in the interest of brevity: in addition to mentioning the above, mention explicitly that there are requirements in other sections of 2026 that affect what is standardized and how. Second paragraph of the introduction now reads: This document exclusively updates the characterization of Proposed Standards from RFC2026 Section 4.1.1 and does not speak to or alter the procedures for the maintenance of Standards Track documents from RFC 2026 and xref target=RFC6410RFC 6410/xref. For complete understanding of the requirements for standardization those documents should be read in conjunction with this document. By the way, while I understand all of the reasons why we don't want to actually replace 2026 (and agree with most of them), things are getting to the point that it takes far too much energy to actually figure out what the rules are. Perhaps it is time for someone to create an unofficial redlined version of 2026 that incorporates all of the changes and put it up on the web somewhere. I think we would want a clear introduction and disclaimer that it might be be exactly correct and that only the RFCs are normative, but the accumulation of changes may otherwise be taking us too far into the obscure. If we need a place to put it, it might be a good appendix to the Tao. And constructing it might be a good job for a relative newcomer who is trying to understand the ins and outs of our formal procedures. I guess this is a call for volunteers. --Olaf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
FYI. I just posted the third version of the draft at: http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02 Diff with the previous document: http://tools.ietf.org/rfcdiff?url2=draft-kolkman-proposed-standards-clarified-02.txt I will let Jari know that I believe we converged and that as far as I am concerned its last call time. --Olaf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
On 13 sep. 2013, at 21:02, Adrian Farrel adr...@olddog.co.uk wrote: Hey Olaf, Thanks for stubbornly pushing on with this. Comments (sorry I haven't read the thread to see if others have already made these comments)… This is to acknowledge I took the suggestions that I am not quoting. --- Section 2 clarity of the standards document Prefer Standards Track document This is a change to the original 2026 language, but I support it it makes really clear what we are taking about. --- Section 2 over the last decade or more have had extensive review. ...by the IESG? ...by or on behalf of the IESG? That is already explained in the paragraphs above. I propose to just keep the focus on the document having had review and not make an addition to that sentence. On the other hand, elsewhere in the thread John Klensin made the case that we should stress that the IESG does this quality assurance since that is different from other SDOs, this might be a good place to add that extra emphasis. As said, I keep the text as is for now but I will take editorial guidance if this is a serious issue. --- Section 2 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 by the IESG. I wonder whether you should add ...a position that is further strengthened by the implementation and running code that is often present before publication as a Proposed Standard. Added, but with the word Interoperable added. Could you review if this is still proper English and contact me off-list if it isn't: In fact, the IETF review is more extensive than is done in other SDOs due to the cross-area technical review performed by the IESG, a position that is further strengthened by the regular precense of interoperable implementation and running code before publication as a Proposed Standard. --- Section 3.1 Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. You could add ... and may be tracked and reported as described in [RFC6982] Hmmm.. I want to be careful with that reference. It is an experimental document and increases the referential complexity for little benefit. Until serious pushback otherwise I propose to not take over this suggestion. --- Section 3.1 Two paragraphs seem to enjoy some duplication in their final sentences. A Proposed Standard specification is stable, has resolved known design choices, is well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, as with all technical standards, further experience might result in a change or even retraction of the specification in the future. and A Proposed Standard will have no known technical omissions with respect to the requirements placed upon it. Proposed Standards are of such quality that implementations can be deployed in the Internet. However, as with all technical specifications, Proposed Standards may be revised if problems are found or better solutions are identified, when experiences with deploying implementations of such technologies at scale is gathered. Fixed by removing that final sentence at first occurrence. I'll wait a few days to see discussion converge before posting 02 in the mean time: pre 02 is at: http://www.secret-wg.org/Secret-Media/draft-kolkman-proposed-standards-clarified-pre02-2013091600.txt with a diff at: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-kolkman-proposed-standards-clarified-01.txturl2=http://www.secret-wg.org/Secret-Media/draft-kolkman-proposed-standards-clarified-pre02-2013091600.txt Thanks, --Olaf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
[Barry added explicitly to the CC as this speaks to 'his' issue] On 13 sep. 2013, at 20:57, John C Klensin klen...@jck.com wrote: [… skip …] * Added the Further Consideration section based on discussion on themailinglist. Unfortunately, IMO, it is misleading to the extent that you are capture existing practice rather than taking us off in new directions. Yeah it is a thin line. But the language was introduced to keep a current practice possible (as argued by Barry I believe). You wrote: While commonly less mature specifications will be published as Informational or Experimental RFCs, the IETF may, in exceptional cases, publish a specification that does not match the characterizations above as a Proposed Standard. In those cases that fact will be clearly communicated on the front page of the RFC e.g. means of an IESG statement. On the one hand, I can't remember when the IESG has published something as a Proposed Standard with community consensus and with an attached IESG statement that says that they and the community had to hold our collective noses, but decided to approve as PS anyway. Because, at least in theory, a PS represents community consensus, not just IESG consensus (see below), I would expect (or at least hope for) an immediate appeal of an approval containing such as statement unless it (the statement itself, not just the opinion) matched community consensus developed during Last Call. Conversely, the existing rules clearly allow a document to be considered as a Proposed Standard that contains a paragraph describing loose ends and points of fragility, that expresses the hope that the cases won't arise very often and that a future version will clarify how the issues should be handled based on experience. That is no known technical omissions since the issues are identified and therefore known and not omissions. In the current climate, I'd expect such a document to have a very hard time on Last Call as people argued for Experimental or even keeping it as an I-D until all of the loose ends were tied up. But, if there were rough consensus for approving it, I'd expect it to be approved without any prefatory, in-document, IESG notes (snarky or otherwise). The above may or may not be tied up with the generally stable terminology. I could see a spec with explicit this is still uncertain and, if we are wrong, might change language in it on the same basis as the loose end description above. Such language would be consistent with generally stable but, since it suggests a known point of potential instability, it is not consistent with stable. I see where you are going. draft Proposed rewrite While commonly less mature specifications will be published as Informational or Experimental RFCs, the IETF may, in exceptional cases, publish a specification that still contains areas for improvement or certain uncertainties about whether the best engineering choices are made. In those cases that fact will be clearly communicated in the document prefereably on the front page of the RFC e.g. in the introduction or a separate statement. /draft I hope that removing the example of the IESG statement makes clear that this is normally part of the development process. Additional observations based on mostly-unrelated recent discussions: If you are really trying to clean 2026 up and turn the present document into something that can be circulated to other groups without 2026 itself, then the change control requirement/ assumption of RFC 2026 Section 7.1.3 needs to be incorporated into your new Section 3. It is not only about internal debates, it is our rule against why we can't just endorse a standard developed elsewhere as an IETF standards track specification. Along the same lines but more broadly, both the sections of 2026 you are replacing and your new text, if read in isolation, strongly imply that these are several decisions, including those to approve standardization, that the IESG makes on its own judgment and discretion. I think it is fairly clear from the rest of 2026 (and 2028 and friends and IETF oral tradition) that the IESG is a collector and interpreter of community consensus, not a body that is someone delegated to use its own judgment. I believe that, if an IESG were ever to say something that amounted to the community consensus is X, but they are wrong, so we are selecting or approving not-X, we would either see a revolution of the same character that brought us to 2026 or the end of the IETF's effectiveness as a broadly-based standards body. More important --and related to some of my comments that you deferred to a different discussion-- the IESG as final _technical_ review and interpreter of consensus model is very different from that in some other SDOs in which the final approval step is strictly a procedural and/or legal review that is a consensus review only in the sense of
Re: PS Characterization Clarified
Colleagues [I have added a number of people who were active in the discussion previously to the CC, my apologies if that is bad etiquette but I wanted to make you explicitly aware of this.] Based on the discussion so far I've made a few modifications to the draft. I am trying to consciously keep this document to the minimum that is needed to achieve 'less is more' and my feeling is that where we are now is close to the sweetspot of consensus. This is the summary of these changes: * Added Updates 2026 and added Sean's initial * Copied the whole characterization pararaph for Internet Standards from 2026, instead of only the line that is the actual characterization itself. * Added the Further Consideration section based on discussion on the mailinglist. See: http://www.ietf.org/id/draft-kolkman-proposed-standards-clarified-01.txt For diff: http://tools.ietf.org/rfcdiff?url2=draft-kolkman-proposed-standards-clarified-01.txt --Olaf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
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. The two references in Section 7 would have to be normative references. Yes. (see PS) Thanks, and best, --Olaf PS. I think this is xml2rfc playing up. The xml contains this: back references title='Normative References' rfc2026; rfc6410; /references section title=Acknowledgements ….. But it seems to not want to translate . If anybody has suggestions, off-list please. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
On 13 sep. 2013, at 20:03, Carsten Bormann c...@tzi.org wrote: On Sep 13, 2013, at 16:56, Olaf Kolkman o...@nlnetlabs.nl wrote: * Added the Further Consideration section based on discussion on the mailinglist. I believe the current document is fine for a major part of the IETF standards activities. It is, however, important to keep in mind that the IETF is not a homogeneous organization, not even within each of the quite different areas. Section 4 seems to try to open up the straightjacket created by section 3 a little bit again, but the way it does this is probably the wrong approach. Note this is not trying to change… I is trying to document what we do now. On https://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf I am trying to see what one gets if one translates the fallacies into positive actions, or answer the question on how do you cope with the fallacy. I notice that your draft observes but doesn't seem to recommend. That is not a value judgement on the text btw but it doesn't give me insight in if 'this is probably wrong' what is the right way? And more important, is there any indication we can get there? I believe we had several tries in doing something different (better, was the intention of all those that took part in that debate) but we never reached consensus. That is why this is not trying to change, but tries to document the realities. Have a nice weekend. --Olaf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
On 2 sep. 2013, at 22:14, John C Klensin john-i...@jck.com wrote: --On Monday, 02 September, 2013 14:09 -0400 Scott O Bradner s...@sobco.com wrote: 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 More than that. Unless we want to deserve the credibility problems we sometimes accuse others of having, nothing should be a full standard, no matter how popular, unless it reflects good engineering practice. I think there is more flexibility for Proposed Standards, especially if they come with commentary or applicability statements, but I believe that, in general, the community should consider bad design or bad engineering practice to fall into the known defect category of RFC 2026. If RFC 6410 requires, or even allows, that we promote things merely because they are popular, then I suggest there is something seriously wrong with it. John, +1 All, 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. 4.1.3 Internet Standard A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community. 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. And for what its worth. One of the concerns most seen are those of IPR. The stamp of Internet Standard is a confirmation of the community that any IPR on the specification can be death with, that is an important piece of information on layer 9. = On a more generic note. The reason I took initiative for this draft is mainly because I believe we need to do what we document and document what we do. As discussed in this thread the practice for the approval of PS has changed, the bar is much higher than 20 years ago. In this case it is good that we document what we do. That shouldn't be a motivation to not do what we document: namely be serious about the maintenance of our standards. And I would hope that somehow we as a community find the energy needed to advance our specification in a way that truly assesses the requirements of RFC2026 sect 4.1.3 * significant implementation * successful operational experience * technical maturity * significant benefit to the Internet community. --Olaf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PS Characterization Clarified
Barry, Question, in-line. On Sep 3, 2013, at 10: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. Wouldn't such spec come with an applicability statement of sorts? (today, in practice?) 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? This draft is mostly targeted to document what we do, not what we want. Although I can see how you want to keep the door open. --Olaf.
Re: Community Feedback: IETF Trust Agreement Issues
On Aug 3, 2013, at 8:48 AM, Chris Griffiths cgriffi...@gmail.com wrote: IETF Community, The IETF Trust Trustees would like feedback from the community on several issues: - We have received requests that we cannot accommodate and have consulted legal counsel to review our options - The trust agreement does not allow the trustees to effectively manage some trust assets From this mail it is not clear what type of feedback you are looking for. I like your direct question from the slide deck better. There you asked: Does the community feel these are reasonable reasons to update the trust agreement? The answer to that question is: yes. It seems reasonable to open up the agreement in order to fulfill its purpose in reasonable, effective, and pragmatic ways. I would expect the trust to come back with a proposal once there seems to be consensus that the the agreement should be opened. My requirement would be that that proposal reflects that the Trust will deal with the assets in a way that is sensible and serves community needs. Best, and thanks, --Olaf PS. As an aside, something that might be helpful for other readers of this thread: The word agreement in Trust Agreement might be confusing to the community, but I think that it is important to point out that the agreement can, since July 1, 2010, be modified unilaterally by the trust (see 10.1 for details and boundary conditions). So except the due diligence that is needed to reflect the communities requirements there is no further negotiation needed with the Settlers. signature.asc Description: Message signed with OpenPGP using GPGMail
PS Characterization Clarified
Colleagues, I have posted draft-kolkman-proposed-standards-clarified-00.txt We have evolved the quality criteria for our entry-level maturity level and todays documentation doesn't reflect that. With this document we intend to align our characterization of PS with what is the current day reality. Having 'Immaturity' terminology in RFC2024 and having a large number of specifications that remain on proposed standard is something that is hard to explain by anybody talking about the quality of IETF standards[*]. But that is not the only, or even primary, motivation for submitting this. It is good for the people participating in the IETF to be aligned on our quality norms. The I-D does not speak to, or alter the process by which we progress on the maturity track. --Olaf [*] e.g. in regulatory and industry context such as http://ec.europa.eu/transparency/regexpert/index.cfm?do=groupDetail.groupDetailgroupID=2758 PS. As an aside, with reference to the discussion about progressing standards during the Administrative plenary. I would like to stress that the quality control (cross area review, progressing along the standards track, and retiring specification) that our maintenance mechanisms provide are an important part in the conversation about RFCs with external business and policy parties. URL: http://www.ietf.org/id/draft-kolkman-proposed-standards-clarified-00.txt
Re: call for ideas: tail-heavy IETF process
On May 5, 2013, at 7:54 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: On 05/05/2013 01:37 PM, Benoit Claise wrote: On 2/05/2013 18:17, Carsten Bormann wrote: On May 2, 2013, at 07:21, Eggert, Lars l...@netapp.com wrote: Yeah, all kinds of issues, but if we created a new thing here in between WGLC and PS, the broader industry would never understand. That is a matter of naming and marketing (candidate RFC?). There is already some misconception between I-RFC and Standards Tracks RFC. I don't believe that adding a new name/category would help: instead it would add to the confusion. Regards, Benoit Interesting that you mention this. A note from a recent experience: Together with Olaf we are participating in a European Multistakeholder Platform for ICT standardization, see http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:C:2011:349:0004:0006:EN:PDF The aim of this group is to find out how to reference IETF RFC (and standards from other organizations, like the W3C) since the European Commission seems to be unable to just reference standards beyond a small set of organizations (such as ETSI). As you can imagine, the different types of RFCs are not that easy to understand for those who do not participate actively in the IETF. Getting others to understand the different streams, the various document types and different standards is already difficult and maybe there is room for simplification here. FWIW. I think the difference between Informational and Standards track is fairly easily explained (in that context), having all the information in the headers and boilerplates helps. Where things become difficult is at the point where the maintenance of our standards need to be explained and questions about progression on the standards ladder get asked. Personally I hope that RFC 6410 has the effect that we, as a community, get serious about promoting our proposed standards, or obsolete them. I wonder how many standards got promoted after 6410 was published. --Olaf
Re: IAOC Request for community feedback
On Oct 23, 2012, at 1:49 AM, The IAOC bob.hin...@gmail.com wrote: The IAOC is requesting feedback from the community concerning a vacancy that the IAOC feels is not adequately covered by existing IETF rules. Marshall Eubanks has been a active IETF participant for many years and a member of the IAOC since 2009. However, he recently stopped participating in the IAOC and Trust. First: I cannot help to think there is a personal tragedy behind all this. I hope Marshall makes it back to this community because I will miss him. [ deep breath ] That said, I believe Bob made a case: Regardless of definition there seems to be a problem. Reading this thread I am sensitive to the arguments that we have a process that prevents people being removed without due diligence and I understand that if one does not follow the procedure one may be creating dangerous and exploitable precedents. However, I also feel we should -as an organization- be more pragmatic at times. It seems that the IAOC is trying to be diligent in solving a delicate situation most transparently and try to have buy in from the community. This is the type of pragmatism that is IMHO lives not to the letter but to the spirit of our documents. Therefore, without wanting to set precedent, I support this cause of action. I also offer my signature under the recall procedure, in case pragmatism doesn't prevail. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl o...@nlnetlabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands
Re: Recall petition for Mr. Marshall Eubanks
On Oct 31, 2012, at 10:21 PM, Olafur Gudmundsson o...@ogud.com wrote: Fellow IETF'rs below is a recall petition that I plan on submitting soon if there is enough support. If you agree with this petition please either comment on this posting, or send me email of support noting if you are NomCom eligible (I'm arbitrarily limiting the submitted signers of the petition to people that have demonstrated recent IETF attendance and participation) The reason I'm starting this recall petition is that I think no other way will vacate the positions that Marchall holds before the end of the year, I have purposely held of starting this process in the hope that Marshall on his own resigned but that has not happened even after he has been publicly exposed for over a week. I'm disappointed that a person that took on a responsibility that he his not able/willing to fulfill anymore, has not had the courtesy to take a few minutes to draft and send a letter of resignation or an explanation. Olafur Recall Petition Lynn St. Amour ISOC president, In accordance with the rules in RFC 3777 Section 7, I request that you start recall proceedings against Mr. Marshall Eubanks as member of the IAOC as well as IETF Trustee, due to his total disappearance from the IAOC and IETF Trust for over 3 months, and either inability or refusal to resign. Evidence to this effect was presented by Bob Hinden [1], as well as further evidence that the IETF Trust ousted Mr. Eubanks as chair of the IETF Trust[2] , due to his prolonged absence in that body as well . I as an IETF member in good standing (having attended over 50 meetings since 1987, including 9 of the last 10 meetings), regrettably request that you start the recall procedure. Below are listed statements of support for this recall petition from more than 20 other NomCom eligible IETF participants. Thanks Olafur Gudmundsson [1] https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=934k2=11277tid=1351092666 [2] https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=65510tid=1351272565 I also offer my signature under the recall procedure, in case pragmatism doesn't prevail (see my other note). My offer of signature should in no way be interpreted as reflecting an opinion about Marshall's character. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl o...@nlnetlabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands
Re: Proposed IETF 95 Date Change
On Aug 2, 2012, at 9:45 AM, IETF Administrative Director i...@ietf.org wrote: The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Support. --Olaf
Re: T-Shirt Design Contest for IETF 83 Paris
I hope a T-Shirt will feature my favorite French hero Super Dupont http://en.wikipedia.org/wiki/Superdupont --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ signature.asc Description: Message signed with OpenPGP using GPGMail ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
From Pandoc To RFC
Folk, My friend Miek Gieben just demonstrated the use of Pandoc that in combination with Make and XSLT scripting to can produce internet-drafts in XML format from plain text input. The plain text only needs a few formatting conventions, more or less like wiki markup. See: http://www.miek.nl/blog/archives/2011/09/28/pandoc_to_rfc/index.html --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ (I am posting this as an individual, specifically not with an RFC Editor hat). smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On Sep 23, 2011, at 10:04 AM, Bob Hinden wrote: I theory I can agree, but in practice I think the more separation there is the more likelihood for organizational problems. The point I am trying to make is that there needs to be close coordination between the IESG/IAB/ISOC and having a responsible person (currently the chairs, there are other possibilities as outlined in some other emails, XO model, etc.) taking voting responsibility is the best way to implement that. It won't happen if it's just another person the, for example, the IESG appoints as your proposal sugests. Likewise, I don't think having the chairs be non-voting members will work because the chairs are too busy for this to work over time. I do not yet see how the other proposal, which is about diluting responsibility over more person, will keep the persons that end up being chair better informed. But that is because I have not seen the details. Remember that my proposal started out with allowing the chairs to delegate. In a way the alternative proposals may be subject to the same critique. I am also not 100% sure that close coordination between the IESG/IAB/ISOC means that the chairs need to participate in each others meeting. It might be much more effective if they have a meeting among each other to exchange high-level information and 'heads-ups'. --Olaf (keeps listening) Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On Sep 21, 2011, at 4:27 PM, Bob Hinden wrote: It is important for the I* chairs to be connected with the community. It is important for the IAOC to be connected with the community. It is important for the I* chairs to be informed about what is happening in the IAOC It is important for the IAOC to be informed about what the I* chairs find important. Yes, but I don't understand your point. We get that today with the current makeup. Your proposal breaks these links. Oops..I did not finish the paragraph. Retry: It is important for the I* chairs to be connected with the community. It is important for the IAOC to be connected with the community. It is important for the I* chairs to be informed about what is happening in the IAOC It is important for the IAOC to be informed about what the I* chairs find important. I claim that the first two items are independent of I* chairs being voting members of the IAOC. I also claim that for the third item there is no necessity for the I* chairs to be a voting member, nor for the fourth. That said, I am sensitive to the argument that if I* chairs are members they may actually pay more attention (human nature and such) and that being effective at those item without being a member is tough. --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Thanks Bob, I appreciate your thoughts on the matter! Dear Colleagues, Based on the discussion I've updated the draft: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership Essentially I incorporated Dave Crocker's proposal to 1) replace the 'chairs' by voting members appointed by the respective bodies. 2) allow the chairs to participate in all meetings and provide (unsolicited) advice. There were many comments on your earlier draft and I don't see how these changes resolve all of issues raised. The new draft is different, but I think the main issues remain. Could you show how the issues raised are solved by the current draft? For example, there seemed to me to be a rough consensus in the discussion on the earlier draft that the IETF Chair should not be included in the proposal. Why did you not remove the IETF chair from the proposal? I did not see that rough consensus, but let us not argue that, I believe it is up for Jari to say were the consensus is. To the substance of that point: there is an argument to be made that if the IETF Chair has full voting power than the IAB chair should so to. I believe that it is beneficial for the organization if there is some symmetry there. For completeness, and in relation to that symmetry argument. Jari wrote in another mail: And if the chairs have to be voting members in IAOC, why aren't they voting members in IAB and IESG? The IETF Chair is voting (full) member of the IAB (see section 1.1 of RFC 2850) The IAB Chair is ex-officio member of the IESG (see RFC3710 section 2) but for Decision making the IAB chair is excluded from the consensus process (RFC3710 section 3.1 2nd paragraph). The obvious reason for that is that the IAB is in the appeal chain. I believe that allows chairs to exercise their responsibilities of keeping a coherent perspective of the organization an allow them to steer outcomes if needed, but doesn't require the day-to-day involvement that is required from a diligent voting member. As I said earlier, I continue to think this is a bad idea. We now have a system that works well. Certainly not perfect, but I am concerned your proposed changes will make it work worse. At some point I'd be perfectly happy to agree to disagree on the merit of the idea. But I want to understand the motivation and make sure there is nothing actionable on my side. In my time as IAOC chair, the I* chairs have been actively involved in the most significant decisions the IAOC makes, they tend to be less active in many of the day to day operational issues. For example, there are weekly calls in the months before an IETF meeting that the host, NOC team, IAD, host, and other people attend. I don't think an I* chair has been involved at this level. Also, the IAOC has several subcommittees (e.g., meetings, budget, specific RFPs, and Tools). I* chair attendance in these varies. The IETF chair is very active in the RFP subcommittee and Tools. The ISOC chair has reduced her attendance in the subcommittees. There is no requirement that members of committees are IAOC members, is there? I think the I* chairs bring a broad view of the community and operational needs based on what's involved in doing their jobs than other appointees would not have. In order for the I* chairs to be effective, they will need to be involved. If they are involved, then they might as well be voting members. With the changes you propose we could end up with an IAOC that none of the I* chairs participate. As you point out, they are all busy and will have a hard time to following the issues if their involvement is optional. This will result in an IAOC that is disconnected from the community. I do not buy that argument. If the I* chairs are vital for the connect with the community we have a different problem. It is important for the I* chairs to be connected with the community. It is important for the IAOC to be connected with the community. It is important for the I* chairs to be informed about what is happening in the IAOC It is important for the IAOC to be informed about what the I* chairs find important. I think it's very important for the I* chairs to share the responsibility for IAOC decisions by being voting members. Why? Same for the IETF Trust, your proposal would result in the I* chairs not being members of the IETF Trust (unless the Trust was changed, another issue in itself). The current structure with the I* chairs being voting members of the IAOC has worked well. The I* members are involved in the important decisions, share the responsibility for the decisions, and keep the IAOC/IASA connected to the community. I am sympathetic to the issue this draft is attempting to resolve, but I think there are better ways to reduce the load we put on the I* chairs, than what this draft proposes. It would help if you would
Re: Trust membership [Re: IAOC: delegating ex-officio responsibility]
On Sep 20, 2011, at 6:25 PM, Marshall Eubanks wrote: - Olaf's wording be changed to make the IAB Chair, IETF Chair and ISOC CEO into ex-officio and non-voting Liaisons to the IAOC and the Trust. - The TAP then be modified to recognize the status of these new ex-officio and non-voting Liaisons. These Liaisons are not IAOC members, thus not Trustees. I would not call them liaisons (as they do not liaise) but advisors. With this procedure, I see no reason to modify the Trust Agreement. The Trust would need to commit to allowing these advisors to join their meetings too. But that can be done in other ways than the Trust Agreement. (so yes, I agree with this line of thought) Obviously this all assumes there is a consensus for changing the I* chairs role --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Trust membership [Re: IAOC: delegating ex-officio responsibility]
On Sep 20, 2011, at 11:09 PM, Brian E Carpenter wrote: ...exactly. I'm far from convinced about that. I think the real need is to figure out how to make the IAOC an Oversight committee rather than it getting involved in executive decisions, and to figure out how to make the IAB an Architecture board instead of getting involved in administrative matters. On the IAB: I do not agree that the focus needs to be on the A of architecture. There is not a lot that the IAB does that is not in its charter. I believe that the focus needs to be on the B of board. In other words, just as in the IAOC more oversight. During my tenure we took a number of steps to move the handy work into programs and initiatives in which the execution of projects could take place so that the IAB members themselves could oversee but that journey was far from complete. For the IAOC and IAB these will be difficult challenges that cannot be enforced externally but also need an evolutionary culture change . Not only in the I* bodies themselves but also how the NOMCOM. --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Brian, So far you are the only person that has responded with substance. Other feedback was promised but never arrived. I hope to rev this document shortly so that we can finalize it before the Taiwan meeting. I wrote: Based on the discussion I've updated the draft: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership Essentially I incorporated Dave Crocker's proposal to 1) replace the 'chairs' by voting members appointed by the respective bodies. 2) allow the chairs to participate in all meetings and provide (unsolicited) advice. I believe that allows chairs to exercise their responsibilities of keeping a coherent perspective of the organization an allow them to steer outcomes if needed, but doesn't require the day-to-day involvement that is required from a diligent voting member. You responded: And it therefore removes the two Chairs' shared responsibility for decisions of the IAOC and the IETF Trust. I am still far from convinced that this is a good thing. That is correct, under this proposal the chairs don't have voting responsibilities in the IAOC. And while I argue that the chairs can 'steer' as ex-officio I understand that is something you are either convinced off or not. Also, the new section 2.3, which is incorrectly titled but presumably is intended to be IETF Trust membership seems to me to be inconsistent with the Trust Agreement. The Trust Agreement states that the Eligible Persons (to become Trustees) are each a then-current member of the IAOC, duly appointed and in good standing in accordance with the procedures of the IAOC established pursuant to IETF document BCP 101 [as amended]. That doesn't exclude the non-voting members of the IAOC, which is why the IAD is already a Trustee. To change this, the Trust would have to change the Trust Agreement. To be clear, I'm not saying this can't be done, but it can't be ignored either. Yes, it is incorrectly titled. As far as I understand the trust agreement the voting members and the IAD are members of the trust. If the 'chairs' are non-voting members of the IAOC then the idea is that they would not be trustees and a modification of the trust agreement is not needed. That can be clarified. If the chairs should be trustees (are you arguing that?) then I agree, a trust agreement modification is needed. --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Dear Colleagues, Based on the discussion I've updated the draft: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership Essentially I incorporated Dave Crocker's proposal to 1) replace the 'chairs' by voting members appointed by the respective bodies. 2) allow the chairs to participate in all meetings and provide (unsolicited) advice. I believe that allows chairs to exercise their responsibilities of keeping a coherent perspective of the organization an allow them to steer outcomes if needed, but doesn't require the day-to-day involvement that is required from a diligent voting member. --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
On Jul 14, 2011, at 3:24 PM, Dave CROCKER wrote: It's excellent that the issue was covered in the RFC. My question is how the contents of that RFC can be binding on random IETF participants? At the risk of answering a rhetorical question: It's being referred to in the NOTE WELL. All of the work we do in the IETF is based on the premisses that somebody who participates in the IETF is exposed to the NOTE WELL. Personally, I think people are exposed ad nauseoum, whether a court would agree, I do not know. --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 15, 2011, at 1:19 AM, Leslie Daigle wrote: Speaking as an individual, but an individual who helped set up this structure and who sat in the non-delegated ex officio IAB Chair position on the IAOC (and IETF Trust) for a couple of years, let me offer some comments. As Bob noted, elsewhere in the thread, your draft does not describe how to delegate responsibilities, it describes how to allow alternatively fill the positions. And I believe that is a fatal flaw. The discussion on this thread certainly indicates that there isn't a clear grasp of what the responsibilities are for the positions in question. The responsibilities are not: show up for meetings/telecons, offer opinions about how to administer the IETF, and put in a vote when called upon, although those certainly are the functions expected. You described the IAB Chair as hub as if that was a bad thing. Certainly not my intention to qualify it as 'bad'. The note was written from the perspective of what is the work load and what are the tasks. Not from the perspective of what are the responsibilities of the chair. In fact, the one thing the Chair (of the IAB -- but it applies in analog to the IETF) needs to do is to support the IAB's functioning (through leadership, organization, note-taking, cajoling, listening, etc). That doesn't mean the IAB Chair has to do the work of the whole IAB, but it does mean that an overall perspective is critical, and each Chair has to best organize her/himself to achieve the one task. Agreed, being informed (as 'information hub') seems to be a prerequisite for gaining that overall perspective. In setting up the IAOC as it is, the intent was to inject the IAB Chair's overall perspective into the IAOC's discussions, including the support for IAB activities. It was not a question of simply finding more credible people to put on the IAOC. If change is needed, the one path away from the fatal flaw seems to be to articulate the actual responsibilities of the IAB Chair (and IETF Chair and ISOC CEO, as appropriate) in the intended ex officio positions, such that it is possible to get agreement and external confirmation that the role is being properly fulfilled by whomever is selected to perform them. Fair enough, and in addition, as a take-away from the thread so far: those responsibilities go two ways: incoming and outgoing. It is not only the general perspective that the iChiefs bring to the IAOC but also what they take out of it. For instance; getting informed about the general state and health of things. I guess I have some homework to do because at the moment I am not able to formulate the responsibility in a way that goes beyond (for the IAB role): providing the IAB perspective into IAOC decisions; and getting informed about IAOC activities that are relevant for the IAB and the activities it oversees. - --Olaf PS: Why does the following phrase come to mind: when in a hole stop digging... Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ I will start to use a new PGP key (ID 0x3B6AAA64) at the beginning of May 2011. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: This message is locally signed. Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2oCPwACgkQtN/ca3YJIofdBgCgquirmPwR35riQZRzBvkPaoqb tGEAoPkbV6MfxzEaPcp+2/gz9sea5AVr =ncXX -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 14, 2011, at 9:17 AM, Brian E Carpenter wrote: On 2011-04-14 06:19, Bob Hinden wrote: Olaf, On Apr 2, 2011, at 1:28 AM, Olaf Kolkman wrote: [as editor:] It seems that the high order bit of this discussion circles around the question on whether it a requirement for the IETF Chair to have a voting position in order to effectively perform oversight. Once we figured out where we want to go with that we can think about delegation by the chair vs appointment by the bodies and the implementation details with respect to the trust. For the record, I don't agree with this summary. That is, I still question the basic assumption in the proposal. We have running code in the IASA model and it appears to work reasonable well. Not perfect, of course. In particular I think that having the IETF chair, IAB chair, and ISOC president as voting members of the IAOC (and IETF Trust) has worked very well. It makes them an active part of decisions the IAOC and IETF Trust are making and helps keep the IAOC from getting disconnected from the community. It also makes them share the responsibility for decisions by having their vote be publicly recorded. I agree. I think this responsibility should not be delegated. It's fundamental to the success of the IETF (and the ISOC for that matter - the IETF is a major source of ISOC's legitimacy). The IAOC delegates execution to the IAD etc. - maybe the real bug is that the IAOC itself needs to delegate more? I agree the IASA model is working well and I also agree that the chairs have played an important role. But I am not convinced that it is the only way to keep the IAOC from getting disconnected from the community. To turn that argument around: If it is the case that we need the IAB chair, IETF chair and ISOC president [iChiefs] to keep the IAOC on track then why do we have NOMCOM appointments? One could easily argue that the NOMCOM appointments are made to keep the IAOC connected to the community. I also do not see why it 'it's fundamental to the success of the IETF'. I do agree that the iChiefs need to understand what is going on, there is no dispute about, but I question whether IAOC membership is best and most efficient instrument. I also don't understand what the effect of the proposal is on the IETF Trust. Currently all IAOC members are members of the IETF Trust. They have to sign a letter accepting this role. I don't think it can then be delegated. It can't be delegated. However, a duly approved update to BCP101 can change the definition of the formal membership of the IAOC, and that would automatically change the membership of the Trust. An alternative would be a formal change to the Trust Agreement, but since IANAL, I don't know whether a change to allow delegation or proxies would be possible under the law of the Commonwealth of Virginia, where the Trust was established. I do not want to brush over this important detail. But, let us first figure out what we want with the IAOC. If there is no consensus on having the iChiefs play a less involved role then fine tuning the details doesn't make sense. If we gain consensus then fixing the Trust is doable. Your draft focuses on one area (that is, reducing the burden of these positions), but does not discuss any other aspects of making this change. What might the negative aspects of delegating this responsibility be? How will this be dealt with? Help me out. The main _potential_ negative aspect is a drop of iChiefs' awareness of what is going on; and the ability to directly influence decisions. Each of the positions (IETF Chair, IAB chair, ISOC President) are different in the way they are selected and this effects their ability to delegate their responsibility and who they might delegate it to. For example, the IETF chair is selected by the NOMCOM and one of his/her responsibilities is to sit on the IAB, IAOC, and IETF Trust. The IAB chair is selected by the IAB. The ISOC president is hired by the ISOC Board of Trustees. Consequently, I think the authority to delegate differs and they should be considered separately. I agree, this needs discussion. But lets first see if there is any consensus on going down the path of getting the iChiefs out day-to-day IAOC business. [as olaf:] I agree that the IETF chair needs to have a good oversight about what goes on in the IETF, to a lesser extend it is good that the IAB has that oversight too (specifically with respect to its chartered responsibilities) but I wonder if a voting membership is the appropriate instrument. Why not? It does appear to work. Yes it works. But it consumes a lot of time too. IAOC retreat, meetings at the IETF, regular tele-chats, participation in sub committees, etc, etc... We have a responsibility to our leadership to make their jobs scalable and manageable. We need to have our
Re: IAOC: delegating ex-officio responsibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Certainly the IASA/IAD/IAOC reorganisation produced a noticeable reduction in the IETF Chair workload, but what has changed since http://tools.ietf.org/html/draft-carpenter-ietf-chair-tasks-00 ? It would be good to have a similar analysis for the IAB chair role. Below is a copy from a note I mailed to the IAB dd Feb 17, 2011. It wis a variation on a note that I mailed to the Nomcom in 2009. It may not map exactly to what you are asking, but I believe it is close enough. Also, my wish to remove the _must_ in the 'iChiefs must be a member of the IAOC' best current practice is not a cherry picking act. The IAB has hired secretarial assistance for the agenda keeping, todo-list maintenance, minutes, etc. It is pushing forward the 'programs and initiatives' model that allows for subgroups to do a lot of actual work without the chair driving that (i.e. much more formal delegation of activities to sub-groups with possibly external members). Starting off with a personal note. As you know the IAB chair is selected by and from the IAB membership on a yearly basis. I first volunteered for the role of chair in March 2007. When I volunteered the first time I committed myself for 3 to 5 years (obviously subject to Nomcom and IAB decision). A minimum of 3 years because anything shorter is almost not worth the investment in the learning curve and the personal network that is needed to do the job effectively. Not longer than 5 years because of the fact that(much) longer terms tend to result in strong identification of a person with the role, sharpness and creativity decline, and possibly forms of mannerism in dealing with issues. From my perspective the most ideal scenario was (remember I wrote this in 2009) that I'd be allowed by the Nomcom and the IAB to serve as a chair for one more year and then be around for another to allow for continuity. In any case I think that it would be good for the Nomcom to look out for 'chair material'. The main reason why I want to step down now is that there have been some developments in the NLnet Labs situation that need my attention as director of that organization that can not be combined with a 0.7 FTE that I seem to be putting in at the moment. As for the responsibilities of the chair. ∙ A number of 'mechanical/managerial' tasks: ∙ Managing and organizing the IAB work-flow both on architectural and organizational items ∙ Setting priorities, planning activities to be aligned, identify actionable items and make sure next steps are taken ∙ Set up various meetings, manage agendas ∙ Track minutes creation and publication ∙ A chair's job can be relieved by having an executive director that complements a chairs talents in organizing these activities. ∙ Drive discussions ∙ defining goals ∙ moderate discussions ∙ call consensus ∙ Identify work items ∙ Incoming appeals ∙ Specific questions to the IAB from external bodies ∙ Track (or make sure they are tracked) various developments that may have impact on the IETF. ∙ IASA/IAOC and Trust ∙ As ex-officio membership, to represent IAB (and IRTF) matters Because the chair is involved in all these activities (s)he becomes a de-facto information hub, besides because the chair often act as spokes person there isa tendency for all major organizational work items to gravitate towards the chair, specifically if the interests of the other members are mostly architectural. There are arguments that the load on the IAB chair is to high and it causes the job to be more than a half-time position (depending on personal effectively, delegation skill, organizational skills and the quality of an executive director[*], it may even be closer to 3 quarters). And I believe that there are some structural questions one can ask, such as in the ex-officio membership of the IASA/IOAC. If we manage to get the Programs ran as more or less autonomous motors that produce recommendations to the IAB it may be that the chairs job becomes relatively bearable. While I think that with the Programs we have put a good structure in place it will need serious efforts of the next chair and the NEW IAB to make working with programs part of the common mindset. I think, and I realize that I am biased, that an IAB chair has some of the following skills, properties: ∙ Organizational: tracking actions, poking people, planning the work load. A good Executive Director can be of tremendous help ∙ Moderating and motivating: The ability to herd cats where occasionally a cat will have its claws out. ∙ Diplomatic: In inter-organizational contacts taking the diplomatic way to where you would like to end up. ∙ Strategic:
Re: IAOC: delegating ex-officio responsibility
[as editor:] It seems that the high order bit of this discussion circles around the question on whether it a requirement for the IETF Chair to have a voting position in order to effectively perform oversight. Once we figured out where we want to go with that we can think about delegation by the chair vs appointment by the bodies and the implementation details with respect to the trust. [as olaf:] I agree that the IETF chair needs to have a good oversight about what goes on in the IETF, to a lesser extend it is good that the IAB has that oversight too (specifically with respect to its chartered responsibilities) but I wonder if a voting membership is the appropriate instrument. I believe effective oversight depends on having the appropriate high level information and having the opportunity to timely inject information that is needed to steer an outcome. An alternative method for sharing and injecting is having regular meetings between the I* chairs and the ISOC President/CEO. I believe that such meetings are much more effective for the parties involved than being exposed to all details. This only an illustration of an instrument, there may be other instruments for oversight as well. But I do not think the ex-officio membership is the only method. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IAOC: delegating ex-officio responsibility
Dear Colleagues, I have just chartered a very short draft that intends to update BCP101. It can be found at: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership The draft is very short and contains only a few sentences of substance: The IETF chair, the IAB chair, and the ISOC President/CEO may delegate their responsibilities to other persons. The delegations by the IETF chair and the IAB chair need to be confirmed by the IESG and IAB respectively. The terms of delegation is for a longer term for instance aligned with the IESG and IAB appointment cycles (roughly anual). John Klensin made me aware he also had a similar idea earlier: http://tools.ietf.org/id/draft-klensin-iaoc-member-00.txt The main difference is between his and this draft is that John's I-D makes the person the chair delegates to a non-voting liaison. I have a small preference for the IAB and the IESG keeping the control point, and I implicitly assume that for IASA matters the persons delegated to will escalate to the chairs and ask for specific guidance when appropriate. I realize that for the Trust anybody serves on personal title. For the trust alignment with the IAOC membership is just a practical considerations. The shared requirement is unloading the I* chairs and the ISOC president and empowering the people that serve in that role to organize themselves. (I should have paid more attention to this much earlier.) I plan to seek a sponsoring AD for getting this I-D published as a BCP shortly. Assuming this is an appropriate list for further discussion, yours, --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Op 30 mrt. 2011 om 13:35 heeft Bert (IETF) Wijnen berti...@bwijnen.net het volgende geschreven: On 3/30/11 1:21 PM, Olaf Kolkman wrote: Dear Colleagues, I have just chartered a very short draft that intends to update BCP101. It can be found at: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership The draft is very short and contains only a few sentences of substance: The IETF chair, the IAB chair, and the ISOC President/CEO may delegate their responsibilities to other persons. The delegations by the IETF chair and the IAB chair need to be confirmed by the IESG and IAB respectively. The terms of delegation is for a longer term for instance aligned with the IESG and IAB appointment cycles (roughly anual). It reads as a generic may delegate their responsibilities. So taking that paragraph out of context may confuse people. Why not make it explicit: The IETF chair, the IAB chair, and the ISOC President/CEO may delegate their IAOC and/or IETF Trust responsibilities to other persons. ... ACK --Olaf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On Mar 30, 2011, at 5:42 PM, SM wrote: Hi Olaf, At 04:21 30-03-2011, Olaf Kolkman wrote: I have just chartered a very short draft that intends to update BCP101. It can be found at: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership In Section 2: The terms of delegation is for a longer term for instance aligned with the IESG and IAB appointment cycles (roughly anual). I suggest dropping that sentence as it is already mentioned that the chairs are delegating their responsibilities. Else, you could use: The delegation is for a term no longer than that of the ex officio member. The point of this paragraph is that, when a new chair joins the chair and get a feel for what is going on and therefore may wait a while until the responsibility is delegated, so it may not be aligned appointment cycle. Also you would want some continuity, hence a long term. Trying to rephrase: For continuity purposes the terms of delegation should be for a longer period, roughly annual. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 83 Venue
[More NOISE, skip reading if you want SIGNAL] On Jan 24, 2011, at 5:36 AM, Christian Huitema wrote: Wasn't the official definition of the meter also tied to Paris? The invention of the meter is indeed tied to Paris. The value of the meter itself is not. The meter was defined by scientists commissioned by the French revolutionary assembly, but it is not exactly tied to Paris. The original definition was 1/10,000,000 of a quarter of the Earth circumference, and the commission of scientists established the value by measuring an arc of the earth circumference between North of France and North of Spain. The unit was then materialized by a big platinum ruler kept in a locker in Paris. It is now defined in relation to the speed of light, itself set as 299,792,458 meters per second. Reminds me of an excellent story where Superdupont saved the world from misery when a bunch of International Terrorists (with British and German accents) saved replaced the standard meter by a non-standard. http://en.wikipedia.org/wiki/Superdupont Since we are exchanging pedantic wise cracks. Instead of Platinum, we now find Cesium to be at the hearth of the measurement of a meter: 299,792,458 meters per 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium 133 atom. Earlier PhB wrote: The idea that there is utility in leap seconds is ridiculous. Most astronomers I have talked to tell me that UTC is useless for their purposes anyway and the time of mid-day varies at Greenwich by 5 minutes over the course of a year so what does it matter which two days are right? Julian Date is the date mostly used in observation records etc. (at least when I did my observing runs as a graduate student). The convenience of the Julian date is that you just keep counting, the Unix time guys did the same, except that there NULL epoch was in 1970 instead of 4713 BC and the unit of counting is seconds instead of days (roughly). PhB also said: What else is there to discuss in Paris? I vividly remember http://www.ietf.org/mail-archive/web/ietf/current/msg36670.html so those discussion may eventually contribute to more noise on the IETF list. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SDO vs academic conference, was poster sessions
On Jan 14, 2011, at 9:23 AM, Alessandro Vesely wrote: On 11/Jan/11 20:32, John C Klensin wrote: --On Tuesday, January 11, 2011 10:35 -0800 Randy Presuhn randy_pres...@mindspring.com wrote: At issue though is that these individuals get paid (sponsored) by someone, either directly or indirectly by corporations and/or governments. Not necessarily. Some of us have no employer and just do this stuff for the fun of it. Indeed. Although I'm increasingly taking exception to the fun part. If you remove fun, what else remains that can be used as a compass to take a bearing in iffy circumstances? For some of us: A feeling of responsibility in shaping the future of the Internet that is beyond direct corporate interest and next year's line items. --Olaf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
I see an opportunity for the IETF Store[*] A T-shirt with a blank space in which you can write your draft name... See http://www.secret-wg.org/Poster-Session.png for the artist impression of the random IETF participant wearing such shirt. --Olaf [*] http://www.cafepress.co.uk/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Tonight's Plenary: RFCs Will No Longer Be Published
On Nov 8, 2010, at 9:14 AM, Dave CROCKER wrote: The price of freedom is eternal vigilance. -- Thomas Jefferson It is also the price for maintaining quality and culture. -- D. Crocker One of the problems with having things work well is that we get complacent. Once we get through the challenges of gaining approval for a document, today we find that going the the RFC publication is usually efficient and even painless. This has not always been so and it could become 'not so' in the future. Tonight's plenary will not include the above-offered announcement, but it /will/ include a proposal on the RFC Editor office, covering the structure and functions, with a focus on the open position for the RFC Series Editor -- roughly equivalent to the position previously held by Bob Braden and created by Jon Postel. As always, if you ignore the current round of proposal review, you do not get to later complain that the result is wrong. Worse, if you do not participate now, you are probably increasing the likelihood that it will be wrong... Some additional information: During this evening we have put this discussion at the end of the agenda, after the IAB open microphone session. WRT timing: We have approximately 30 minutes allocated for about 10 mins of introduction and 20 mins of discussions. While I do not want to be strict with respect to the end time I do want to respect that people need food and want to try to close microphone lines at 19:30. Until now I have not seen any questions for the IAB open microphone session. I suspect that the open microphone doesn't need the allocated 30 mins so we may gain some time at the start. Also see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg08097.html http://www.rfc-editor.org/pipermail/rfc-interest/2010-November/001827.html http://www.rfc-editor.org/rse/RSE.html for some background and references. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
On Oct 20, 2010, at 10:47 PM, Richard Shockey wrote: I personally find section 5.1 unusually amusing as if now the IAB wants to say split-DNS should be considered harmful. Leakage in to the public DNS .. geez really. Like what where are the examples of the harm? So who put ringtones in the DNS :-) I am trying to understand where there are misunderstandings and differences in insight. And I think you might have read 5.1 different than intended: It is not trying to speak about data that is leaked from internal to public DNS installs. But it tries to make a more generic point that solutions that are engineered for environments that are supposed to be closed will leak to the public Internet. With that comes a responsibility to design those solutions and protocols in such a way that they will have the appropriate security, privacy, and scalability properties. ? --Olaf (speaking for myself) Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Posting Placement (was Re: Fisking vs Top-Posting)
In the context of a long thread about style and readability[*] Joel M. Halpern summarized: I do want to re-iterate two points I have seen that are important. Both are relevant no matter what style of posting you like. 1) People need to read the whole email before composing their response. (You can draft ideas while reading, but make sure you actually read the whole thing before you finalise your response.) 2) People need to edit longer threads so that they do not copy large amounts of redundant and useless text. I would think that there is a 3rd point: 3) Think about what you would want to communicate, who to communicate to, and what style fits best. Fisking, classical Oxbridge rhetoric, top-posting, satire, acronyms (WFM, or 1+), one-liners, essays, YELLING, not-replying-at-all, c, c all seem to have their own effectivity and charm. In that contest I observe that by looking at the From: header you can often predict the style that is used while in an ideal world you would like to see correlation with the Subject: header. --Olaf [*] See for the whole thread: https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=53746tid=1285574931 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pigeon flies past broadband in data speed race
On Sep 16, 2010, at 11:56 PM, Jorge Amodio wrote: sh don't say it out loud, the IGF may try to regulate the reproduction of pigeons ... BTW did each of the pigeons had a different class of service ? We need Reminds me of an implementation report of RFC1149 Firewalling way back at IETF 55 (see http://bert.secret-wg.org/Trips/IETF55/ middle of the page) --Olaf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The Evils of Informational RFC's
On Sep 8, 2010, at 11:17 PM, Bob Hinden wrote: Eric, On Sep 8, 2010, at 1:05 PM, Eric Burger wrote: I would offer RFC 5211 is PRECISELY the kind of RFC the IETF should NOT be publishing! I can see the press release now: IETF publishes IPv6 transition plan. NO ONE OUTSIDE THE IETF has a clue the RFC Editor is NOT the IETF. RFC = IETF is the *reality*, no matter how much we say it is not. The IETF did not publish it, the RFC-Editor published it. For that matter, would the world notice if the press release made the accurate statement, The RFC Editor, who publishes all IETF protocols, publishes IPv6 transition plan? What rational person would not make the leap that the IETF published the document? Anyone who actually read the document. If we are going to worry about what people think who don't read our documents, we should stop now. Also see RFC 5741 work on which was inspired on exactly this sort of discussion. Quoting from that: For non-IETF stream documents, a reference to Section 2 of this RFC is added with the following sentence: Documents approved for publication by the [stream approver -- currently, one of: IAB, IRSG, or RFC Editor] are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. For IETF stream documents, a similar reference is added for BCP and Standards Track documents: Further information on [BCPs or Internet Standards] is available in Section 2 of RFC 5741 . --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Optimizing for what? Was Re: IETF Attendance by continent
The recent remark on bias against individuals[*] made me think about weighing the location preference by number of participants from certain regions. Suppose an individual from Asia attends all IETFs then her costs are that for attending 6 IETFs she gets to travel 1x regional and 5x interregional. While an individual from the US travels 3x regional and 3x interregional. Clearly there is a bias agains our Asian colleague in with respect of the costs. Using participation/contribution numbers to weigh locations minimizes the global costs (total amount of miles flown, carbon spend, lost hours by the collective, total amount of whining) but nothing of that flows back to the individual engineer that attends every time. If you want to be fair to the individual participants you have to optimize in such a way that attending 6 meetings costs the same for every individual that regularly attends the IETF. Obviously one can only approximate that by putting fairly large error bars on the costs but isn't the X-Y-Z distribution where X= approx Y= approx Z the closest optimum? (or finding one place that sucks equally for everybody) Am I missing something? --Olaf (strictly personal) [*] Independent consultants, somebody not financially backed up by big corporations. Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
On Aug 6, 2010, at 10:44 PM, Bob Hinden wrote: During my IAOC chair plenary talk at IETF78 (slides are in the proceedings) I asked a question about continuing the current meeting policy (3 in North America, 2 in Europe, 1 in Asia in two year period (3-2-1) ) or changing to a 1-1-1 policy based on current meeting attendance. The talk included a graph of attendance by continent for IETF72-IETF78. I was asked to provide this data to the community. It is attached. It includes the raw data and a new graph that shows attendance by percentage. It appears to me that a 1-1-1 meeting policy is justified by current overall IETF meeting attendance. Your comments are appreciated. I read the thread and I am happy we are not basing our decision based on the geographical spread of the persons who participated in this discussion. :- As a rhetoric question: The IAOC will not be the judge of the consensus on this topic, will it? We leave that to the general AD? Personally I believe that the aspect of going where our contributors come from should be weighed most heavily and I agree with Jari that there are different statistics that should be taken into account (like draft authorship). However, I also believe that the outreach component is an important one to the viability/goodwill of/towards the organization. Whatever the numbers X-Y-Z turn out to be (and I would consent with 1-1-1 and 2-1-1) I am in favor of moving towards the X-Y-Z-* model that Peter and Frederico alluded to. --Olaf --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [78attendees] WARNING !!! Re: Maastricht to Brussels-Nat-Aero, Sat 07:09
On Aug 26, 2010, at 3:07 AM, JORDI PALET MARTINEZ wrote: Hi, I'm forwarding this message to the general IETF mailing list, because I think we need a good discussion on this and the confirmation from the secretariat/IAOC that this work will be done CORRECTLY NEXT TIME. The fact is that if we don't make sure that a venue has good connections then should not be candidate to be an IETF venue. I'm not referring to plane vs train. I'm fine with train if the information provided is accurate. Some times, for people in Europe, train can be more convenient than planes, but this is only true if the train system is reliable in general (of course, a strike, crash or anything like that is something that we can't predict/avoid). Maastricht proved that the information provided by the train web sites was totally FALSE. This is something that the secretariat/IAOC SHOULD verify before accepting a venue. I hope that we learn the lesson. Jordi, You are suggesting that the secretariat or the IAOC does research into the correctness of information that is linked from the host site, correct? If so: The host site is _not_ the responsibility of the IAOC or the secretariat, it is the responsibility of the host. And although I would agree that there should be some expectation that the host does its best to provide accurate venue information one cannot expect the host to actually _test_ whether sites that (in their eyes) are supposed to give authoritative information are actually correct. Suppose that this link was not provided by the host. You would probably have googled for Maastricht Brussels Train? That query provides me with the mentioned site as first hit. Would you have complained to google that the first hit for that query contained false information? But to the underlying point: I think the responsibility of the IAOC and secretariat stops with providing accurate hotel and venue location information. How to get from home to the venue is _your own_ responsibility by which you might be aided through links provided by the hosts and hints and tips from your colleagues on the various IETF lists. I would agree that it is fair to expect that folk providing those hints and tips do so diligently but that is not the responsibility of the IAOC or Secretariat. On purely personal title, --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Tourist or business visa from US?
On Aug 24, 2010, at 10:49 PM, Melinda Shore wrote: On Aug 24, 2010, at 12:44 PM, Behcet Sarikaya wrote: Many countries we go to attend IETF meetings would probably require business visa but we go there as tourists on a visa waiver program. I don't quite understand this discussion. Why not ask the host what they recommend? Since one is responsible for ones own travel, I suggest you (always) ask a specialist yourself, like the local consulate or a visa service bureau. FWIW, if you are in the NL: I've been using http://www.visum.nl/ a number of times. In some cases these visa buros can arrange a letter of invitation for you. This buro does that for trips to Russia. Also FWIF, I just called the that visa buro about China and they actually recommended to ask for a tourist visa which will result in a 'general' visum that can be used for business too. Or, as second alternative apply for both tourist and business, which will result in a general visa too. I will probably take the approach of handing them all the paperwork, including the LOI and let them make sure I get the right visa. Again, don't take my word, or anybody else's, do your own research. --Olaf PS I always thought of Visa being plural of Visum, but that is rejected by my spell checker. Is there a singular version of the word in English? Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pointing to IANA registries
[Replying to Mark, only because he inspired to make the remark] On Apr 19, 2010, at 5:21 AM, Mark Nottingham wrote: Couldn't IANA just implement the search format as http://www.iana.org/assignments/Registry-Name and cut out the middle man? Regarding the 20 year argument, it seems to imply that one of the following will happen in that time scale: 1) HTTP will be replaced by another protocol in a non-backwards-compatible fashion, and support in software is dropped (i.e., obviating all existing HTTP URLs), or 2) URIs themselves will be replaced in a non-backwards-compatible way, and URI-handling software disappears (obviating all URIs, period), or 3) The domain name system crashes and burns irrevocably, or 4) IANA loses legal control of iana.org, or 5) IANA lacks the organisational ability to guarantee stable identifiers for its products, or 6) No Web serving software is available that gives IANA the ability to control their own URI path components, and it is illegal for them to write it themselves. If #1 or #2 happens (unlikely), we will have enough warning to revise the RFCs as appropriate, or provide a mapping to the new way of doing things. Not fun, but a reasonably calculated risk, given the shelf life of most IETF products. If #3 - #6 happens (likelihood is reader-deterimined), we've got far worse problems than some RFCs whose registries can't be easily found -- A STATE THAT I WOULD MENTION WE ARE ALREADY IN TODAY. Slightly orthogonal to how one approaches long-term stability of references in RFCs there is the issue of the needs of the IETF. It is not completely hypothetical that in a far, far future there will other or even multiple 'vendors' that offer the service[*]. It that context stability is important too. See http://tools.ietf.org/html/draft-iab-iana The IAB is close to finalizing that document. --Olaf [*] In fact there are two organizations today, see Appendix A of draft-iab-iana Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Appeal Support ... was Re: Appeal to the IESG concerning the approbation of the IDNA2008 document set.
Folks, I am increasingly concerned about efficiency in the IETF, given the loads everyone is carrying. One source of inefficiency is having someone create work for others, without having already done enough of their own work. [...] A few years ago I proposed http://tools.ietf.org/id/draft-kolkman-appeal-support Abstract RFC 2026 outlines the procedure for appealing decisions or process failures to the IESG and the IAB. This document describes how an appellant should first gain support for filing their appeal before an appeal is being considered. I just went back to thread starting at http://www.ietf.org/mail-archive/web/ietf/current/msg43976.html to convince me that dropping the document at that time was done based on lack of support. It seems to me that at the time there were to many difficult and contentious details that it was not really worth the effort to prioritize on that document. While the gist of the discussion went in the direction to suggest the IAB and IESG that appeals could be returned with a stamp no merit. Ted's mail triggered the thought that appeal support could also go another way. If there are people who think that an appeal is important they can help the appellant to create a concise and direct appeal. -- Olaf (no hats) PS Note the subject change. I am not talking about a (this) specific appeal. Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Glenn Kowack appointed as Transitional RFC Series Editor
On Feb 26, 2010, at 3:25 PM, IAB Chair wrote: The IAB also acknowledges the support of the volunteers that served on the the Ad-hoc Advisory Committee (ACEF) and assisted the IAB in their selection. They are: Joel Halpern (who took the responsibility for coordinating), Bob Hinden, Joe Touch, and Jim Schaad, Craig Partridge (who left the committee in October 2009) and Scott Bradner (who recused in December 2009). They worked with IAB members John Klensin, Russ Housley, and me. I am a bit embarrassed to confess that I made a mistake in the above acknowledgments: Joe Touch was never on the committee, Bruce Davies was. --Olaf ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
On Jan 4, 2010, at 3:08 PM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Nameservers for IPv4 and IPv6 Reverse Zones ' draft-jabley-reverse-servers-01.txt as a Proposed Standard Colleagues, Ron, In the context of Joe Abley's reverse servers draft (draft-jabley-reverse-servers) there has been some discussion about the need for a standards track document for the delegation. I was the IAB member that suggested Joe to follow standards track on the basis of my strict reading of RFC3172 section 3. I did so after considering whether an IAB stream document for this was sufficient. Unfortunately, when the appropriateness of the IAB statement (section 4) in Abley's draft was brought to the IAB list, the reference to the trade-off between STD-track and IAB stream was overlooked and not discussed timely. After having seen the discussion on the list I believe that RFC3172 (2.1) is clear about the use of zones under .arpa within the context of protocol parameters (in-addr.arpa, urn.arpa, etc e164.arpa). The implementation thereof is described in section 3 of the document. However in this case the argument has been made that the creation of a subdomain is done for purely operational purposes. In the case of purely operational matters, such as redelegation of nameservers for specific domains, or DNSSEC signing of .ARPA, the IAB instructs or approves modifications in the .ARPA zone that need to be implemented by IANA. This document is closer to describing an operational matter than a protocol matter and could have been treated differently -- as an IAB-stream informational RFC-- obviously after a Call for Comments. The current review is useful for transparency: having to explain clearly the 'why and how' is beneficial to everyone. The point I am trying to make is one of setting precedent: A future IAB may make a different tradeoff between IETF Standards Track versus IAB-stream publication. In this case the coin dropped in the direction of Standards Track review. Having made that point I want to share the observation that the document has no protocol elements as such. Publication as BCP instead of Standards Track would therefore be better. Another decision the IESG could make based on the last call comments is to hand the document back to the IAB for publication on the IAB stream. As far as timely publication of the material is concerned either path would do. I do not think the IESG would need more time if the document would be BCP instead of Standards track, nor would the IAB need a call for comments, as the discussion on this list has been thorough. To be clear, we are where we are, and I personally do not think that any of these consideration should delay publication: the decision is currently with Ron. --Olaf as IAB chair. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
On Dec 22, 2009, at 8:39 PM, Dave CROCKER wrote: Brian, This seems worth being a bit pedantic about, to make sure we all share the same understanding: I take your interpretation to mean that the RFC Editor can, on their own initiative, fix the problem(s) that Julan has raised and that it does not require changes to the about-to-be-published document. Is that correct? Do others agree? (I hope so.) FWIW, I do. As long as those changes are stylistic, editorial, and not so substantive that they cause the various streams to be uneasy with those changes. And in reply to Brian: Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate, exactly as for the Trust-maintained boilerplate. That is what I intended with: I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input --Olaf (personal title) d/ On 12/22/2009 11:23 AM, Brian E Carpenter wrote: FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. ... For now, there are indeed weasel words such as: However, this is not intended to specify a single, static format. Details of formatting are decided by the RFC Editor. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. I think this gives the RSE, in conjunction with the tools maintainers, reasonable flexibility. -- Dave Crocker Brandenburg InternetWorking bbiw.net Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Julian, You wrote: This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? We are at a point where making trivial changes to headers and boilerplates leads to discussion about more substantive matters and causes even more delay, folk wanted it done. It is unfortunate that the stutter (I agree its there and that its ugly) remains in the document. Headers and boilerplates lives on this tangent between community wishes, RFC oversight, and RFC Editor series continuity and style. Having learned from getting HB done, I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input. FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. --Olaf [top-post, full context below.] On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote: Julian Reschke wrote: ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see http://tools.ietf.org/html/draft-reschke-hab-01, in particular http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt (diffs). ... I just heard that the RFC 5741-to-be is not going to be fixed with respect to the stutter in the boilerplate, such as in: -- snip -- 3.1.6.2. Text of 'Status Of This Memo' This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc. -- snip -- (see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2). This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? Best regards, Julian ___ rfc-interest mailing list rfc-inter...@rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
During previous technical sessions I mailed an announcement about the technical plenary and in those announcements I've asked something along the lines of: If you consider asking a question during the open-microphone session it would be helpful to send that question to the IABi...@iab.org in advance. In that way we may be able to think about the problem and answer your question effectively. Note that sending in a question is _not_ a requirement for asking one. I believe that submitting questions in advance will help to get concise questions asked (because some thought went into phrasing them) and get pointed answers (because some thought went into answering them). In fact the questions may be shared by the larger group and not just the individual opinions of the folk that are happen to be on stage. FWIW, in the sessions I had asked this questions nobody walked up during the microphone. I just forgot to add the paragraph in this weeks announcement. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] [rfc-i] path forward with RFC 3932bis
On Sep 21, 2009, at 7:29 PM, Jim Schaad wrote: Ok - the problem I have, and the reason that I asked, is that it is not clear to me that the Independent Series Editor (ISE) is part of the RFC Editor any more than the ISRG is going to be. Thus it is the ISE not the RFC Editor that will be asking for the IESG to review documents in the future. The first level of negotiations would be between the ISE and the ISEG, the second level would add the RSE and the final level would be the IAB. RFC Editor includes the ISE (the model defined the ISE as one of the components of the RFC Editor) RFC5620: Note that RFC 4844 uses the term RFC Editor function or RFC Editor as the collective set of responsibilities for which this memo provides a model for internal organization. This memo introduces the term RFC Series Editor or Series Editor for one of the organizational components. This change from the RFC Editor processing independent submissions to an ISE doing the same thing - with an additional layer of possible internal review from the RSE - is not reflected in the document. Correct. Personally I don't think that is a big issue. If the RFC series allowed footnotes I would add a footnote about how it would work out with the ISE and RSE in version 1 of the RFC Editor model --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Sep 20, 2009, at 7:18 PM, Michael StJohns wrote: Some 15 years ago, the IETF had a plenary session on the NSA's CLIPPER chip initiative. That was a hot topic of the time and was a great example of open discussion. That discussion could not be had at an IETF in the PRC. We've had various discussions on P2P systems and their ability to evade government restrictions. That discussion could not be had at an IETF in the PRC. We've had discussions on E164 and whether or not the owner of E164.ARPA could allocate a country code for Taiwan. That discussion could not be had at an IETF in the PRC. Mike, Do you have evidence that those items could not be discussed or do you suspect that those items could not have been discussed? --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote: Tim, I definitely agree with you that it should be the IETF community that is last called. Normally, the IESG judges IETF consensus. However, if it makes the IAB more comfortable for the IAB chair to do the consensus call, that's fine with me. If we do that we'd need to make it clear how this interacts with the IETF appeals process. Sam, the underlying point of my question is that the streams are independent and that the IETF (stream) has no say about the other streams. IETF consensus or not. I am not even sure the IAB has a roll in calling the consensus. But there is a nugget in the introduction of a last call: I think that the ISE has a very hard time explaining to the RSE that a note that has backing of IESG consensus will not be published. (I am assuming the use of the appeal procedure as described in RFC5620, which I think is appropriate for a difference of opinion between RFC entities such as the ISE and the IESG). If in such conflict the RSE would choose sides of the ISE then I am pretty sure something is severely broken and the appearance of a note is the least of our problems. So in other words what I am saying is don't invent process but follow existing pieces: - put a note in front of the ISE o if the ISE pushes back - last call the note in the IETF, to make sure the IESG actually represents IETF consensus --whereby the consensus is called by the IESG following normal process and appeal--, and go back to the ISE telling that the note has IETF backing. o if the ISE pushes back - consider this a disagreement between stream entities and follow RFC 5620 appeal process. o if the RSE chooses sides with the ISE the note gets published but the IAB, the IESG, and the RSE have some serious talking to do because something is severely broken elsewhere than just the note. The RFC will most probably be published without the note but the IESG has the possibility to publish a This RFC sucks for this reason RFC while the real problems are being addressed Obviously publication of the document should be delayed on request from the IESG while the above is sorted out in a timely manner. -- Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
On Sep 8, 2009, at 2:06 PM, Simon Josefsson wrote: I'm strongly concerned that this puts the decision making of what is and what is not a problem into the Trust's hands. No, there is always step 5: review of the new text or decision not to change the text. If a suggestion isn't considered a good idea by the Trust, the reasons for not changing it can be discussed in this step. Step 4 puts a veto for changes into the Trust's hands. Members on the Trust can be removed by the IETF, but I don't believe that is a good way to make the Trust to do something the IETF requests. As a Trustee I've signed a statement that reads: 3. The undersigned hereby agrees to serve as a Trustee to the Trust and to fulfill the duties of a Trustee in accordance with the terms of the Trust Agreement and all other requirements of law applicable to service as a trustee of a Virginia trust and to comply with all requirements of the Trust Agreement applicable to his/her service as a Trustee If a proposal from the IETF is in conflict with the terms of the Trust Agreement or the law then a Trustee has the obligation to veto it (a fairly academic possibility, I believe). However, if such happens I think that the Trust has the obligation (MUST) to explain the motivations in quite some detail, and explain why they did not catch the problem earlier in the process. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Sep 8, 2009, at 4:13 PM, Polk, William T. wrote: I believe Sam's suggestion offers a good compromise position: if the IESG and RFC Editor do not come to an agreement, we should last call the proposed IESG Note and let the community determine whether (1) this is an exceptional case meriting a note and (2) if the text accurately clarifies the relationship. Which community, The IETF community or the wider RFC community? And who calls the consensus? --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Sep 2, 2009, at 7:20 PM, John C Klensin wrote: We simply require that, if the ISE receives input from the IESG requesting specific changes to a document (specific changes including, but not limited to, so-called IESG Notes) and the ISE and authors decide to not incorporate those proposed changes, the ISE is required to explain to the IESG, in writing, why not and allow a reasonable period of time for the IESG to respond. If it felt it were necessary, the IESG could then open a further discussion, ask the RSE to mediate, or launch a formal request for IAB review. Consistent with other provisions in RFC 4846, either the IESG or the ISE could, at their discretion, make the correspondence (the request and response) public. I think it is more than reasonable to expect documented communication if a request from the IESG is not honored by the ISE. I also think it is reasonable to expect such decision to be appealable/reviewable and that all the communication is timely. So yes, I support this, in fact I take this for granted. I believe that difference of technical opinion follows RFC 4846 sect 5 (which is about publishing or not publishing). The denial of a note from the IESG is a dispute between streams that follows RFC 5620 4.2.1. I can see that there could be some argument about which procedure to follow but in the end the RFC Editor (the RSE in this case) will make the final decisions based on various recommendations (that is how both 4846 and 5820 are written). --Olaf (no hats) --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Aug 31, 2009, at 3:29 PM, Jari Arkko wrote: And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. I am happy to see the document being reverted so that an IESG note is exceptional. Over the last years I've started to appreciate the fact that the RFC Series is not exclusively an IETF series. On the other hand I am sensitive to the argument that most consumers of RFCs do not see the fine distinction between standards track and non-standards track RFCs, let alone the difference between non-standards track from various streams. Headers and Boilerplates tried to address that and hopefully helps to clarify the fact that not every RFC is an IETF Standards Track document. However, the whole RFC streams framework has been build with complete independence of the various stream in mind. In my opinion that makes sense. The IAB should not be able to force notes on IETF stream documents, the IRTF should not be able to put them on IAB stream documents, and the IESG should not be able to force them on IRTF, IAB and Independent documents. In other words it is not clear to me why the combination IESG and the Independent stream should have a special status. And, as other mentioned, deciding about that special status is not a matter that rests solely with the IESG/IETF stream. I do think that in essence this is a fairly theoretical discussion. I believe that in general notes from the IESG will have merit and recommendations will in general be followed, specifically since they are likely to be exceptional. In the case that the judgement, by the IESG and ISE, of merit conflicts, there is a procedure in RFC 5620. I'm for (a). --Olaf (no hats) Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
On Aug 28, 2009, at 4:13 AM, Dave CROCKER wrote: I am under the understanding the the IESG Note in RFC is provided by the IESG not by the RFC Editor. Is there a document that says otherwise? (I'm certainly open to the possibility that perhaps these documents should not have an IESG note but that seems a different issue) My understanding of this text is that the IESG can recommend text, including an IESG Note. The RFC Editor can accept it or not. As Russ said: the IESG can suggest text, which can be an IESG note. The RFC Editor, more specifically the Independent Submission Editor, is responsible for the followup, which includes the possibility of the variation described below. FWIW (and in my no-hats opinion) this 'negotiation' between IESG and ISE should all happen well before the RFC is submitted to the production center and the RFC Series Editor (RSE) should in general not be part of this loop. Only if the ISE and the IESG cannot come to agreement then the RSE is called in as described in RFC5620 section 4.1.3. ... I'm pretty sure, though, that there has been pushback and negotiation on quite a few occasions. It's important that the RFC Editor keeps this power, in the general interest of checks and balances. +1. One can debate various details and costs about the RFC Editor function. But it really is quite useful to have the editor exert an independent review of IESG efforts to modify an RFC. Not because the IESG is suspect, but because it is deeply involved in the topics it comments on and that could cause misguided decisions. By contrast, the RFC Editor can consider suggested IESG notes with detachment. My impression, too, is that this has produced revised IESG text. d/ -- Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Copyrights and the IRTF and Independent Stream
or on the definition of IETF Documents in the context of BCP78? Or, is the trust well suited, and does implementation only need some boilerplate changes? - IETF Stream RFCs need to be protected by limited derivative rights so that the IETF keeps ownership over its Standards and can maintain those. Suppose a I-D with full derivative rights is posted (either because the author has published it with Creative Commons, or because the Trust allows full derivative rights for stream specific I-Ds) would narrowing down the rights by publication as an IETF stream RFC cause any problems? Feedback welcome, --Olaf Kolkman PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] Status of DNSSEC signing of .arpa?
On 26 jul 2009, at 11:10, Samuel Weiler wrote: Earlier this month the IAB mailed IANA with a request to provide us plans: http://www.iab.org/documents/correspondence/2009-06-02-Roseman-Signing-by-IANA-of-ARPA.html Thank you again for following up with IANA. It looks like IANA has not yet signed .arpa nor related zones. Have they provided the IAB with a plan? Not yet. --Olaf Kolkman PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] Status of DNSSEC signing of .arpa?
On 10 jun 2009, at 00:53, Samuel Weiler wrote: Kind IAB, Today is the thirty-seven month anniversary of the IAB's request that IANA sign .arpa and related zones. Lather, rinse, repeat. Sam, Thanks for your reminder. Earlier this month the IAB mailed IANA with a request to provide us plans: http://www.iab.org/documents/correspondence/2009-06-02-Roseman-Signing-by-IANA-of-ARPA.html A link to this correspondence was added to our web-page earlier this week. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
On 1 jun 2009, at 16:56, Jari Arkko wrote: I do think though that additional information at the level of This RFC describes FOO. A standardized version of FOO can be found from RFC . is useful. I think -07 version of the 3932bis is an improvement over the previous one, and should be approved. The proposed text would allow for these sort of suggestions to be made to the Independent Series Editor (ISE, the approval body for the Independent Submissions Stream). IMHO these relational notes would be useful additions to Independent stream documents. Maybe not even as an IESG Note but as language in the abstract and/or introduction. However, the proposed language would also allow standard templates to be added. That would IMHO be wrong. I understand that for many people the distinction between the various streams is not always clear and that a large number of folk think that the RFC series is synonymous with Internet Standard documents, but I do not think that the IESG Note is the magic bullet to solve that. In any case: RFC4846 section 5 uses the word recommend If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published. That wording is chosen in such a way that the decision is with the RFC Editor, more specifically the ISE. I would try to bring 3932bis in line with that: OLD: The IESG may choose to add an IESG note to an Independent Submission or IRTF Stream document that explains the specific relationship, if any, to IETF work. NEW: The IESG may recommend [to the RFC Editor] to add an IESG note . The text in section 3 uses request which IMHO is in line with the spirit of 4846. And makes clear that the ISE could in fact push back on the recommendation or request. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
On 4 mrt 2009, at 16:33, Margaret Wasserman wrote: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. I don't believe that there are any legal implications to moving our IPR information to the back of the document, and it would be great not to have to page down at the beginning of every I-D to skip over it. If someone wants to check the licensing details, they could look at the end of the document. FWIW: On my todo list is coordination of the implementation of draft-iab- streams-headers-boilerplates and in addition the consolidation of boilerplate material in RFCs and I-Ds. Part of the equation is figuring out if and where copyright and license boilerplate material can be moved. The plan is under construction. --Olaf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Internet Society joins Liberty Alliance Management Board: Why?
On 1 mrt 2009, at 23:49, Lynn St.Amour wrote: PS. Re: your side note below on the makeup of the ISOC Board, we'll update the list to show the community or mechanism that appoints/ elects Trustees. In the meantime, the IETF appoints 3 Trustees (out of 13, 12 voting and me non-voting). The current IETF appointees to the ISOC Board are: Patrik Fältström, Ted Hardie and Bert Wijnen. Also note that the IAB is to select a new IETF appointee. See http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05771.html for the list of nominees. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Nov 27, 2008, at 8:49 PM, Matthew Ford wrote: After all the years of FUD surrounding DNSSEC deployment, I feel quite strongly that having the IETF do as you suggested and then be able to point to 'no discernible impact' on the network would be a significant milestone. Data point: IETF65 (Dallas) had a DNSSEC enabled recursive nameserver (and, if I recall well, signed reverse zones). No impact noticed whatsoever. I wonder how many people actually knew. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NTIA request for feedback on DNSSEC deployment at the root zone
There are links to a number of process flow diagrams that may interest you. For easy accessibility of those links see: http://www.ntia.doc.gov/DNS/DNSSEC.html --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 2026 interpretation question
On Oct 2, 2008, at 6:56 PM, Bob Braden wrote: The RFC Editor continues to publish STD 1 online, updated daily. And we recently published a periodic version as an RFC, over some people's dead bodies, I might add. I'm not sure wether you refer to: http://www.iab.org/documents/iabmins/iabmins.2008-04-16.html#3 But the reference seems relevant to the thread. --Olaf (who happens to like zombie movies) PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] The RFC Editor and the Internet Standards Process
On Sep 9, 2008, at 9:56 PM, SM wrote: Hello, A proposal was posted at http://www.iab.org/documents/resources/RFC-Editor-Model.html about a new structure for the RFC Editor. I read about the Internet Standards Process and couldn't find the answer to a question. Quoting Section 4.2.3 of RFC 2606: The RFC Editor is expected to exercise his or her judgment concerning the editorial suitability of a document for publication with Experimental or Informational status, and may refuse to publish a document which, in the expert opinion of the RFC Editor, is unrelated to Internet activity or falls below the technical and/or editorial standard for RFCs. Furthermore, .. the IESG and the RFC Editor have agreed that the RFC Editor will refer to the IESG any document submitted for Experimental or Informational publication which, in the opinion of the RFC Editor, may be related to work being done, or expected to be done, within the IETF community. Given that the RFC Editor is explicitly mentioned in RFC 2026, does RFC 2606 have to be revised to bring it in line with the proposed structure? I would argue that 2026 does not need to be revised. The model discribes the collective of functions that taken together we call The RFC Editor. Various people have already commented that using the same words for one of the functions is confusing. More to the point 4.2.3 is about what we have started to call the independent submissions and it is the Independent Submission Editor function in the model that takes the responsibilities that are described in the paragraph above. Also see RFC4844 and RFC4846. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Review of draft-ietf-forces-mib-07
Essentially, this note is another me too. On Sep 2, 2008, at 11:56 PM, John C Klensin wrote: (iv) If that note is acceptable to the authors/ editors/ WG/ etc., generation of a document that incorporates the changes. That version is, or is not, posted at the discretion of the RFC Editor and/or WG Chair and/or AD. In other words, the document editor prepares a clean draft with the RFC Editor note(s) incorporated, rather than expecting the RFC Editor to do so. If a draft is posted at (ii), it implies that significant changes have occurred and may trigger the re-review to which Spencer refers. The IESG approval at (iii) is considered final and the document at (iv) simply an editorial matter of splicing the changes in. If that latter document is posted at all, it is with the understanding that additional substantive comments, or even post-IESG fine-tuning, are inherently disruptive and time-consuming and that they should not be accepted unless they raise new, very significant, showstopper-level issues. Otherwise, we would never finish anything. Personally I would like to see that whatever document enters into the RFC-Production function (to use the terminology from the RFC Editor model[*]) has a clean copy in the repository. That allows for a very clean interface between the streams and the RFC-producer. So, I would argue that the result of (iv) is always posted. I can imagine that the posting of an I-D may cause Pavlovian reactions but maybe there are means by which one can prevent folk to mistake the posting of such I-D as another request for review. --Olaf [*] For those for who this terminology is new see: http://www.iab.org/documents/resources/RFC-Editor-Model.html PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF72, IPv6 Panel Report
Dear Colleagues, The IAB would like to thank all of you who attended or otherwise participated at the IETF 72 Technical Plenary's panel on IPv6 adoption in Dublin. We heard about IPv4 exhaustion contingency planning and about real-world IPv6 adoption successes and barriers from: - Mark Kosters (ARIN's perspective and policies about IPv4 address exhaustion) - Alain Durand (Comcast's IPv6-enabled network infrastructure) - Lorenzo Colitti (Google's IPv6-enabled content services) - Shin Miyakawa (NTTcom's IPv6-enabled consumer services) - Stuart Cheshire (Adoption of IPv6 in applications like Apple's Safari web browser) Audio stream archive: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ Select ietf72-ch3-wed-plenary.mp3. The IPv6 panel starts at time 01:13:00 on the stream. Presentation archive: https://datatracker.ietf.org/meeting/72/materials.html See heading Plenary Sessions, session PlenaryW. The consistent message from the presentations was that most of the code implementation work for IPv6 is done -- the protocols have been designed, and implemented in all major operating systems and networking devices. Most widely-used software (like networking gear, OS software, and web browser clients) has already been updated to support IPv6, and most application software written to use higher-level connect-by-name APIs. Popular development languages like Java get IPv6 support for free without any code changes at all. However, the participants were clear that although the actual operational deployment of IPv6 is much easier technically than they expected, it takes longer than expected; they urged the rest of the community to begin their deployment work as soon as possible. One common theme was that, as with many technological advances, success stories in IPv6 adoption are frequently the result of one or two motivated individuals who take the initiative to make things happen in their organization. If you yourself have worked on throwing the IPv6 switch within your organization, or you know of someone with an interesting IPv6 adoption story, the IAB invites you to let us know about it, including issues overcome, or hurdles still before you. Send your story to: [EMAIL PROTECTED] The IAB will deliver a summary report on these stories at a future IETF meeting. On the universal deployment of IPv6[*], -- For the IAB Olaf Kolkman PS: Want to make a difference? A brainstorm of ideas follow: * Share the slides and a report of the plenary session with the networking lead in your organization's IT department. * Personally request IPv6 service from your ISP and enable IPv6 for your home network. * Prepare your laptop for IPv6 and primarily use the IPv6 network at IETF 73. * If you work on application code, make sure your application works with IPv6, and if not, fix it. (Even if you don't test wide-area IPv6, at the very least make sure your application works with IPv6 link-local addresses, which are configured automatically these days on Mac OS X and Windows.) * Start using IPv6 operationally within your organization. [*] There is an old tradition to toast on the Universal Deployment of IPv6 during the the IETF Scotch BOFs. With that in mind we plan to provide the best story with a bottle of single malt. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: IAB Open Microphone session on Thursday?
On Jul 31, 2008, at 2:50 PM, David Kessens wrote: Olaf, On Wed, Jul 30, 2008 at 11:52:36AM -0700, IAB Chair wrote: We would like to create such opportunity on Thursday but only if interest is demonstrated. If you have a question for the IAB, please sent it to [EMAIL PROTECTED], by 2pm Thursday 31st. I am afraid that this procedure itself is a reason for questions. I don't see why sending a question to the IAB in advance is necessary to determine whether there is interest in the community to have a discussion with the IAB. In fact we talked about this this morning and it occurred to us that for accountability it is, at minimum, necessary that everybody knows who the members are, regardless wether or not there are questions. Being on stage is therefore a good thing. Personally, I think there is benefit to questions being mailed in advance. It serves two purposes: It helps with phrasing the question concisely and it helps the IAB members to provide a response that has been given more than a few seconds thought. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Disappointing to not have plenary slides online for remote participants...
On Jul 31, 2008, at 5:55 PM, Dan York wrote: Being a remote participant (for the first time) at this IETF 72 meeting, I have to say that my main disappointment was that some or all of the slides for the two plenary sessions were not available at the time of the plenary. In the Wednesday Plenary, only two of the 4 IPv6 presentations were available. The ARIN presentation, in particular, had a number of charts that made it rather useless to be listening to the audio as we had no clue what was being discussed. The two missing presentations were later uploaded, but they were not available when they were being discussed. My apologies for this, there were a few technical and logistical problems that made uploading the slides in time impossible. Your point is dully noted though: Availability of material is important to enable remote participation. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC Editor Structure
Dear Colleagues, This message, with apologies for possible duplicates, is to aware you of a proposed change in the RFC Editor model. The Internet Architecture Board is responsible for the RFC series oversight. With this message we want to notify possible stakeholders of the possibility to provide feedback on the plan. The proposed model is posted on the RFC interest list, see http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-May/000581.html and made available through http://www.iab.org/documents/resources/RFC-Editor-Model.html . Discussion should take place on the RFC interest list. To subscribe go to http://www.rfc-editor.org/mailman/listinfo/rfc-interest. The IAB will gauge consensus shortly after the IETF meeting in Dublin (July 27 - August 1, 2008). For the IAB, --Olaf Kolkman PGP.sig Description: This is a digitally signed message part ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-enum-infrastructure (The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM) to Informational RFC
On Jun 2, 2008, at 8:37 PM, The IESG wrote: The IESG has received a request from the Telephone Number Mapping WG (enum) to consider the following document: - 'The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM ' draft-ietf-enum-infrastructure-07.txt as an Informational RFC To the IESG and the ENUM WG, The ENUM WG and its chairs, together with the RAI Area Directors have asked the IAB for a review on Infrastructure ENUM documents based on the current state of the Internet Drafts in the ENUM working group. IAB has collected information about Infrastructure ENUM, its rationale, use cases and reviewed the ENUM WG discussion surrounding its deployment challenges. IAB has drawn the conclusion that the current Internet Drafts regarding Infrastructure ENUM are reusing ENUM technology but potentially use it with an alternative anchor other than the e164.arpa domain, as defined in RFC 3761, that was agreed to between IAB and ITU-T. It is well known that ENUM technology is used today with multiple anchors in both public and private schemes outside of e164.arpa. That said, IAB is generally concerned with the referential integrity of lookup mechanisms that may be used by multiple entities for fundamentally different purposes. Such usage requires that the resolution algorithm produce different responses depending on the context. One such context, when discussing ENUM, is what anchor is in use. This issue is similar to that of the namespace context in the DNS and the uniqueness of the root, which are discussed in RFC 2826. For alternative ENUM anchors to work, agreements are needed on what anchor to use, how the selection of anchors should be controlled, and who should be the registry. The ENUM working group has created a series of documents regarding Infrastructure ENUM. The IAB understands there is (working group) consensus to publish these documents as RFCs. Based on the reasons laid out above, the IAB suggests the documents be published as Informational RFCs only, as is currently proposed. The IAB believes that the IETF should not make any unilateral decisions regarding issues about mapping e.164 numbers into the DNS. The possible use of another domain is considered outside the existing agreements surrounding e164.arpa between IAB and ITU-T. Such issues fall within the scope of the ongoing and successful cooperation between the ITU-T and the IETF. Consequently, the IAB plans to send a liaison letter to the ITU-T, and based on the response, the IAB will suggest further steps for the ENUM WG in the IETF. For the IAB, --Olaf Kolkman PGP.sig Description: This is a digitally signed message part ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Blue Sheet Change Proposal
On Apr 4, 2008, at 1:16 AM, Ray Pelletier wrote: All, We are considering changing the meeting Blue Sheet by eliminating the need to enter an email address to avoid spam concerns. Is there any good reason to retain that info bit? Ray There may be reasons to contact participants after a meeting, being able to tie the name to an e-mail might be of value. If folk think the spam concern is important (not me) the engineering approach is a layer of indirection: print a registration ID on the badges, and have folk fill in that I-D on the blue sheet, together with their names off course. --Olaf - Due to a mishap my right hand is in cast and I can only type short messages using my left hand. Apologies for the snappy tone that may be caused by that. Olaf Kolkman [EMAIL PROTECTED] PGP.sig Description: This is a digitally signed message part ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call for two IPR WG Dcouments
Colleagues, The IAB discussed the IPR documents during its most recent call. It unanimously decided that the IAB-stream is to be covered by the incoming IPR document. It is our understanding that the iab-stream documents IPR are then automatically covered by the outbounds rights that the IETF trust will establish based on the advice in draft-ietf- ipr-outbound rights. We also want to stress that for any change in the inbound rights for streams other than the ietf- and iab-stream there needs to be a stream dependent discussion and approval process as indicated in RFC 4844 The RFC Series and RFC Editor section 4.2.3. To that extent section 4 of the draft should explicitly mention that the irtf-, the independent- and any possible future streams are not covered by the draft. For the IAB, Olaf Kolkman PGP.sig Description: This is a digitally signed message part ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call for two IPR WG Dcouments
On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote: While not really disagreeing with Leslie and Olaf, I would point out that the IPR WG was chartered to look at IETF documents. Those being ietf-stream exclusively or implicitly also covering the iab-stream? Personally, I think it makes sense that the iab-stream is covered, but let me put that in front of the IAB too. We can have a meta-discussion about where the clarifications belong, but it seems to me that the WG consensus definitely assumed that scope and no wider scope. I'd be happy if that was made clear in the drafts, rather than trying to cover the other documents streams by some kind of awkward retro-fit. 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. Such a rewrite would preserve the status quo for the independent and irtf stream. no-hats, --Olaf no further comments below On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote: While not really disagreeing with Leslie and Olaf, I would point out that the IPR WG was chartered to look at IETF documents. We can have a meta-discussion about where the clarifications belong, but it seems to me that the WG consensus definitely assumed that scope and no wider scope. I'd be happy if that was made clear in the drafts, rather than trying to cover the other documents streams by some kind of awkward retro-fit. Brian On 2008-03-28 08:15, Leslie Daigle wrote: --On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman [EMAIL PROTECTED] wrote: I would think that the document would gain in clarity if it explicitly ties the incoming rights to the streams as defined in RFC4844 and also explicitly calls out that if new streams would be defined those should specifically define if and how rights are transferred to the IETF Trust. I would have to agree with the above, and say further that the the IAB should make sure that the entities responsible for the non-IETF streams are okay with the result. When writing the streams definitions, it was clear that there was a lot of material that was spread across existing documents without clear delineation between IETF or non-IETF documents, let alone further refinement into what has become streams. THat's understandable, historically, but we should be clearer going forward. Breaking it out, as you suggest, would be consistent with that goal. Leslie. While reviewing the documents I tried to determine how the 4 streams currently defined in RFC4844 fit into the framework. Although the stream is not specifically mentioned it is clear that the incoming rights document applies to the IETF Stream. To me it is clear that a contribution to the IAB is explicitly bound by the rules (including the No Duty to Publish rule, that allows for confidential information to be supplied to the IAB), so are contributions from the IAB, i.e. IAB stream document. I conclude this from the fact that IAB is part of the IETF under the definition in 1.e. However, I may be over-interpreting, and the status of the incoming rights for the IAB stream is also not captured. The independent stream document are clearly excluded by section 4 of the document. It is not quite clear where the IRTF stream document live. This could be fixed in a document which defines the IRTF stream. I would think that the document would gain in clarity if it explicitly ties the incoming rights to the streams as defined in RFC4844 and also explicitly calls out that if new streams would be defined those should specifically define if and how rights are transfered to the IETF Trust. --Olaf (no hats) ___ 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 PGP.sig Description: This is a digitally signed message part ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call for two IPR WG Dcouments
While reviewing the documents I tried to determine how the 4 streams currently defined in RFC4844 fit into the framework. Although the stream is not specifically mentioned it is clear that the incoming rights document applies to the IETF Stream. To me it is clear that a contribution to the IAB is explicitly bound by the rules (including the No Duty to Publish rule, that allows for confidential information to be supplied to the IAB), so are contributions from the IAB, i.e. IAB stream document. I conclude this from the fact that IAB is part of the IETF under the definition in 1.e. However, I may be over-interpreting, and the status of the incoming rights for the IAB stream is also not captured. The independent stream document are clearly excluded by section 4 of the document. It is not quite clear where the IRTF stream document live. This could be fixed in a document which defines the IRTF stream. I would think that the document would gain in clarity if it explicitly ties the incoming rights to the streams as defined in RFC4844 and also explicitly calls out that if new streams would be defined those should specifically define if and how rights are transfered to the IETF Trust. --Olaf (no hats) PGP.sig Description: This is a digitally signed message part ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Impending publication: draft-iab-dns-choices-05
Dear Philip, You referred to draft-hallambaker-xptr-00.txt and wrote: The list of comments does not include my core objection made in the 'Domain Centric Administration' and XPTR drafts, that it is in fact possible to create 'midpoint' wildcards of the form '_prefix.*.example.com' by the simple measure of introducing a layer of indirection. This may be implemented by defining semantics for the existing PTR record in the forward DNS or by introducing one new RR to deal with the issue as is suggested in XPTR. [U] If you want to construct this wildcard you may use: *.example.comPTR _wildcard.example.com _prefix1._wildcard.example.com TXT Text _prefix2._wildcard.example.com SRV blah... _prefix3._wildcard.example.com NAPTR blah... The search strategy is then quite simple, if a search for the record itself returns no answer you look for the PTR record at the node to be queried, if that exists you concatenate the prefix to the result of the PTR indirection and do a lookup there. This strategy is one that may work. I'd argue that defining an XPTR RR is probably cleaner than the re-use of a pointer record because the semantics of PTR might be hardcoded somewhere outside of your control. An observation of more fundamental nature is that you are moving away from a query-response model to a search strategy. And the first tradeoff you make there is one of performance and load on the system as a whole. It is easy to argue that the DNS can deal with the extra load, but I note that your proposed strategy involves an extra query _every_ time that you do not get a response to a query to the direct name. Obviously not a problem during the onset of the deployment (your proposal has the nice property of incremental deployment) but if the approach gets ubiquitous then we have pushed significant costs to the system as a whole. I am of the opinion that taking NO (NXDOMAIN) for an answer is, IMHO, an important property of the scalability of the DNS and we need to think very deep about the consequences of these extra queries. The strategy always completes in two or three lookups, there is never a requirement to do tree climbing. A DNS server can efficiently predict the optimum responses to send as additional records. It is fully compatible with other DNS extensions. The above paragraph suggests a strategy to deal with the performance issue. Note however that this means that your proposal relies on special processing that will will need to be implemented in authoritative and recursive nameservers. That makes this performance optimization is subject to the same arguments you use to counter the arguments that one cannot rely on the ubiquitous support for unknown resource records. Also there are reasons not to rely on the results provided in the additional sections (in absence of DNSSEC). There have been proposals to do some sort of pre-processing to generate the nodes that should match _bla._foo.*.example.com. Such proposals will not be able to generate each an every combination for the wild-card but that may be sufficient for the use cases at hand. All and all, I am not convinced if your proposal is _the_ solution to the wildcard problems at hand. My main problem with it is the extra query after an NXDOMAIN. I think that the DNSEXT working group is a better place to discuss the proposal and I've CC-ed them on this note. Having said all this, I do agree with your point that the RR-type space is not infinite. The question if that is a problem can only be answered by the Crystal Ball of the proper brand. I think it would be fair to suggest some text to deal with that issue. Also, although I know I'm biased, and can blame English to be my second language, I have always read the dns-choices document as a series of considerations and trade-offs. If you could point out the fragments of text that come across as degrading that would help the editor. In that context the request to send text is fair. In the spirit of the send-text and the above discussion I would suggest text along the following line: Somewhere around the section where the wildcard arguments are made: -- There have been proposals to deal with the problem that DNS wild-cards are always terminal records. These proposals introduce an additional set of trade-offs that would need to be taken into account when assessing which extension mechanism to choose. Aspects of extra response time needed to perform the extra queries, costs of pre- calculation of possible answers, or the costs induced to the system as a whole come to mind. At the time of writing none of these proposals has been published as standards tracks RFCs. -- And we probably need to mention explicitly that the RRTYPE code space is finite. I think that somewhere in section 5 we can add a paragraph along the following lines: -- There is a
Re: Impending publication: draft-iab-dns-choices-05
A minute ago I wrote: I think that the DNSEXT working group is a better place to discuss the proposal and I've CC-ed them on this note. I used the wrong address in the CC line. Be aware of that if you want to continue the discussion on DNSEXT: [EMAIL PROTECTED] is the proper address of that WG. --Olaf PGP.sig Description: This is a digitally signed message part ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Correction: Impending publication: draft-iab-dns-choices-05
I managed to sneak in two errors: 1. a February 23 deadline, that should have been March 28 2. a link to version 03 of the document, that should have been 05. For completeness: The IAB is ready to ask the RFC-Editor to publish Design Choices When Expanding DNS draft-iab-dns-choices-05 as an Informational RFC. This document provides a number of considerations to assist application and protocol designers in choosing a mechanism to store and retrieve data in the DNS. It treats, among other things the pros and cons of using TXT records, and of adding prefixes or suffixes to owner names. It argues that adding a new Resource Record is the best solution to add new data to the DNS and that the use of TXT Resource Records is the worst. The IAB solicits comments by March 28, 2008. Please send comments to the IAB ([EMAIL PROTECTED]), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-dns-choices-05.txt From the Abstract: This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. Olaf Kolkman, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Impending publication: draft-iab-dns-choices-05
The IAB is ready to ask the RFC-Editor to publish Design Choices When Expanding DNS draft-iab-dns-choices-05 as an Informational RFC. This document provides a number of considerations to assist application and protocol designers in choosing a mechanism to store and retrieve data in the DNS. It treats, among other things the pros and cons of using TXT records, and of adding prefixes or suffixes to owner names. It argues that adding an new Resource Record is the best solution to add new data to the DNS and that the use of TXT Resource Records is the worst. The IAB solicits comments by February 23, 2008. Please send comments to the IAB ([EMAIL PROTECTED]), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-dns-choices-03.txt From the Abstract: This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. Olaf Kolkman, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
