Re: sending strings data into IPfix stream
Hi Brian, Thanks a lot for your answer. Our IPFIX exporter is a bit specific, and we'd like to export periodically a list of hostname, ipaddress and related data (that are not available from the collector: owner, serial number, ...) It should be easier to send this list using IPFIX stream (and this deals with all security/filtering policy)... The transmission frequency of this list will be quite low. What is the right way to dothat ? Do I have to use IPFIX option templates to send such data, or not ? Thanks a lot. Cheers Thierry On 01/07/2013 11:28, Brian Trammell wrote: Hi, Thierry, Have a look in the IANA information element registry (http://www.iana.org/assignments/ipfix) to see if there are existing IEs for the information you want to export. Hostnames, I think, are not there -- in general, IPFIX exporters deal in addresses taken from observed packets and leave it up to the collector to do reverse resolution, due to (1) the amount of time DNS reverse lookups can take, blocking measurement activity on a (presumably) resource-constrained metering process, as well as (2) the ambiguity inherent within reverse lookups (due to e.g. misconfigured local and/or authoritative resolvers). In an environment where you have a good, internal database of hostnames (e.g. because the metering process is colocated with a DHCP server), this is more likely to be useful, though. If you'd like to export information _not_ in the IANA Information Element registry, you have two options; (1) defining new enterprise-specific IEs scoped by your Private Enterprise Number (see Section 3.2 and example A.2.2. in http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis) or (2) submitting a new Information Element definition for addition to the IANA registry (see http://tools.ietf.org/html/draft-ietf-ipfix-ie-doctors-07/ for guidelines on writing such a definition). Keep in mind, for strings, you'll almost certainly be dealing with variable-length IE export; see section 7 of http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis. Cheers, Brian On 1 Jul 2013, at 11:06 , DESCOMBES Thierry descom...@lpsc.in2p3.fr wrote: Hello, Not sure if this is the right list for this type of message ... I am developing an IPFIX exporter. It exports IP flows, and I'd like now to export some extra information (strings) about the machines on the LAN (the hostname of the machine, and others information ...) What is the right way to do that (IPFIX fields to use, template options or not ...) Thank you very much in advance. Regards T. Descombes
Invitation to request an IETF mentor
All, During IETF 87 in Berlin, we will be running a trial of the IETF Mentoring Program. The goal of the IETF Mentoring Program is to match people new to the IETF (people who have participated in three or fewer face-to-face meetings or anyone registering as a student) with experienced IETF mentors. As a mentoring participant, your mentor will personally introduce you to the IETF community, help you find your way around the IETF the meeting, explain things, and introduce you to other attendees you might like to meet. Basically, your mentor will be your personal buddy during the meeting week, and possibly afterwards. The IETF Mentoring Program was created to help new IETF participants to get up to speed rapidly and help them begin to contribute to the IETF quickly and easily. If you wish to participate in the IETF Mentoring Program, you can follow the sign-up procedures described in the program FAQ: https://www.ietf.org/resources/mentoring-program.html After you follow the sign-up procedure, we will then introduce you to each other by email, and invite you to meet up in person at the IETF Meet Greet event on Sunday afternoon in Berlin. From there on, you and your mentor decide on when and where to meet during the rest of the week and afterwards. You are of course free to withdraw from the program at any time and for any reason, no questions asked, should a need arise. But I sincerely believe the IETF Mentoring Program will be a great way for new participants to get introduced to the IETF by an experienced participant with matching interest. Regards, Jari Arkko IETF Chair
Re: Gen-ART LC review of draft-merkle-tls-brainpool-02
a new version addressing your review is on its way. Johannes Roni Even schrieb am 30.06.2013 08:44: 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. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-merkle-tls-brainpool-02 Reviewer: Roni Even Review Date:2013–6–30 IETF LC End Date: 2013-7–23 IESG Telechat date: Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: In section 1 you reference TLS 1.0 and 1.1 usage based on RFC 4492. What about TLS 1.2 usage specified in RFC5246 A.7 Nits/editorial comments: 1. In section 3 the registry name is EC Named Curve 2. In section 3 change “suitability” to “suitable” -- Mit freundlichen Grüßen, Dr. Johannes Merkle Principal Beratung, Elektronische Identitäten Public Sector secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 johannes.mer...@secunet.com www.secunet.com
Re: NOMCOM 2013-14 Volunteering - 3rd and Final Call for Volunteers
Michael O'Reirdan Attended 84, 85, 86 Comcast michael_oreir...@cable.comcast.com Use above address please 703-981-8895 or 856-433-0047 Sent from my iPhone On Jul 1, 2013, at 20:27, NomCom Chair 2013 nomcom-chair-2...@ietf.org wrote: Hi, everyone, We are short of our goal of 200 volunteers for the upcoming nomcom. Please do volunteer. Our publicly verifiable random algorithm has fully adequate entropy for a flood of volunteers - more names, more names, more names, more brains --- er, oops, not yet a zombie. The more volunteers we get, the better chance we have of choosing a random yet representative cross section of the IETF. Respond to this challenge and strengthen our statistical significance just by hitting Reply (but not Reply-All, please). Oh, first, please do check the official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The details of the selection and operation of the nomcom can be found in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, reply to this email and volunteer. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. Being a nomcom member will require some time commitment - there will be interviews with candidates at meetings, regularly scheduled conference calls to ensure progress, collection and review of requirements from the commitment, review of candidate questionnaires and of community feedback. A more detailed timetable for the nomcom tasks will appear soon. Please respond to this email before 23:59 EDT (UTC -4 hours) July 04, 2013. In the body include: 1. your Given Name as you enter it when you register for the IETF 2. your Family Name as you enter it when you register for the IETF 3. your current primary affilation (the information you enter into the Company field) 4. any/all email addresses you've used to register for IETF meetings 5. which email address you prefer 6. your phone number (for our use in confirming you if selected). On July 05, 2013 there will be an announcement of validated volunteers. If you haven't received an acknowledgement message from me to your email (indicating that you are or are not eligible) and you do not see your name in the July 05 list, contact me AS SOON AS POSSIBLE, on or before July 06. Looking forward to adding your name to the hat very soon, Allison Allison Mankin Nomcom Chair 2013-2014
RE: NOMCOM 2013-14 Volunteering - 3rd and Final Call for Volunteers
-Original Message- From: NomCom Chair 2013 nomcom-chair-2...@ietf.org Sent: 7/2/2013 8:27 AM To: IETF Announcement List ietf-annou...@ietf.org Cc: IETF Discuss ietf@ietf.org Subject: NOMCOM 2013-14 Volunteering - 3rd and Final Call for Volunteers Hi, everyone, We are short of our goal of 200 volunteers for the upcoming nomcom. Please do volunteer. Our publicly verifiable random algorithm has fully adequate entropy for a flood of volunteers - more names, more names, more names, more brains --- er, oops, not yet a zombie. The more volunteers we get, the better chance we have of choosing a random yet representative cross section of the IETF. Respond to this challenge and strengthen our statistical significance just by hitting Reply (but not Reply-All, please). Oh, first, please do check the official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The details of the selection and operation of the nomcom can be found in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, reply to this email and volunteer. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. Being a nomcom member will require some time commitment - there will be interviews with candidates at meetings, regularly scheduled conference calls to ensure progress, collection and review of requirements from the commitment, review of candidate questionnaires and of community feedback. A more detailed timetable for the nomcom tasks will appear soon. Please respond to this email before 23:59 EDT (UTC -4 hours) July 04, 2013. In the body include: 1. your Given Name as you enter it when you register for the IETF 2. your Family Name as you enter it when you register for the IETF 3. your current primary affilation (the information you enter into the Company field) 4. any/all email addresses you've used to register for IETF meetings 5. which email address you prefer 6. your phone number (for our use in confirming you if selected). On July 05, 2013 there will be an announcement of validated volunteers. If you haven't received an acknowledgement message from me to your email (indicating that you are or are not eligible) and you do not see your name in the July 05 list, contact me AS SOON AS POSSIBLE, on or before July 06. Looking forward to adding your name to the hat very soon, Allison Allison Mankin Nomcom Chair 2013-2014
RE: NOMCOM 2013-14 Volunteering - 3rd and Final Call for Volunteers
Allison, Just one or two observations... --On Tuesday, July 02, 2013 13:50 +0800 rex corpuz rex_corpuz2...@yahoo.com wrote: ... The more volunteers we get, the better chance we have of choosing a random yet representative cross section of the IETF. Respond to this challenge and strengthen our statistical significance... You must know that statement isn't true and I think it would actually help the IETF is we stopped kidding ourselves about it. From an almost-elementary statistical standpoint, increasing the sample proportion within a particular subset of a population has nothing to do with strengthening the statistical significance or representativeness of the total population. As other recent conversations have illustrated, that particular subset excludes those who don't attend lots of meetings f2f, it excludes those who are wiling to serve in positions the Nomcom appoints (and who believe that they have or could obtain the resources and support to do so), and it excludes anyone who lacks the time, support, and resources to make a major commitment to the Nomcom for an extended period. Some of the community would argue that those restrictions are A Good Thing and create a better Nomcom than we would have with a representative cross section of the IETF. Others would (and have) argued that those restrictions are both a problem in themselves and an important contributor to less diversity than they think desirable. But it is, IMO, impossible to argue that a group selected under those restrictions represents a statistically-valid sample of the community (or, in different language, a cross-section of that community). Selecting more people from that same pool doesn't increase the odds of getting a valid cross-section of the community, it just increases the odds of getting a valid cross-section of the pool. Again, I'm not arguing, at least in this note, that the pool from which you are soliciting volunteers isn't appropriate and/or the absolutely best we can do or even what we want whether it is or not. But we should stop pretending that it represents a statistically-valid cross-section of the community, much less that getting more volunteers has anything to do with that. best, john
Re: NOMCOM 2013-14 Volunteering - 3rd and Final Call for Volunteers
Hi, On Mon, Jul 1, 2013 at 7:40 PM, NomCom Chair 2013 nomcom-chair-2...@ietf.org wrote: Hi, everyone, We are short of our goal of 200 volunteers for the upcoming nomcom. Please do volunteer. Our publicly verifiable random algorithm has fully adequate entropy for a flood of volunteers - more names, more names, more names, more brains --- er, oops, not yet a zombie. The more volunteers we get, the better chance we have of choosing a random yet representative cross section of the IETF. Respond to this challenge and strengthen our statistical significance just by hitting Reply (but not Reply-All, please). The goal of 200 volunteers seems totally arbitrary to me. I understand that there is a wide range of opinions here, but I do not believe that the noncom is intended to be or should be a representative sample from those who just barely qualify as eligible to be volunteers under the current rules. Why is the quality of volunteers ignored in comparison with the quantity? No doubt many will strongly object to my use of quality but by that I mean understanding of the IETF culture and the IETF goal of benefiting the Internet community and a goodly amount of experience with IETF processes. For example, producing RFCs is clearly a large part of the IETF. Let's assume that, under current conditions, using only recent attendance as a qualifying criterion, we can get ~200 eligible volunteers but that adding the additional restriction that volunteers must have been a front page author/editor of an RFC issued within the past X years for some X would reduce the number of eligible volunteers to ~100. While I admit there is some volunteer pool size that would be too small (40? opinions will differ), my opinion is that 100 is more than enough and that such a change, to produce a pool of stronger and better qualified volunteers, would be an improvement. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Oh, first, please do check the official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The details of the selection and operation of the nomcom can be found in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, reply to this email and volunteer. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. Being a nomcom member will require some time commitment - there will be interviews with candidates at meetings, regularly scheduled conference calls to ensure progress, collection and review of requirements from the commitment, review of candidate questionnaires and of community feedback. A more detailed timetable for the nomcom tasks will appear soon. Please respond to this email before 23:59 EDT (UTC -4 hours) July 04, 2013. In the body include: 1. your Given Name as you enter it when you register for the IETF 2. your Family Name as you enter it when you register for the IETF 3. your current primary affilation (the information you enter into the Company field) 4. any/all email addresses you've used to register for IETF meetings 5. which email address you prefer 6. your phone number (for our use in confirming you if selected). On July 05, 2013 there will be an announcement of validated volunteers. If you haven't received an acknowledgement message from me to your email (indicating that you are or are not eligible) and you do not see your name in the July 05 list, contact me AS SOON AS POSSIBLE, on or before July 06. Looking forward to adding your name to the hat very soon, Allison Allison Mankin Nomcom Chair 2013-2014
RE: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
Do we have any statistics on how many appeals to the IESG fail and how many succeed? If I knew that 97% of appeals get rejected, I wouldn't even bother writing one... (On the other hand, that might simply be because 97% of the appeals are written by loons. Statistics can't tell us everything.) Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-announce-boun...@ietf.org [ietf-announce-boun...@ietf.org] On Behalf Of The IESG [i...@ietf.org] Sent: 02 July 2013 23:24 To: abdussalambar...@gmail.com Cc: ietf-annou...@ietf.org Subject: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats The IESG has reviewed the appeal of Abdussalam Baryun dated June 19, 2013 on the subject of inclusion in the acknowledgments section of draft-ietf-manet-nhdp-sec-threats: http://www.ietf.org/iesg/appeal/baryun-2013-06-19.txt This is a dispute about a matter in a working group. The same matter has previously been raised with the working group chairs and responsible Area Director, as specified in RFC 2026 Section 6.5.1. Writing acknowledgments sections is largely a matter of editorial discretion, where good sense and general attribution practices are the primary guidelines, although RFC 2026 Section 10.3.1 has some specific rules regarding acknowledgment of major contributors, copyright, and IPR. After reviewing the appeal, including the associated list discussion and draft revisions, the IESG concludes that the authors made a reasonable editorial choice that was well within their discretion and that none of the messages at issue fall under the required acknowledgment rules of RFC 2026 Section 10.3.1 and RFC 5378 Sections 5.6a and 1c. The IESG finds that the chairs and responsible AD handled complaints about the matter appropriately.
Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
Lloyd, On Jul 2, 2013, at 4:37 PM, l.w...@surrey.ac.uk wrote: Do we have any statistics on how many appeals to the IESG fail and how many succeed? Appeals are listed at: https://www.ietf.org/iesg/appeal.html Bob If I knew that 97% of appeals get rejected, I wouldn't even bother writing one... (On the other hand, that might simply be because 97% of the appeals are written by loons. Statistics can't tell us everything.) Lloyd Wood http://sat-net.com/L.Wood/
Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
If I knew that 97% of appeals get rejected, I wouldn't even bother writing one... i have never considered writng one. sour grapes make bad wine. randy
Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
http://www.ietf.org/iesg/appeal.html Every appeal ever submitted to the IESG and its response can be found here. On Jul 2, 2013, at 7:37 PM, l.w...@surrey.ac.uk wrote: Do we have any statistics on how many appeals to the IESG fail and how many succeed? If I knew that 97% of appeals get rejected, I wouldn't even bother writing one... (On the other hand, that might simply be because 97% of the appeals are written by loons. Statistics can't tell us everything.) Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-announce-boun...@ietf.org [ietf-announce-boun...@ietf.org] On Behalf Of The IESG [i...@ietf.org] Sent: 02 July 2013 23:24 To: abdussalambar...@gmail.com Cc: ietf-annou...@ietf.org Subject: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats The IESG has reviewed the appeal of Abdussalam Baryun dated June 19, 2013 on the subject of inclusion in the acknowledgments section of draft-ietf-manet-nhdp-sec-threats: http://www.ietf.org/iesg/appeal/baryun-2013-06-19.txt This is a dispute about a matter in a working group. The same matter has previously been raised with the working group chairs and responsible Area Director, as specified in RFC 2026 Section 6.5.1. Writing acknowledgments sections is largely a matter of editorial discretion, where good sense and general attribution practices are the primary guidelines, although RFC 2026 Section 10.3.1 has some specific rules regarding acknowledgment of major contributors, copyright, and IPR. After reviewing the appeal, including the associated list discussion and draft revisions, the IESG concludes that the authors made a reasonable editorial choice that was well within their discretion and that none of the messages at issue fall under the required acknowledgment rules of RFC 2026 Section 10.3.1 and RFC 5378 Sections 5.6a and 1c. The IESG finds that the chairs and responsible AD handled complaints about the matter appropriately.
submission tool not sending confirmations ?
I'm trying to submit and I-D, and I'm not getting the usual confirmation mail. My mail logs show nothing, no attempts, no failures. It worked the last time I tried it on Sunday. (Yes, I gave it a working address.) Anyone else seeing this? R's, John
Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
On 03/07/2013 14:23, Russ Housley wrote: http://www.ietf.org/iesg/appeal.html Every appeal ever submitted to the IESG and its response can be found here. ...since late 2002, that is. There were appeals earlier in history. The first one I recall reached the IAB in 1995, and had presumably already been rejected by the IESG. However, statistics since 2002 are probably enough. I'd say that rejected appeals quite often lead to clarification of procedures for the future; therefore they have value, even if it isn't immediately obvious. Brian
Re: [IETF] submission tool not sending confirmations ?
On Jul 2, 2013, at 10:43 PM, John Levine jo...@taugh.com wrote: I'm trying to submit and I-D, and I'm not getting the usual confirmation mail. My mail logs show nothing, no attempts, no failures. It worked the last time I tried it on Sunday. (Yes, I gave it a working address.) Anyone else seeing this? Happened to me recently -- I ended up opening a ticket.. Then I discovered the issue -- I was adding myself as a co-author on an existing draft -- in order to prevent shenanigans, an *existing* author has to submit it. Perhaps this is your issue? Anyway, Henrik / the tools folk are planning on adding a descriptive error message for the above. W R's, John -- I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is. --Terry Prachett
Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
On 7/2/2013 8:10 PM, Brian E Carpenter wrote: On 03/07/2013 14:23, Russ Housley wrote: http://www.ietf.org/iesg/appeal.html Every appeal ever submitted to the IESG and its response can be found here. ...since late 2002, that is. There were appeals earlier in history. The first one I recall reached the IAB in 1995, and had presumably already been rejected by the IESG. However, statistics since 2002 are probably enough. I believe I submitted the first appeal. It was to break a logjam with the the IETF's failure to sign an agreement with Sun, to get NFS brought into the IETF. I had been the cognizant AD when they approached the IETF, but the ball got dropped after that. So it wasn't so much 'rejected' by the IESG as it was cast in terms of IESG failure, although really no one was quite sure who needed to sign the contract with Sun and everyone was afraid of doing it. My reading of the appeal was that it succeeded, in that the agreement with Sun was signed shortly after that and the IETF took over the NFS specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
i have never considered writng one. sour grapes make bad wine. Errors do happen, for everyone and for all organisations. We do not treat appeals as sour grapes at the IESG, IAB or other places that receive them. We consider them an opportunity to review whether something was missed. At the same time, we do not intend to give special treatment to an argument just because it is labeled as an appeal. Sometimes legitimate differences of opinion are just that, and consensus was rough. Jari
Invitation to request an IETF mentor
All, During IETF 87 in Berlin, we will be running a trial of the IETF Mentoring Program. The goal of the IETF Mentoring Program is to match people new to the IETF (people who have participated in three or fewer face-to-face meetings or anyone registering as a student) with experienced IETF mentors. As a mentoring participant, your mentor will personally introduce you to the IETF community, help you find your way around the IETF the meeting, explain things, and introduce you to other attendees you might like to meet. Basically, your mentor will be your personal buddy during the meeting week, and possibly afterwards. The IETF Mentoring Program was created to help new IETF participants to get up to speed rapidly and help them begin to contribute to the IETF quickly and easily. If you wish to participate in the IETF Mentoring Program, you can follow the sign-up procedures described in the program FAQ: https://www.ietf.org/resources/mentoring-program.html After you follow the sign-up procedure, we will then introduce you to each other by email, and invite you to meet up in person at the IETF Meet Greet event on Sunday afternoon in Berlin. From there on, you and your mentor decide on when and where to meet during the rest of the week and afterwards. You are of course free to withdraw from the program at any time and for any reason, no questions asked, should a need arise. But I sincerely believe the IETF Mentoring Program will be a great way for new participants to get introduced to the IETF by an experienced participant with matching interest. Regards, Jari Arkko IETF Chair
Document Action: 'The Internet Numbers Registry System' to Informational RFC (draft-housley-rfc2050bis-02.txt)
The IESG has approved the following document: - 'The Internet Numbers Registry System' (draft-housley-rfc2050bis-02.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-housley-rfc2050bis/ Technical Summary This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. This document also provides information about the processes for further evolution of the Internet Numbers Registry System. This document replaces RFC 2050. Working Group Summary This is an individual document, but discussed extensively on the IETF list and with experts on the topic, including RIR and ICANN participants. Document Quality The document and the proper division of documentation between the IETF and other parts of the Internet community has been discussed extensively on the list. There was no unanimous agreement, but the document clearly has consensus behind it. Personnel The responsible AD is Jari Arkko.
IETF 87 - Meeting Information
87th IETF Meeting Berlin, Germany July 28-August 2, 2013 Platinum Sponsor: DENIC Gold Sponsors: Deutsche Telekom and EURid Bronze Sponsor: Dyn Meeting venue: InterContinental Berlin: http://www.berlin.intercontinental.com/ 1. Social Event 2. Sponsor Web page 3. Visas Letters of Invitation 4. Accommodations 5. Companion Program 6. Childcare Information 1. Social Event IETF87's social event sponsored by DENIC will be held at the famous German Museum of Technology (Deutsches Technikmuseum) in Berlin on Tuesday, 30 July 2013 from 19:00 to 24:00 Shuttles will be provided from/to the Intercontinental starting at 18:30. You may also walk to the museum (directions will be available soon). It will take you about 30 minutes. The cost is $30 USD per person. 475 tickets will be available, due to the expected demand, registration is limited to IETF87 attendees and one guest. For more information or to purchase tickets, please visit: http://www.ietf.org/meeting/87/social.html 2. Sponsor Web Page DENIC, the Platinum sponsor for IETF 87 has created a web page with information about Berlin, the URL is: http://www.ietf87.de/ 3. Visas Letters of Invitation: For information on Visiting Germany, please visit: http://www.auswaertiges-amt.de/EN/EinreiseUndAufenthalt/Visabestimmungen_node.html After you complete the registration process, you can request an electronic IETF letter of invitation as well. The registration system also allows for you to request a hard copy IETF letter of invitation. You may also request one at a later time by following the link provided in the confirmation email. Please note that the IETF Letter of Invitation may not be sufficient for obtaining a visa to enter Germany. 4. Accommodations Currently the venue hotel (InterContinental) and overflow hotel (Pullman) are both fully booked. The following hotels are near the InterContinental though we are not holding blocks at any of them. Pestana http://www.pestana.com/en/pestana-berlin-tiergarten-hotel/pages/home.aspx Distance from InterContinental: approximately 1-2 minute walk Hotel Berlin http://www.hotel-berlin.de/en/hotel-berlin.html Distance from InterContinental: approximately 5-7 minute walk Das Stue Hotel http://www.das-stue.com/en/ Distance from InterContinental: approximately 7-10 minute walk 5. Companion Program If you are traveling with a friend or family member over 18 years of age you can register them for the IETF Companion Program for only USD 25.00 Benefits include: - A special welcome reception for companions from 1630-1730 on Sunday, 28 July - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 28 July - A distinctive meeting badge that grants access to the venue (not to be used to attend working sessions) - Participation in a separate companion email list if you choose to help communicate and make plans with other IETF Companions. You can register your companion at any time via the IETF website or onsite at the meeting. To join the 87 companions mailing list only see: https://www.ietf.org/mailman/listinfo/87companions 6. Childcare Information If you are staying at the InterContinental or the Pullman and are interested in childcare services, please contact the concierge at the respective hotel to get more information or to make arrangements. You can email the InterContinental at berha.concie...@ihg.com and the Pullman at pull...@berlinconcierge.de Only 26 days until the Berlin IETF!
Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
The IESG has reviewed the appeal of Abdussalam Baryun dated June 19, 2013 on the subject of inclusion in the acknowledgments section of draft-ietf-manet-nhdp-sec-threats: http://www.ietf.org/iesg/appeal/baryun-2013-06-19.txt This is a dispute about a matter in a working group. The same matter has previously been raised with the working group chairs and responsible Area Director, as specified in RFC 2026 Section 6.5.1. Writing acknowledgments sections is largely a matter of editorial discretion, where good sense and general attribution practices are the primary guidelines, although RFC 2026 Section 10.3.1 has some specific rules regarding acknowledgment of major contributors, copyright, and IPR. After reviewing the appeal, including the associated list discussion and draft revisions, the IESG concludes that the authors made a reasonable editorial choice that was well within their discretion and that none of the messages at issue fall under the required acknowledgment rules of RFC 2026 Section 10.3.1 and RFC 5378 Sections 5.6a and 1c. The IESG finds that the chairs and responsible AD handled complaints about the matter appropriately.
Draft submission deadlines change
Please note that for IETF 87, there is only one deadline for draft submission: Monday 15th July. Previously, there had been two different deadlines, one for -00 and another one for other versions. The IESG has decided to experiment with just one deadline for now to simplify the set of deadlines and enable easier submission of new drafts. While we realise that the change comes near the deadline, we hope that you find the extra time useful. But please do note that working group chairs will continue to make smart decisions about what topics are worthwhile for discussing in a session in the upcoming meeting, and will also set their agendas in a timely manner and create deadlines for their working groups that must be adhered to. The earlier new drafts are submitted, the more time there is to talk about them on the mailing lists and consider them for the session agendas. This is particularly important for BoFs. Jari Arkko for the IESG
