Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-05
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Document: draft-ietf-intarea-nat-reveal-analysis-05 Reviewer: Peter Yee Review Date: Mar-08-2013 IETF LC End Date: Mar-08-2013 IESG Telechat date: TBD Summary: This draft is on the right track but has open issues, described in the review. [Ready with issues.] This draft catalogs and analyzes various means of supplying a host identifier to a remote server when Carrier Grade NAT or similar host obscuring technology is in use. General: There were sentences in the draft that I could not parse even in the context of surrounding text. That's primarily why I'm marking this draft as Ready with issues. These sentences are supplied below. Mostly, the document has a fair number of nits. The general concept is fine. General: hyphenate uses of address sharing when it used as an adjective. For example, address-sharing device. General: expand acronyms on first use except if they are really well known in our community (e.g., TCP/IP) or where they appear in the abstract. Examples of acronyms in need of expansion are HIP, XFF, . General: You will probably want to resolve Internet Draft references to something more permanent. General: The term broken should be replaced with something more specific or useful. I've made some suggestions below. Section 1, 2nd paragraph, last sentence: delete an before information. Section 1, 3rd paragraph: change are to include. Section 1, 3rd paragraph: change customers unsatisfaction to and customers' dissatisfaction. Section 2, 1st paragraph, 2nd sentence: delete an before extra. Change than to beyond. Section 2, 1st paragraph, 3rd sentence: replace this sentence with We call this information the HOST_ID. Section 2, 2nd paragraph: add a serial comma after subscriber. Serial comma use in the draft was inconsistent. Section 2, 3rd paragraph, 3rd sentence: I'm not sure why the HOST_ID and public IP address would be relatively unique. Assuming that HOST_IDs are unique amongst the hosts hidden behind the public IP address and the public IP address is unique, I would have thought that the combination was globally unique. My confusion may arise from the 4th sentence which is incomplete. Perhaps those two sentences could be rewritten for clarity. Section 2, 4th paragraph, 1st sentence: change put to conveyed. Section 2, 4th paragraph, 2nd sentence: change put to conveyed. Section 3, 2nd paragraph, 1st sentence: considering using identifiability instead of uniqueness. Section 3, 2nd paragraph, 2nd sentence: replace which with what. Section 3,1, 4th paragraph: add a comma after re-write. Change re-write to rewrite. Section 3.1, 5th paragraph: I don't quite follow what's being said here. Is the point that the address-sharing function should reveal the same HOST_ID for any given host regardless of what layer or mechanism that HOST_ID is being conveyed across? How does this relate to interference between HOST_IDs? Section 4.1.1, 1st paragraph, 1st sentence: delete an before information. Section 4.1.1, 1st paragraph, 3rd sentence: insert , there are after hence. Section 4.1.1, 4th paragraph, consider replacing with: Address-sharing devices using this solution would be required to indicate that out of band, possibly using a special DNS record. Section 4.1.2, 3rd paragraph, 2nd sentence: add a comma after scenario. Change broken to ill-advised. Section 4.2.1, 1st paragraph, 2nd sentence: add A at the beginning of the sentence. Section 4.2.1, 1st paragraph, 4th sentence: rewrite as This IP option allows the conveyance of an IPv4 address, an IPv6 prefix, a GRE key, an IPv6 Flow Label, etc. Section 4.2.1, 2nd paragraph: insert an before IP. Section 4.2.2, 1st paragraph, 1st sentence: change for to to. Section 4.2.2, 1st paragraph, 2nd sentence: use of the term filter in this sentence is not clear. Do you mean that that routes and middleboxes remove the IP options? Or that they remove packets with IP options? Or that they take other actions based on the presence of IP options? Please clarify. Section 4.2.2, 2nd paragraph: replace As a with In. Define host-hint somewhere. Is it meant to be equivalent to HOST_ID? Section 4.3.1, 3rd sentence: change their to its both places in the sentence. Insert or before subscriber. Section 4.3.2, 2nd paragraph, 2nd sentence: insert a before HOST_ID Section 4.3.2, 2nd paragraph, 3rd sentence: change in host to on the host. Insert the before address, and add a comma after function. Section 4.3.2, 1st bullet item: this is the IETF. We don't need no stinkin' OSI! :-) Section 4.3.2, 1st bullet item, 2nd sentence: replace the sentence with Moreover, an updated version of [I-D.wing-nat-reveal-option] no longer allows conveyance of a full IP address as the HOST_ID is encoded in 16 bits. Section 4.3.2, 2nd bullet item, 1st sentence: delete the comma after limited.
The TSV discussion and its spinoffs (was: Re: Nomcom is responsible for IESG qualifications)
--On Friday, March 08, 2013 18:57 -0500 Jari Arkko jari.ar...@piuha.net wrote: FWIW, I do believe that noncoms may decide for themselves what the final requirements are for specific positions. This is true in this case as well. The IESG has a role to send the starting point for these requirements, the desired expertise. (But it is possible that the nomcom does not see a need to change what the input said, which may help explain what Dave has seen.) ... I agree with Jari's note (the part I didn't quote as well), but want to make three suggestions (mixing threads a bit): (1) A continued debate about the limits to job descriptions and suggestions or mandates about requirements doesn't help anyone right now. I can't imagine the current nomcom feels that it is so lacking in input on the subject that another note on the IETF list will help. And, if the community believes that there is either ambiguity or that the current rules, whatever they are, are wrong, I hope everyone agrees that the way to address that is to create a draft with clarified or different rules and see if it gets community consensus. (2) I can't and won't speak to what has happened in any particular year, but at least part of the IAB's shift to give us a slate is a consequence of Nomcoms choosing to move people between areas. That can create a race condition among candidates qualified for any given position. To the extent to which the IAB has concerns about balances of various sorts on the IESG -- such as overrepresentation of one particular country or various diversity issues-- there is no plausible way to look at those questions without doing so on a slate. The specifications don't prevent the IAB from considering those criteria. As with the above, it is probably too late for this year and those who feel that the IAB should be more constrained (or who feel the the options should be clarified so they don't come up again) should, IMO, probably be writing drafts rather than seeing if their positions become more persuasive if repeated enough times. (3) People agree to be candidates for various positions with a certain expectation of privacy based on the rules in effect when the call for candidates is issued. The community can to change the rules again. Doing so should come with the understanding that such changes may change the profile of those who are willing to volunteer. But changing the rules mid-process, whether by asking people to disclose questionnaires (and inevitably putting those who don't to explain why not, whether the comments in them are formally confidential or not) or getting into public discussions about qualifications for a position while that position is under active consideration by the Nomcom (not because the qualifications should be an issue but because, once the candidate list is known, comments about qualifications are comments about candidates unless everyone is hyper-careful about what they say, how they respond to what others say, and what inferences they draw. It may be that we should change our process to allow (or require) Nomcoms to conduct public fact-finding discussions about qualifications and other considerations before issuing the formal call for candidates. At the risk of repeating myself, those who like either that idea or changing (or clarifying) the confidentiality rules should probably be writing drafts. thanks, john
Re: The TSV discussion and its spinoffs
John == John C Klensin john-i...@jck.com writes: John confidential or not) or getting into public discussions about John qualifications for a position while that position is under John active consideration by the Nomcom (not because the John qualifications should be an issue but because, once the John candidate list is known, comments about qualifications are John comments about candidates unless everyone is hyper-careful John about what they say, how they respond to what others say, and John what inferences they draw. John, I agree with what you say and what Jari said--both the part you quoted and the rest of his note. However, I think the part of your note above is a bit unclear. I realize you and I have been having side discussions about this issue for a few days now, but I suspect the IETf list may not be able to follow what you wrote above, because I had significantly difficulty the first time you explained it to me. When you engage in a discussion of qualifications while there is an open position, you very quickly force others to either abandon the discussion or to make comments that expose information about how they feel about candidates. Let's take an example that happened here. Joe Touch said something that roughly boiled down to he didn't want to see an AD who required a tutorial in basic networking knowledge. I felt that wasn't a useful place to take the discussion because I feel that the candidates in question don't need such a tutorial. I have a number of options: 1) I can say that. However, if someone out there does feel that we have candidates who should be disqualified for this reason, they're now in a really bad position. They either need to speak up and thus disclose information about their evaluation of candidates or stay silent in which case the discussion passes them by and pushes people out of the discussion. 2) I could take a page from consensus-building techniques and say Joe, I'm confused; it's not obvious to me which candidates need such a tutorial. Who are you thinking of? That would actually be a great approach to try and understand where Joe's coming from if there weren't confidentiality involved. It's absolutely the wrong answer here because it puts Joe in a really bad position. 3) I can ignore the discussion. However if a lot of people do this, we end up focusing time in the discussion on issues that we don't have community interest in, only because we're excluding a lot of community members from expressing that. Similar examples are easy to find. my conclusion is that you basically cannot discuss requirements for an open position while it's open and get meaningful results. I look forward to the discussion of future years. I hope that who ever is moderating that discussion is very careful to close down any attempts to bring it to a discussion of this year or what this year's nomcom should do. In my opinion, people who have opinions about that should contact the nomcom and iab (nomco...@ietf.org and i...@ietf.org).
Re: The TSV discussion and its spinoffs
--On Saturday, March 09, 2013 10:31 -0500 Sam Hartman hartmans-i...@mit.edu wrote: John == John C Klensin john-i...@jck.com writes: John confidential or not) or getting into public discussions about John qualifications for a position while that position is under John active consideration by the Nomcom (not because the John qualifications should be ... John, I agree with what you say and what Jari said--both the part you quoted and the rest of his note. However, I think the part of your note above is a bit unclear. I realize you and I have been having side discussions about this issue for a few days now, but I suspect the IETf list may not be able to follow what you wrote above, because I had significantly difficulty the first time you explained it to me. When you engage in a discussion of qualifications while there is an open position, you very quickly force others to either abandon the discussion or to make comments that expose information about how they feel about candidates. ... Sam, Yes, that is exactly correct. I didn't say more because I'm all-too-familiar with people not reading my longer notes and thought writing in a little less detail might be a good tradeoff. Thank you for the example -- at least IMO, it illustrates the problem very well and, as you say, it isn't hard to come up with others. ... Similar examples are easy to find. my conclusion is that you basically cannot discuss requirements for an open position while it's open and get meaningful results. I look forward to the discussion of future years. I hope that who ever is moderating that discussion is very careful to close down any attempts to bring it to a discussion of this year or what this year's nomcom should do. In my opinion, people who have opinions about that should contact the nomcom and iab (nomco...@ietf.org and i...@ietf.org). For whatever it is worth, this is yet another part of the argument for Nomcom reports that are well-thought-out, careful about confidentiality, and that, ideally, pose questions and alternatives for the community to think about in public and defines a foundation for discussing them. thanks again, john
Re: Welcome to IETF-86!
On Fri, 8 Mar 2013, Jari Arkko wrote: The IETF meeting is beginning on Sunday. I'd like to welcome everyone to the meeting! This blog highlights some of topics that I find most interesting in the meeting: http://www.ietf.org/blog/2013/03/welcome-to-ietf-86/ Is someone going to update the IETFers iphone app? It still does not have the sculed in it :/ Paul
RE: [IETF] Petition for We the People US Federal Government
petition process: Create a Request for Comment (RFC) process similar to the IETF's for taking in suggestions for innovation from public. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8f838cff8b048104d76e919a --e89a8f838cff8b048104d76e919a Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Richard, IETF process may not be ideal, but it is better. More importantly, it is a grassroots (not industry specific, and totally vendor dominated) process, that at least considers unsolicited ideas based on merit, not popularity. And I bet NIST or GSA or the CTOs office are the right agencies to implement it. It is guaranteed to be light years better than a petition website.. Thanks for reading.. Sam Crooks scro...@microsoft.com From: Richard Barnes Sent: =E2=80=8E3/=E2=80=8E8/=E2=80=8E2013 11:09 AM To: Sam Crooks Cc: Warren Kumari; kho...@salesforce.com; patrick.gallag...@nist.gov; case_c...@yahoo.com; ietf@ietf.org Subject: Re: [IETF] Petition for We the People US Federal Government petition process: Create a Request for Comment (RFC) process similar to the IETF's for taking in suggestions for innovation from public. I think you may be over-estimating the filtering power of the Internet-Draft system. On Thu, Mar 7, 2013 at 2:08 PM, Sam Crooks sam.a.cro...@gmail.com wrote: not a Joke, Warren (and IETF). The petition process is the best I have found to put in unsolicited suggestions. The RFI process and public comments are the ways to put in solicited comments on some topic. There is not a good merit-based proces= s to put suggestions and ideas into the government, I am trying to get an effective one created. The IETF Internet Draft process is the most effective I can think of for a grassroots process to take input and kill the Internet trolls who hijack such processes.. I would appreciate your help, as well as the rest of the networking industry's help, in highlighting the issue to people in the federal government who can change it and put in an effective process. There is innovation going on in the government, and they are starting to put in place processes for innovation internally, but the government does not have an effective process for gathering ideas from the public and validating them based on merit. The Whitehouse's We the People website is a popularity contest which occasionally produces interesting things, like the recent Build the Death Star petition response from the Whitehouse. General Services Administration (GSA) is probably one of the most innovative government agencies in relation to IT. NIST and DHS NPPD and the DHS ST directorates are very innovative as well, particularly in regards to cybersecurity and information assurance. State department as well. Casey Coleman of the GSA writes a great blog on the innovation occurring in the government, and is one of the most forward looking CIOs. http://gsablogs.gsa.gov/innovation/ GSA is trying to innovate. Read this article: http://www.govexec.com/management/2013/03/hunting-great-ideas-should-be-e= veryday-affair-gsa-chief-says/61674/ The Whitehouse is doing some interesting things as well Hackathonshttp://www.whitehouse.gov/blog/2013/03/02/looking-back-white-h= ouse-hackathon Exposing government data sets Open Government initiativehttp://www.white= house.gov/open/around Data.gov Presidential Innovation Fellows programhttp://www.whitehouse.gov/innovat= ionfellows Help me highlight a great process that works (at least considerably bette= r than petitions) for collecting and vetting ideas from anybody on how and why something should be changed, and perhaps it will be implemented. The petition: http://wh.gov/G29p http://wh.gov/G29p Regards, Sam Crooks http://www.linkedin.com/in/samcrooks/ sam.a.cro...@gmail.com On Thu, Mar 7, 2013 at 10:22 AM, Warren Kumari war...@kumari.net wrote: 'm assuming this is a joke=E2=80=A6 but my subtlety filters are turned d= own, so who knows... The Internet Draft process of the IETF works so effectively at filterin= g out Internet trolls because of the rigor and structure required for a proposal to be submitted. W On Mar 5, 2013, at 9:55 PM, Sam Crooks sam.a.cro...@gmail.com wrote: Hi all: If you agree, please sign this petition. I'd appreciate your help in crossing the thresholds required for consideration. Regards, Sam Text of the Petition: Create a Request for Comment (RFC) process similar to the IETF's for taking in suggestions for innovation from public. I believe that the We the People initiative is a good idea, grassroots-level suggestions, but a less than ideal implementation for collection of innovation suggestions. I propose that the Federal Government implement a process and structur= e similar to the Internet Engineering Task Force (IETF) Internet Draft and Request For Comment (RFC) processes and organization, which has proven
RE: [IETF] Petition for We the People US Federal Government
petition process: Create a Request for Comment (RFC) process similar to the IETF's for taking in suggestions for innovation from public. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ideal would be SharkTank. But that is bound to be difficult at a national level. (SharkTank is something we are doing in my org in my employer.. I make trouble everywhere, not just in public forums.. Intrapreneur is what they politely are calling people like me now apparently... Chief troublemaker is how I refer to it).. Sam Crooks scro...@microsoft.com Sent from my Windows Phone From: Joe Abley Sent: =E2=80=8E3/=E2=80=8E8/=E2=80=8E2013 12:21 PM To: Richard Barnes Cc: Sam Crooks; kho...@salesforce.com; patrick.gallag...@nist.gov; case_c...@yahoo.com; ietf@ietf.org Subject: Re: [IETF] Petition for We the People US Federal Government petition process: Create a Request for Comment (RFC) process similar to the IETF's for taking in suggestions for innovation from public. On 2013-03-08, at 14:09, Richard Barnes r...@ipv.sx wrote: I think you may be over-estimating the filtering power of the Internet-Dr= aft system. Perhaps the implication is that if the Whitehouse were to insist upon a 197= 0s publication format and employed an array of tools to reject submissions = based on formatting errors, only the most persistent trolls would get throu= gh? Joe (running away now)
Re: Orlando time for human language draft discussion
I replied, sorry about the delay. It looks like Thursday lunch would work well. On 3/5/13 4:47 AM, Randall Gellens wrote: Hi all, I created a Doodle poll to see if we can find a time in Orlando to meet face to face. Doodle poll for time at Orlando to discuss open issues and moving forward with Human Language Negotiation: http://doodle.com/uwedikez6etwsf39 Link to current version (-02) of draft: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt
Update on Orlando time for human language draft discussion
Hi everyone, It looks like Thursday lunch (11:30-1:00) works well for everyone who has responded so far. Let's plan on that for now. At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: It looks like Thursday lunch would work well. On 3/5/13 4:47 AM, Randall Gellens wrote: Hi all, I created a Doodle poll to see if we can find a time in Orlando to meet face to face. Doodle poll for time at Orlando to discuss open issues and moving forward with Human Language Negotiation: http://doodle.com/uwedikez6etwsf39 Link to current version (-02) of draft: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- A child of five would understand this. Send somebody to fetch a child of five.--Groucho Marx, Duck Soup
Re: Nomcom off in the wilderness: Transport AD
I'm really, really against turning this into an election-like process just because one nomcom did a bad job (and I agree they did). I've puzzled by this statement nomcom did a bad job. How could we, people outside of noncom, know that they did a bad job? They are the only ones who have all the information, all the variables in the equation. We don't. So I believe that, at this stage, we can't make that assertion. Being a positive person, I (want to) trust them. Regards, Benoit
Re: Nomcom off in the wilderness: Transport AD
On 3/9/13 1:46 PM, Benoit Claise wrote: I'm really, really against turning this into an election-like process just because one nomcom did a bad job (and I agree they did). I've puzzled by this statement nomcom did a bad job. How could we, people outside of noncom, know that they did a bad job? What we know is that it hasn't produced a AD that has been approved by the IAB. It's premature at the very minimum and imho probably inappropriate to start assigning blame. They are the only ones who have all the information, all the variables in the equation. We don't. So I believe that, at this stage, we can't make that assertion. Being a positive person, I (want to) trust them. Regards, Benoit
Re: Beta testing of xml2rfc version 2
Several bugs have been uncovered and resolved during beta testing. Thanks for your help. If you want to run xml2rfc on your own machine, it remains available from the sites listed in my earlier message (below). The new version of xml2rfc is now used at xml.resource.org. So, those people that use the web site will now get the new version by default. Just in case you encounter a problem with the new version of xml2rfc, the old version will remain available for a while. You can find the older version at: http://xml.resource.org/old.html Russ On Jan 18, 2013, at 7:52 PM, IETF Chair wrote: This announces the new xml2rfc implementation for beta testing. There are two components: a command line interface and graphical user interfaces. XML2RFC Version 2 - The rewrite of xml2rfc in python, tagged with version numbers 2.x.y, have been unofficially available for some time, and it is now officially announced as available for use. This package is a complete rewrite of the xml2rfc command-line functionality in python. The command line tool is available from the main Python package repository, PyPi: http://pypi.python.org/pypi/xml2rfc or alternatively from: http://tools.ietf.org/tools/xml2rfc2/cli/ A number of alternative installation methods are available, described on the PyPi page for xml2rfc. There are some known issues with the current release, none of them major. These are listed in the issue tracker: http://tools.ietf.org/tools/xml2rfc/trac/report/9 Bug fixing is actively happening. If you find bugs which are not already listed in the tracker, please add them. Please help us find the bugs. They cannot be fixed if we do not know about them. Also, suggestions for improvements are welcome. New releases will be announced at the xml2rfc mail list. GUI Frontends - There are also GUI frontends available for Mac, Linux and Windows. These are not undergoing active bugfixing at the moment, but should overall be in good enough shape for production use if you prefer a GUI interface instead of command-line for your XML to draft/rfc operations. If you are going to install the GUI version, it is suggested that you first install the latest command-line version, and then the GUI front-end. The GUI components can be downloaded from here: http://tools.ietf.org/tools/xml2rfc2/gui/ Please note that in some cases, the GUI installers come with an embedded version of the base tool, and this version will not necessarily be the latest version available. If you download and install a later version of the command-line tool, the GUI component should use that if it comes before the embedded version in your PATH, which will normally be the case. Feedback I hope you'll find that the rewrite of xml2rfc works well for you; it will certainly be easier to extend and bugfix than the previous version. If you have feedback, regarding bugs or enhancement suggestions, please use the issue tracker at: http://tools.ietf.org/tools/xml2rfc/trac/newticket Best regards, Russ Housley IETF Chair Henrik Levkowetz IETF Tools Program Manager
Re: [IETF] Re: Welcome to IETF-86!
On Mar 8, 2013, at 5:33 PM, Paul Wouters p...@nohats.ca wrote: On Fri, 8 Mar 2013, Jari Arkko wrote: The IETF meeting is beginning on Sunday. I'd like to welcome everyone to the meeting! This blog highlights some of topics that I find most interesting in the meeting: http://www.ietf.org/blog/2013/03/welcome-to-ietf-86/ Is someone going to update the IETFers iphone app? It still does not have the sculed in it :/ I have no idea, but this reminds me…. A huge, heartfelt thanks to whoever wrote it -- it makes life much much easier… W Paul -- Some people are like Slinkies..Not really good for anything but they still bring a smile to your face when you push them down the stairs.
Transport Area Director Position: Statement by the Nomcom Chair
The nominating committee process (see RFC 3777) has had difficulty in filling the TSV area director position this year. In particular, the process was unable to produce a confirmed candidate into the position prior to the Spring IETF meeting. There has been speculation about how the process reached this point. I would, therefore, like to provide the community with what information that I can, subject to the confidentiality rules that bind the Nomcom. Note that this is not a consensus statement of the Nomcom, and opinions expressed in this message are my own. In the selection of area directors, as stated in RFC 3777, the Nomcom operates with the advice and consent of the IAB, which acts as the confirming body for IESG positions. Despite the fact that the IAB and the Nomcom are both working hard to produce an outcome that satisfies the best interests of the community, the Nomcom has thus far not succeeded in putting forward a Transport Area Director candidate whom the IAB is willing to confirm. As per RFC 3777, the Nomcom receives written requirements from the IESG, and also talks to members of the community about the needs of the area and requirements for the position. However, at this point in time, it is possible that the Nomcom and the IAB lack a common understanding of the requirements for the Transport Area Director position and the current needs of the Area. The Nomcom is watching the discussion on the IETF mailing list and I appreciate those constructive comments that have been made on the list. However, if you have specific comments about the position of Transport Area director or the needs of that area, please do not hesitate to send comments directly to the Nomcom: nomco...@ietf.org. The Nomcom always welcomes comments from the community. Ultimately, the process is ongoing. I personally remain optimistic that additional dialog between the Nomcom, the community, the IAB, and the IESG will allow us to resolve the current situation. The Nomcom will continue its work until all open positions are filled. However, one of the challenges to everyone involved in the current situation is that RFC 3777 provides little guidance in cases such as this. Namely, where the Nomcom and a confirming body are not able to produce a confirmed candidate (for some position) prior to the First IETF meeting of the year. With regards to the discussion in TSVAREA, the Nomcom was not directly involved in the decision to have this community discussion in Orlando. (The Nomcom did recently inform the IESG that the process would not produce a TSV Area Director in time for Orlando, and had previously requested and received clarification of the IESG's written requirements from the IESG.) However, myself and at least several members of the Nomcom will be present at the TSVAREA session. I believe that the proposed discussion is constructive and that holding the discussion is appropriate. I do not know whether the discussion will help resolve the current situation, though it might. Furthermore, this is not the first year the nomcom process has had trouble filling the TSV area director position, and so at the very least, this discussion should begin to pave the way for a smoother process next year. Therefore, I would encourage all interested parties to attend. Finally, I realize that this message contains less detail than some of you would like. However, at this point in time, I am personally unwilling to disclose additional details to the community related to interactions between the Nomcom and the confirming body. Although RFC 3777 is not precise with regards to what is covered by Nomcom confidentiality, I would rather err on the side of broad interpretation of Nomcom confidentiality. I believe this is consistent with the interpretation of past Nomcoms with regards to interactions with confirming bodies. Thank you all for your patience in this matter. Please do not hesitate to contact me personally with any comments or concerns. - Matt Lepinski nomcom-ch...@ietf.org
Re: Nomcom Reports
I found your report useful. I intend to produce such a report. - Matt Lepinski nomcom-ch...@ietf.org On Mon, Mar 4, 2013 at 3:31 PM, Mary Barnes mary.ietf.bar...@gmail.com wrote: As far as I can tell, the last official Nomcom report was from the Nomcom I chaired (2009-2010): http://tools.ietf.org/id/draft-barnes-nomcom-report-2009-00.txt I have a general question for the community as to whether they find such reports useful and whether we should encourage future nomcom chairs to produce these? While this is not listed as a requirement in RFC 3777, I had understood as chair that this was a requirement for the job, but again, I've not seen that carried on. Personally, I don't find a few .ppt charts adequate in terms of summarizing the outcome of such an important IETF process. The Nomcom gains a unique insight into the operation of the IETF (and its leadership) that no one else gets. I will note that of the 4 issues that I raised in the report, there are 2 that remain critical IMHO: - Section 7.1 Diversity. Out of the leaders across the IAOC, IAB and IESG, there is one individual from Asia and one female (both on the IAB). - Section 7.3. Expertise. Of course, this is directly related to the long thread of discussion underway with regards to filling the Transport AD position - i.e., it's the exact same situation faced by the 2009-2010 Nomcom. The other two issues are of course, important, but didn't appear to be such an issue for this year's Nomcom. Regards, Mary.
Re: Beta testing of xml2rfc version 2
Several bugs have been uncovered and resolved during beta testing. Thanks for your help. If you want to run xml2rfc on your own machine, it remains available from the sites listed in my earlier message (below). The new version of xml2rfc is now used at xml.resource.org. So, those people that use the web site will now get the new version by default. Just in case you encounter a problem with the new version of xml2rfc, the old version will remain available for a while. You can find the older version at: http://xml.resource.org/old.html Russ On Jan 18, 2013, at 7:52 PM, IETF Chair wrote: This announces the new xml2rfc implementation for beta testing. There are two components: a command line interface and graphical user interfaces. XML2RFC Version 2 - The rewrite of xml2rfc in python, tagged with version numbers 2.x.y, have been unofficially available for some time, and it is now officially announced as available for use. This package is a complete rewrite of the xml2rfc command-line functionality in python. The command line tool is available from the main Python package repository, PyPi: http://pypi.python.org/pypi/xml2rfc or alternatively from: http://tools.ietf.org/tools/xml2rfc2/cli/ A number of alternative installation methods are available, described on the PyPi page for xml2rfc. There are some known issues with the current release, none of them major. These are listed in the issue tracker: http://tools.ietf.org/tools/xml2rfc/trac/report/9 Bug fixing is actively happening. If you find bugs which are not already listed in the tracker, please add them. Please help us find the bugs. They cannot be fixed if we do not know about them. Also, suggestions for improvements are welcome. New releases will be announced at the xml2rfc mail list. GUI Frontends - There are also GUI frontends available for Mac, Linux and Windows. These are not undergoing active bugfixing at the moment, but should overall be in good enough shape for production use if you prefer a GUI interface instead of command-line for your XML to draft/rfc operations. If you are going to install the GUI version, it is suggested that you first install the latest command-line version, and then the GUI front-end. The GUI components can be downloaded from here: http://tools.ietf.org/tools/xml2rfc2/gui/ Please note that in some cases, the GUI installers come with an embedded version of the base tool, and this version will not necessarily be the latest version available. If you download and install a later version of the command-line tool, the GUI component should use that if it comes before the embedded version in your PATH, which will normally be the case. Feedback I hope you'll find that the rewrite of xml2rfc works well for you; it will certainly be easier to extend and bugfix than the previous version. If you have feedback, regarding bugs or enhancement suggestions, please use the issue tracker at: http://tools.ietf.org/tools/xml2rfc/trac/newticket Best regards, Russ Housley IETF Chair Henrik Levkowetz IETF Tools Program Manager
