Invitation to request an IETF mentor

[IETF Chair]

All,

If you are new to the IETF, we would like to invite you to participate in the 
new IETF Mentoring Program at the upcoming IETF 88 in Vancouver. 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 Vancouver. 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

IETF 88 Final Agenda

[IETF Agenda]

88th IETF Meeting - Vancouver, BC, Canada
November 3 - 8, 2013

The final agenda has been posted.

https://datatracker.ietf.org/meeting/88/agenda.html
https://datatracker.ietf.org/meeting/88/agenda.txt

While this is considered the final agenda for printing, changes may
be made to the agenda up until and during the meeting. Updates will be 
reflected on the web version of the agenda. 

Information about the 88th IETF meeting in Vancouver, BC, Canada can be found 
here: https://www.ietf.org/meeting/88/index.html

Thank you and see you in Vancouver!

Sincerely,

The IETF Secretariat

Nominations for the Internet Hall of Fame Awards

[IETF Chair]

I wanted to forward this message on behalf of the ISOC:


 
Nominations Now Open for the Prestigious Internet Hall of Fame Awards

Hong Kong to Host Third Annual Awards Ceremony
 
[Washington, D.C. and Geneva, Switzerland] - The Internet Society today 
announced that nominations for the 2014 Internet Hall of Fame are now open.  
Hong Kong has been selected as the site of the 2014 Internet Hall of Fame 
awards ceremony, to be held on 8 April 2014. 
 
Now in its third year, the Internet Hall of Fame honors and celebrates Internet 
visionaries, innovators, and leaders from around the world who have 
significantly contributed to the development and advancement of the open, 
global Internet. The Internet Hall of Fame reflects the living history of the 
Internet and the 2014 honorees will add to that history, available for all to 
experience through the Internet Hall of Fame, http://www.internethalloffame.org.
 
Organizations and individuals from around the world are invited to make 
nominations, and the form is available on the Internet Hall of Fame website, 
http://www.internethalloffame.org/nominations.  Nominees are considered for 
induction into one of three categories:
 
• Pioneers: individuals instrumental in the early design and development of the 
Internet
 
• Innovators:  individuals who made outstanding technological, commercial, or 
policy advances and helped expand the Internet’s reach
 
• Global Connectors: individuals who made major contributions to the growth, 
connectivity, and use of the Internet, either on a global scale or within a 
specific region or community
 
"The Internet would not have happened without the incredible work of many 
pioneers and visionaries," said Robert Hinden, Chair of the Internet Society 
Board of Trustees. “The Internet has made a significant difference in the lives 
of millions of people around the world; this would not have happened without 
the work and devotion of these people.  This is your opportunity to recognize 
them for their contributions that made the Internet a reality."
 
A vibrant city with a highly connected population, Hong Kong will host the 2014 
Internet Hall of Fame ceremony on 8 April.  The ceremony will be one of the 
highlights of the International IT Fest 2014 in Hong Kong, 7-20 April. 
Reflecting the dynamic, global nature of the Internet, the awards ceremony will 
move to a different region of the world each year.  Following Hong Kong, the 
ceremony will be held in Latin America in 2015, Africa in 2016, and North 
America in 2017.
 
“Hong Kong is consistently ranked among the world’s most dynamic cities and 
will provide the ideal setting for next year’s ceremony,” remarked Lynn St. 
Amour, President and CEO of the Internet Society. “The 2014 event promises to 
be as inspiring as the previous events, gathering some of the greatest thinkers 
and collaborators.”
 
More details on the historic contributions of the 2012 and 2013 Internet Hall 
of Fame inductees can be found at http://www.internethalloffame.org. You can 
follow the Internet Hall of Fame on Facebook and on Twitter at @Internet_HOF.

Montevideo statement

[IETF Chair]

I wanted to send a link to a statement that Russ and I signed as a part of a 
meeting that we held last week with the leaders of other Internet organisations.

http://www.internetsociety.org/news/montevideo-statement-future-internet-cooperation

Jari Arkko
IETF Chair

IETF 88 Preliminary Agenda

[IETF Agenda]

The IETF 88 Preliminary Agenda has been posted. The final agenda will be 
published on Friday, October 11th.
 
https://datatracker.ietf.org/meeting/88/agenda.html 
https://datatracker.ietf.org/meeting/88/agenda.txt 

We are still having some difficulty integrating the new agenda tool into the 
datatracker and as a result some portions of the meeting agenda -- beverage and 
snack breaks, plenaries --  are not yet showing up on the html version. This 
will hopefully be resolved very soon.
 
More information regarding IETF 88 in Vancouver, BC, Canada is located here: 
https://www.ietf.org/meeting/88/index.html 
 
IETF Secretariat 

Re: feedback & blog entry

[IETF Chair]

SM:

Thanks for the feedback.

> I read the article.  As a comment about the last paragraph, the metric being 
> used is not the best in my humble opinion.

You are referring to attendance and authoring RFCs? I agree, of course. I 
apologize for using a metric that is, at best, partial. My only defense is that 
it was what I had easily available :-( I do realise that real engagement from 
different types of organisations and people and areas of the world goes to far 
more fundamental issues than showing numbers of people. True involvement and 
effect is what counts. As we know, that does not necessarily correlate with any 
particular statistic...

>  Spencer Dawkins made an insightful comment which I would look into if I was 
> looking for a better metric.

Ok. Which comment are you referring to? I'm sorry, too much e-mail to know what 
you are referring to. I'd be interested in better metrics.

Jari

Vancouver meeting is coming up fast (reminder)

[IETF Chair]

This is a second reminder about an upcoming deadline:  If you are working on a 
new proposal for work at the IETF, it needs to be submitted by September 23rd, 
i.e., on Monday. If you have been talking about new topics that require a new 
meeting slot in Vancouver, hopefully you have already talked to your ADs about 
that. If not, this would be the last opportunity to do so :-)

And if you are reading this e-mail, this would also be a good opportunity to 
register for the meeting. Details below. I know this is going to be an exciting 
meeting, with many important topics on the agenda. Join us in Vancouver for the 
discussions!

Meeting web site and registration: http://www.ietf.org/meeting/88/index.html
Deadlines: http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88
BOF recommendations: http://tools.ietf.org/html/rfc5434
BOF procedures: http://www.ietf.org/wg/bof-procedures.html
Blog post about the upcoming meeting: 
http://www.ietf.org/blog/2013/09/vancouver/

Jari Arkko
IETF Chair

feedback & blog entry

[IETF Chair]

One of things that I feel is important for the chair to do is to talk to 
various IETF contributors - not just on this list! :-) - and try to understand 
what issues they have, either technical or otherwise. Here's a small overview 
report of my recent effort to talk to various participants and organisations in 
China.

   http://www.ietf.org/blog/2013/09/china/

These specific observations aside, I wanted to highlight that while I try to 
talk to many people, it will take a long time and ultimately be a very small 
subset of people. Hence if you have feedback on how the IETF is doing, what new 
things we should do, or what we should differently - contact me. I'd love to 
know - and I can also speak for the rest of the people in leadership positions 
- that ideas, experiences, and feedback is always appreciated. Let us know.

Jari Arkko
IETF Chair

Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe

[geoff . ietf]

Ralph,
 Will you be in Vancouver?  I'd like to get some time to talk about IPSO  
and also my new project for the White House - SmartUSA Challenge.  I plan to  
be there if I can get approval for "foreign travel".


Geoff Mulligan
Presidential Innovation Fellow
Cyber-Physical Systems
SmartUSA Challenge

IETF Mentor Program

[IETF Chair]

All,

   Based on the positive feedback we received after IETF 87, we are
going to continue the trial of an IETF mentoring program in Vancouver.
During this trial period, we would like to pair newcomers (people who
have attended 3 or fewer meetings or have registered as students) with
existing IETF participants.  The goal is to provide a resource for the
newcomer who can assist them with integrating into the IETF community.
Mentors and newcomers will be paired prior to IETF 88.

   What we need is for people to volunteer to be mentors. As a mentor,
we would ask that you be willing to assist your mentoring participant
before, during, and (hopefully) after IETF 88.  The actual level of
interaction will be driven by an agreement between the mentor and the
mentoring participant. Feedback from IETF 87 indicated that the average
amount of time a mentor spent on the program was approximately 4 hours
over the entire week.  Additionally, we would need a brief description
of your areas of expertise, technical interests, and conversational
languages.

   A description of the Mentor Program (including a FAQ describing
how to volunteer to be a mentor) is available:

http://www.ietf.org/resources/mentoring-program.html.

   Anyone interested in being a mentor should follow the sign-up
instructions contained in the above URL.  The more volunteers we have,
the stronger the program will be!

Regards,
IETF Chair

thoughts on pervasive monitoring

[IETF Chair]

Here are some thoughts on reports related to wide-spread monitoring and 
potential impacts on Internet standards, from me and Stephen Farrell:

  http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/

Comments appreciated, as always.

Jari & Stephen

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

[ned+ietf]

> On Fri, Sep 6, 2013 at 6:02 PM, Tim Bray  wrote:

> > How about a BCP saying conforming implementations of a wide-variety of
> > security-area RFCs MUST be open-source?
> >
> > *ducks*
> >

> And the user MUST compile them themselves from the sources?

> Nobody runs open source, (unless its an interpreted language). They run the
> compiled version and there is no infrastructure to check up on the
> compilation.

And don't forget:

   http://cm.bell-labs.com/who/ken/trust.html

Ned

Vancouver meeting is coming up fast

[IETF Chair]

It seems like yesterday when we were in Berlin, but I wanted to highlight that 
our Vancouver meeting is coming up soon. Sooner than usual, in fact, given the 
dates of the meetings this year.

I wanted to highlight an important deadline. If you are working on a new 
proposal for work at the IETF, it needs to be submitted by September 23rd, just 
three weeks away. If you have a new idea, this would be a good time to start 
talking about it to others, create lists, submit early drafts. And talk to your 
ADs. We at the IESG are happy to help you in the process. If you have not 
submitted a proposal earlier, you should probably read RFC 5434 
(http://tools.ietf.org/html/rfc5434) and BOF procedures 
(http://www.ietf.org/wg/bof-procedures.html).

For more information about the meeting, see my recent blog post here: 
http://www.ietf.org/blog/2013/09/vancouver/

Jari Arkko
IETF Chair

Huawei to Host IETF 88 in Vancouver!

[IETF Administrative Director]

Announce Huawei Host Vancouver

The IAOC is pleased to announce that Huawei will be the Host for IETF 88 in 
Vancouver.  

Huawei has been a long time supporter of the IETF through its participation and 
sponsorships 
at IETF meetings, but this is their first time as the Host of an IETF meeting.  
Congratulations, 
welcome and Thank You!

Registration is now open for IETF 88 at: http://www.ietf.org/meetings/88/

Many sponsorship opportunities are still available:  
http://iaoc.ietf.org/documents/IETF-Sponsorship-Opportunities-20132002.pdf

If interested contact Andrew Dvorshak, dvors...@isoc.org.

Once again, thank you Huawei!.  

See you in Vancouver in 71 days.

Ray
IAD

2014 Meeting Venues

IETF 89 London  Hilton MetropoleMarch 2-7
IETF 90 Toronto Fairmont Royal York July 20 - 25
IETF 91 HonoluluHilton Hawaiian Village November 9 - 14

New IETF Trust Chair

[IETF Administrative Director]

The IETF Trust Trustees are pleased to announce that Ole Jacobsen has been 
selected as the IETF Trust 
Chair.  Ole was selected following the resignation of Chris Griffiths as Chair, 
who assumed the 
chairmanship of the IAOC.   This will be Ole's second stint as Chair as he 
succeeded Marshall Eubanks 
when Marshall resigned from the IAOC.  

Congratulations Ole!  

Ray Pelletier
Trustee
IAD
http://trustee.ietf.org/

Re: Community Input Sought on SOWs for RFC Production Center and RFC Publisher

[Bert Wijnen (IETF)]

The point w.r.t. MIB module checking was that
during editing phase, even a small typo in a
double quote or some such would render the MIB
module invalid/non-compilable (i.e. invalid SYNTAX).

So if RPC does not touch the text at all, then there
is no need for them to check. But if they DO touch
it (even for pagination or some such) I would
recommend doing the check. For MIB modules that
should be pretty easy, simple and not cause much
extra work. Of course the MIB module needs to be
checked (SYNTAX that is) BEFORE it gets submitted
to AD/IESG even.

Bert
On 8/17/13 2:09 PM, Jeffrey Hutzelman wrote:

While I have no objection in principle to the RPC doing this check, it
seems likely that the burden of doing so would be significant and, at
least for IETF-stream documents, not worthwhile for the relatively small
gains realized.  This sort of check should be done before a document is
ever submitted to the IESG, let alone the RPC.

Community Input Sought on SOWs for RFC Production Center and RFC Publisher

[IETF Administrative Director]

The RFC Series Editor (RSE) is proposing changes to the Statements of Work 
(SOW) for the RFC 
Production Center (RPC) and the RFC Publisher.  The IAOC wants to receive 
community input prior to 
negotiating the proposed changes with the contractor.  Community input will be 
discussed with the RSE 
prior to negotiations and reviewed by the IAOC.

In forwarding the proposed Statements of Work the RSE said:  "The changes seek 
to make the SoWs 
more current [implementing RFC 6635] and specific, correcting the issues of 
"multiple masters" 
directing the RPC and Publisher, as well as preparing the way for a more 
significant revision to the SoWs
when the RFC Format changes are operationalized.  The SoWs have also been 
reviewed and supported 
by the RSOC [RFC Series Oversight Committee].  We consider the changes within 
the SoWs critical to the 
clear function of the RPC and Publisher, but suggest that the changes do not 
imply a significant change 
in responsibility for the RPC or Publisher."

The proposed SOWs, the current SOWs and a diff file for each can be found here 
under Community 
Review: 

We appreciate the community's input and look forward to hearing from you.  

Thanks

Ray Pelletier
IAD

Re: [87attendees] procedural question with remote participation

[Spencer Dawkins at IETF]

On Monday, August 5, 2013, Aaron Yi DING wrote:

> On 05/08/13 10:38, Scott Brim wrote:
>
>>
>> > Right, but Fuyou was talking about *spoken* English being more >
>> challenging than written English (if you can't *read* English fairly >
>> quickly, drafts and mailing lists are impenetrable, and you're done in >
>> the IETF). I'm told that it's easier for non-native English speakers to >
>> read slides than to parse spoken English for anyone who talks faster > than
>> I do.
>>
>>
>
> don't forget there are accents as well which make the parsing challenging
> even more challenging.
>

When I have talked to non-native English speakers at the IETF newcomers
tutorial, pointing out that many of the speakers they're working to
understand are also not not native English speakers often turns out to be
encouraging. ...

Re: stability of iana.org URLs

[ned+ietf]

> Hi,

> The link in RFC3315 is actually incorrect -- it should have been 
> http://www.iana.org/assignments/enterprise-numbers, without the file 
> extension, and there's an erratum about this. HTML was generally (if not 
> exclusively) reserved for files that needed to include links to registration 
> forms .

> As Barry said, we do intend to keep that same short 
> http://www.iana.org/assignments/example format working for every current 
> page, even the newly-created ones. We also prefer to see that format used in 
> documents, since we can't guarantee that the file extension used for the long 
> version won't change. (This information will be appearing on the website in 
> some form.)


> Also, if you find that a formerly-valid URL (like one that used to have an 
> .html exception) isn't redirecting to the current page, please report it to 
> i...@iana.org. A redirect should have been set up.

Excellent, thanks.

Ned

Re: stability of iana.org URLs

[ned+ietf]

> On 7/31/13 4:06 PM, Barry Leiba wrote:
> >> I just followed http://www.iana.org/assignments/enterprise-numbers.html
> >> From RFC3315 (DHCPv6)'s reference section.  Ten years later, the URL
> >> doesn't work.
> >>
> >> I know that things were reworked when we went to XML based storage, but
> >> I thought that the old URLs would at least have a 301 error on them.
> >>
> >> I discovered that dropping the .html gets me the right data at:
> >>   http://www.iana.org/assignments/enterprise-numbers
> >
> > Yes: that's the form that IANA would like you to use.  They changed
> > their registries from HTML to XML, and the URLs changed.

> That's true, but cool URIs don't change:

> http://www.w3.org/Provider/Style/URI.html

> IMHO it'd be easy enough to put general redirects in place.

+1. mod_rewrite is nobody's friend, but it can be tamed and put to good use.

Ned

Re: PS to IS question from plenary

[IETF Chair]

> Just to make sure we have good data, can we go back a few more years?
> Specifically, did we not previously have a restriction forbidding references
> FS->DS, and {FS,DS}->PS? RFC3967 was in Dec. 2004, but I thought that we
> had some other work more recently (2008?) that attempted to unjam things.
> 
> What I'm wondering is if the 20 actions prior to 6410 was an anomaly,
> and really the historical rate of upgrade is really lower.

A quick couple of seconds with mail search and grep says that in the four years 
preceding publication of RFC 6410, we made 28 actions. As noted earlier, 20 of 
those happened in the 22 months preceding the publication of RFC 6410. So in 
the 2+ years before that only 8 were produced.

I'd love to have a graph that plots DS/FS/IS progression per year, over time. 
But I don't have time to make that today. Unless someone else wants to...

Jari

PS to IS question from plenary

[IETF Chair]

Last night there was a question in the plenary about how many PS->IS 
transitions have occurred since RFC 6410 was published in October 2011. That 
RFC changed the three-step standards process to two steps. There was also a 
question of how this compared to previous times before that RFC got approved.

Looking at the timeframe from October 2011 to today (22 months), there have 
been four such protocol actions. These results are given by searching the IETF 
Announce mail archive:

0.1000  12159   07/16/2013  Protocol Action: 'Specification of the IP Flow 
Information eXport (IPFIX) Protocol for the Exchange of Flow Information' to 
Internet Standard   iesg-secret...@ietf.org 
0.1000  12036   06/04/2013  Protocol Action: DomainKeys Identified Mail 
(DKIM) Signatures to Internet Standard  iesg-secret...@ietf.org 
0.1000  11609   01/25/2013  Protocol Action: 'Extension Mechanisms for DNS 
(EDNS(0))' to Internet Standard (draft-ietf-dnsext-rfc2671bis-edns0-10.txt) 
 iesg-secret...@ietf.org 
0.1000  11510   01/03/2013  Protocol Action: 'Automated Updates of DNSSEC 
Trust Anchors' to Internet Standard (RFC 5011)iesg-secret...@ietf.org 

Prior to the publication of RFC 6410, in the preceding 22 months there were 
these 20 actions raising standards to either Draft Standard or Full Standard:

0.1000  957207/12/2011  Protocol Action: 'DomainKeys Identified Mail 
(DKIM) Signatures' to Draft Standard (draft-ietf-dkim-rfc4871bis-15.txt)   
iesg-secret...@ietf.org 
0.1000  942706/06/2011  Protocol Action: 'Transport Layer Security 
(TLS) Transport Model for the Simple Network Management Protocol (SNMP)' to 
Draft Standard   i...@ietf.org 
0.1000  940205/31/2011  Protocol Action: 'Transport Security Model for 
the Simple Network Management Protocol (SNMP)' to Draft Standard 
iesg-secret...@ietf.org 
0.1000  940105/31/2011  Protocol Action: 'Transport Subsystem for the 
Simple Network Management Protocol (SNMP)' to Draft Standard  
iesg-secret...@ietf.org 
0.1000  940005/31/2011  Protocol Action: 'Simple Network Management 
Protocol (SNMP) Context EngineID Discovery' to Draft Standard   
iesg-secret...@ietf.org 
0.1000  741001/25/2010  Protocol Action: 'ESMTP and LMTP Transmission 
Types Registration' to Draft Standard iesg-secret...@ietf.org 
0.1000  685808/17/2009  Protocol Action: 'Guidance on Interoperation 
and Implementation Reports for Advancement to Draft Standard' to BCP   
iesg-secret...@ietf.org 
0.1000  681907/29/2009  Protocol Action: 'Cryptographic Message Syntax 
(CMS)' to Draft Standard iesg-secret...@ietf.org 
0.1000  681607/29/2009  Protocol Action: 'TCP Congestion Control' to 
Draft Standard iesg-secret...@ietf.org 
0.1000  625603/05/2009  Protocol Action: 'RPC: Remote Procedure Call 
Protocol Specification Version 2' to Draft Standard
iesg-secret...@ietf.org 
0.1000  606901/14/2009  Protocol Action: 'Capabilities Advertisement 
with BGP-4' to Draft Standard  iesg-secret...@ietf.org 

0.1000  10108   12/05/2011  Protocol Action: 'The Multipart/Report Media 
Type for the Reporting of Mail System Administrative Messages' to Full Standard 
   iesg-secret...@ietf.org 
0.1000  978109/06/2011  Protocol Action: 'Message Submission for Mail' 
to Full Standard (draft-ietf-yam-rfc4409bis-03.txt)  
iesg-secret...@ietf.org 
2.3656  803406/21/2010  Protocol Action: 'Cryptographic Message Syntax 
(CMS)' to Full Standard  iesg-secret...@ietf.org 
2.4437  766803/15/2010  Protocol Action: 'SMTP Service Extension for 
8-bit MIME Transport' to Full Standard iesg-secret...@ietf.org 
2.2366  687608/19/2009  Protocol Action: 'Extensible Provisioning 
Protocol (EPP) Transport over TCP' to Full Standard   iesg-secret...@ietf.org 
2.4694  678407/20/2009  Protocol Action: 'Extensible Provisioning 
Protocol (EPP) Contact Mapping' to Full Standard  iesg-secret...@ietf.org 
2.2972  678307/20/2009  Protocol Action: 'Extensible Provisioning 
Protocol (EPP) Host Mapping' to Full Standard iesg-secret...@ietf.org 
2.1632  678207/20/2009  Protocol Action: 'Extensible Provisioning 
Protocol (EPP) Domain Name Mapping' to Full Standard  iesg-secret...@ietf.org 
2.5992  678107/20/2009  Protocol Action: 'Extensible Provisioning 
Protocol (EPP)' to Full Standard  iesg-secret...@ietf.org 

I should insert here the Standard disclaimer about possibly faulty search 
methodology or records, misunderstanding the question, or the hasty 
interpretation of results. In particular, the above search was not easy on ARO, 
involved manual steps, and I might have easily missed something. And I wish I 
had been able to do a database query instead. Feel free to repeat & verify my 
results...

Jari

moving more responsibility to working groups

[IETF Chair]

I would like to report an experiment that the IESG is starting. (There's also 
an associated blog article about this at 
http://www.ietf.org/blog/2013/07/the-role-of-working-groups/)

Internet Drafts sent for approval as RFCs are reviewed by individuals during 
the IETF Last Call, the Area Directors, IANA, as well as a number of volunteers 
from various directorates and review teams. The reviews from these teams has 
gained a significant role in ensuring that the IETF produces high-quality, 
understandable and implementable RFCs.

Yet, as discussed in http://www.ietf.org/blog/2013/05/balancing-the-process/ we 
have a general problem that quite a lot of the work around IETF documents 
happens at the end of the process. In particular, a number of the reviews 
during IETF last call point out issues that end up being raised by the IESG as 
comments. It is of course good that issues are caught, but raising them earlier 
would be better. And it would be better if the working groups - the intended 
focus point of work on a topic - would get to handle them, as opposed to 
raising these issues with the IESG. The has IESG discussed these issues and 
decided to experiment with three actions designed to move more work to the 
responsibility of the working groups:

(1) Perform some reviews that are now happening at IETF Last Call a bit 
earlier. This will put the working group in a bigger role in resolving 
cross-area and general issues.

(2) Invite document shepherds on IESG telechats when there's a document that is 
likely to require discussion. This will make it possible for the document 
shepherd to be directly involved in the discussions. 

(3) When a document up for approval has a number of issues, hand over the 
process back to the working group, as opposed to the IESG tracking the issues. 
Among other things, this will ensure that changes are discussed in an open 
working group list and agreed through consensus.

We are at the beginning of the experiment. We've done (2) and (3) a few times 
and plan to use it more from now on. We are discussing with the review teams to 
plan how (1) comes into effect. Building quality and cross-area review to the 
process earlier is of course a big effort. We are making a small change to 
current directorate review procedures. If successful, this will enable working 
groups to deal with issues before IETF Last Call and IESG review and empower 
the working groups to be in charge of the documents throughout their life 
cycle. We are also hoping that document quality will improve and number of 
issues discussed in the IESG will be lower.

From the point of view of the document authors and WG participants, all the 
above works through your working group chairs. They will be talking to you when 
documents come back to the working group. They or the document shepherds will 
be even more part of the IESG discussions and will keep the working groups 
updated on the progress of the documents. They will work with review teams to 
request earlier review. You will be seeing some reviews in the working group 
mailing lists. The current plan is to do these reviews after WGLC has 
completed, in parallel with ongoing reviews from your responsible ADs and 
chairs preparing the write-ups for the document to be submitted to the IETF 
Last Call.

While the number of reviews as such is not changed, some additional effort and 
care will however be required from the reviewers, directorate 
coordinators/secretaries, the working group chairs, and other participants. The 
experiment will show us whether this effort is reasonable and if there are any 
unexpected effects. The experiment is performed on a voluntary basis by each 
directorate, for a limited number of drafts at the beginning.

We will be collecting experiences so that in six months we can evaluate the 
experience. I would also like to thank the document shepherds, chairs, and 
review teams for participation in this effort!

Jari

Cisco Commits More Than US$2 Million to Support Open Internet Standards Development

[IETF Chair]

I would like to highlight an announcement that we sent today, detailing a 
multi-year hosting commitment that was first presented at IETF-86. I would like 
to thank Cisco for its significant contribution to the IETF. Thank you!

> Cisco Commits More Than US$2 Million to Support Open Internet Standards 
> Development
> 23 July 2013
> 
> IETF defines the standards for the global network that connects more than 2 
> billion people
> 
> [Washington, D.C. and Geneva, Switzerland] – 23 July 2013 – The Internet 
> Engineering Task Force (IETF), the Internet's premier standards organization, 
> and Cisco, the worldwide leader in information technology, today announced an 
> agreement to provide up to US$2.2 million in support for the IETF's work and 
> meetings through 2019.
> 
> The IETF brings together leading Internet engineers and technologists from 
> around the world to develop standards that form the foundation of the global 
> Internet and enable yet unimagined products and services. The IETF developed 
> the standards for capabilities such as internationalized domain names, email, 
> and instant messaging. Since its first meeting was held on January 16, 1986 
> in San Diego, California, the IETF has published more than 4500 documents 
> that describe standards for the fundamental technologies and widely used 
> services on today's global Internet. 
> The IETF is open to any interested individual and seeks broad participation 
> from across the globe. While the work of the IETF mainly takes place online 
> to reduce barriers to participation and to maximize contributions from around 
> the world, its meetings bring together over 1000 participants. Cisco's 
> commitment of more than US$2 million will provide support for both in-person 
> meetings and remote participation technology to enable even broader 
> participation in the IETF.
> 
> "The IETF is focused on developing timely, relevant, and technically 
> excellent open standards that provide a platform for the continued growth and 
> evolution of the global Internet," said Jari Arkko, Chair of the IETF. 
> "Unique among standards organizations, the IETF invites all interested 
> parties to participate, and makes every draft and final standards available 
> online without charge. Cisco's support will help to further expand 
> participation in the IETF by encouraging involvement in meetings in-person 
> and through collaboration technology built on IETF-developed standards."
> 
> The Internet Society is the administrative home of the IETF. With its 
> commitment, Cisco is recognized as the Internet Society’s newest Corporate 
> Partner. Corporate Partnership is a special program developed by the Internet 
> Society to recognize organizations that have provided support that warrants 
> the highest level of value and recognition, and a customized method for 
> mapping a longer-term strategy across multiple areas of support.
> 
> "We welcome Cisco's expanding commitment to the IETF as it reflects the 
> strategic importance that open Internet standards represent for continued 
> economic and social development around the world," said Lynn St. Amour, 
> President and CEO of the Internet Society.
> 
> About the Internet Engineering Task Force
> 
> The Internet Engineering Task Force (IETF) is the Internet’s premier 
> technical standards body. It gathers a large open international community of 
> network designers, engineers, operators, vendors, and researchers concerned 
> with the evolution of the Internet architecture and the smooth operation of 
> the Internet. The IETF seeks broad participation. The work of the IETF takes 
> place online, largely through email lists, reducing barriers to participation 
> and maximizing contributions from around the world. IETF Working Groups (WGs) 
> are organized by topic into several areas (e.g., routing, transport, 
> security, etc.).
> 
> For more information, see: http://www.ietf.org/
> 
> About the Internet Society
> 
> The Internet Society is the trusted independent source for Internet 
> information and thought leadership from around the world. With its principled 
> vision and substantial technological foundation, the Internet Society 
> promotes open dialogue on Internet policy, technology, and future development 
> among users, companies, governments, and other organizations. Working with 
> its members and Chapters around the world, the Internet Society enables the 
> continued evolution and growth of the Internet for everyone. For more 
> information, see: http://www.internetsociety.org
> 
> Contact:
> Greg Wood
> w...@isoc.org
> +1703-625-3917

Source: 
http://www.internetsociety.org/news/cisco-commits-more-us2-million-support-open-internet-standards-development

Jari Arkko
IETF Chair

Invitation to request an IETF mentor

[IETF Chair]

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

IETF Mentor Program

[IETF Secretariat]

Hi all,

   This is a reminder that, based on discussions during IETF 86, we are 
trialing an IETF mentoring program.  During this trial period, we would like to 
pair newcomers (people who have attended 3 or fewer meetings or have registered 
as students) with existing IETF participants.  The goal is to provide a 
resource for the newcomer who can assist them with integrating into the IETF 
community.  Mentors and newcomers will be paired prior to IETF 87.

   What we need is for people to volunteer to be mentors. As a mentor, we would 
ask that you be willing to assist your mentoring participant before, during, 
and (hopefully) after IETF 87.  The actual level of interaction will be driven 
by an agreement between the mentor and the mentoring participant. Additionally, 
we would need a brief description of your areas of expertise, technical 
interests, and conversational languages.

   A description of the Mentor Program (including a FAQ describing
how to volunteer to be a mentor) is available:

http://www.ietf.org/resources/mentoring-program.html.

   Anyone interested in being a mentor should follow the sign-up
instructions contained in the above URL.  The more volunteers we have,
the stronger the program will be!

Regards,
IETF Chair

Internet Draft Submission Cut-Off Today

[IETF Secretariat]

This is a reminder that the Internet Draft Submission cut-off is today, Monday, 
July 15, 2013. 

All submissions are due by UTC 24:00.

All drafts can be uploaded using the ID submission tool located here:
https://datatracker.ietf.org/submit/

The Internet-Draft cutoff dates as well as other significant dates for IETF 87 
can be found at: 
https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87

Thank you for your understanding and cooperation. If you have any  questions or 
concerns, then please send a message to internet-dra...@ietf.org.

ISOC CEO Search

[IETF Chair]

This announcement is of interest to the IETF community. If you have candidates 
or other feedback in mind, please work with Eva or Odgers Berndtson.

Jari Arkko
IETF Chair

Begin forwarded message:

> From: Eva Frölich 
> Subject: ISOC CEO Search
> Date: July 8, 2013 5:01:26 PM GMT+02:00
> To: jari.ar...@piuha.net
> Reply-To: e...@frobbit.se
> 
> Dear Jari,
> The Internet Society Board of Trustees has retained the Executive Search firm 
> of Odgers Berndtson to help us identify qualified candidates for the Internet 
> Society's President &   CEO position. As announced earlier this year, 
> Lynn St.Amour plans to step down as President & CEO in February 2014 at the 
> conclusion of her contract.
> 
> Founded in 1965, Odgers Berndtson provides an extensive range of high level 
> recruitment services and has more than 53 offices worldwide. We are extremely 
> confident that Odgers Berndtson offers the breadth of experience and 
> resources to help us find the absolute right candidate for the Internet 
> Society and the broader Internet community.
> 
> Working with Odgers Berndtson, the Board's CEO Search Committee has finalized 
> the position description, below. The position is being announced on the 
> homepage of the Internet Society website and in messages to all ISOC member 
> and stakeholder email lists and appropriate Internet community lists. 
> Additionally, in the next two weeks, Odgers Berndtson will place an 
> advertisement in The Economist magazine and publicize the opportunity through 
> its global network.
> 
> We will continue to keep you updated on a very regular basis on our 
> recruitment plans and the ongoing search. If you have any questions or 
> referrals for this position, please contact Odgers Berndtson: 
> ceo-i...@odgersberndtson.be
>  
> Eva Frölich
> Chair, ISOC Board of Trustees
> 
> ___
> 
> Chief Executive Officer
> The Internet Society (ISOC)
> 
> “The Internet is for everyone”
> 
> www.internetsociety.org
> 
> ISOC invites candidates for this exceptional role who will demonstrate top 
> level global service in the public and/or business sector, leadership in a 
> multi-stakeholder environment, and familiarity with civil regulatory and 
> business issues related to the Internet.
> 
> ISOC's mission is to promote the open development, evolution and use of the 
> Internet for the benefit of everyone in the world. Through its 65,000 
> individual members and supporters, 90 Chapters, and 145+ organizational 
> members, ISOC plays a unique global role in championing policies, promoting 
> open standards and implementing a plethora of actions to realize its mission. 
> ISOC is also the organizational home of the Internet Engineering Task Force, 
> the Internet’s premier technical standards body.
> 
> With offices in Virginia (USA) and Geneva (CH) and staff around the globe, 
> ISOC collaborates with a variety of partners from all societal and activity 
> sectors to ensure their engagement in the continued evolution of one of the 
> greatest tools of our time.
> 
> ISOC is a not-for-profit organization for whom transparency, consensus, 
> creative thinking and inclusiveness are key, and whose policy is developed by 
> the Board of Trustees with input from staff, members, chapters and the 
> broader community.
> 
> The CEO reports to, and is a member of, the Board of Trustees.
> 
> The Role
> • Lead the design, agreement and implementation of actions and programmes in 
> support of the strategic policy set with the Board of Trustees and Community
> • Provide inspired leadership and motivation to staff, members, and ISOC 
> partners around the world
> • Ensure effective long-term financial and organizational stewardship of 
> ISOC, upholding its unique mission and reputation
> • Deliver a significant personal impact as ISOC's primary representative in 
> the Internet space and beyond
> • Be unswerving in driving for the open development and use of the Internet, 
> by and for all
> 
> The Candidate
> • Track record of excellence in global leadership and coaching within major 
> organizations, at the intersection of public and private interests, with 
> strong relevance to the Internet
> • Familiarity and comfort with a multi-stakeholder universe, where consensus 
> prevails over hierarchy
> • Enthusiasm for and commitment to ISOC’s mission and operating values
> • An outstanding communicator and advocate, who engenders trust and who shows 
> integrity and courage
> • Strategic and integrative thinker, open to innovation, who sees the big and 
> the small picture, and is streetwise and politically astute
> • Genuinely multicultural, connects effectively wi

IETF 87 Final Agenda

[IETF Agenda]

87th IETF Meeting - Berlin, Germany
July 28 - August 2, 2013

The final agenda has been posted.

https://datatracker.ietf.org/meeting/87/agenda.html
https://datatracker.ietf.org/meeting/87/agenda.txt

While this is considered the final agenda for printing, changes may
be made to the agenda up until and during the meeting. Updates will be 
reflected on the web version of the agenda. 

Information about the 87th IETF meeting in Berlin, Germany can be found here: 
https://www.ietf.org/meeting/87/index.html

Thank you and see you in Berlin!

Sincerely,

The IETF Secretariat

IETF 87 Registration Suspended

[IETF Administrative Director]

Registration for IETF87 in Berlin has been suspended to consider the impact 
of a change in the VAT rules on Registration Fees.  We expect registration 
to open as soon as this matter has been clarified.

Ray
IETF Administrative Director

Invitation to request an IETF mentor

[IETF Chair]

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

IETF 87 Preliminary Agenda

[IETF Agenda]

The IETF 87 Preliminary Agenda has been posted.  The final agenda will be 
published on Friday, July 5th.  

https://datatracker.ietf.org/meeting/87/agenda.html
https://datatracker.ietf.org/meeting/87/agenda.txt

https://www.ietf.org/meeting/87/index.html

Thank you!

IETF Secretariat

Accessibility of IETF Remote Participation Services

[IETF Administrative Director]

From: iaoc-...@ietf.org
Subject:  Accessibility of IETF Remote Participation Services

For more than a decade, the IETF has tried to make it easier for remote 
attendees to participate in regular and interim face-to-face  meetings.   The 
current tools that the IETF has been using, as well as the state of remote 
participation services in the IETF was summarized by the IETF Chair in a 
message to the IETF-Announce list on 5 February 2013:
http://www.ietf.org/mail-archive/web/ietf/current/msg77020.html


Section 1 summarizes the current remote participation system: 

   The IETF's current remote participation system ("RPS") consists of a
   outbound real-time audio stream for each session carried to remote
   attendees over HTTP, textual multi-user chat carried over XMPP
   (commonly called Jabber), and posting of slides prior to the WG
   session so that they can be downloaded from the IETF web site.

   WebEx and Meetecho are experimentally supported, offering outbound
   real-time audio stream synchronized to the slides for the remote
   participant.  Meetecho displays the Jabber Room on the screen with
   slides, and it can also be used to replay the audio and slides from
   a recording.

As noted in Section 4 of the IETF Chair message, the IETF is currently 
soliciting 
suggestions for improvements in its RPS capabilities.   As part of that, the 
IETF 
would like to solicit feedback on the accessibility and usability of remote 
participation 
services by IETF participants with disabilities.  If you would like to comment 
on 
the accessibility and usability of IETF RPS services, please send email by July 
26, 2013 to 
iaoc-rps at ietf.org, Subject: RPS Accessibility, and CC: ietf@ietf.org. 

Bernard Aboba
Chair, IETF Remote Participation Services Committee 

IAOC Website Updated

[IETF Administrative Director]

One of the IAOC goals for 2013 was to update the IAOC website to improve
consistency, organization, linkage, and ease of use.

I am pleased to announce that the IAOC site has been updated and is available 
now for your use at <http://iaoc.ietf.org/>.

On the home page see a video of an Overview of the IAOC given by Chair Bob
Hinden in Orlando that includes a discussion of venue selection and IETF 
finances.  Also on the home page are recent announcements, as well as reports
from IANA, the RFC Editor, the IETF Chair, the NomCom Chair, and more.

The navigation bar makes it easy to find financial statements, minutes,
meeting sponsorship opportunities, and much more.

We hope you find this helpful, the IAOC as more transparent, and of course we
welcome your feedback.

Ray
IETF Administrative Director

PS:  Going to IETF 87 in Berlin?  The IAOC will be doing another overview
session there, Sunday July 28 at 3:00 PM.  Hope to see you there!

Re: Content-free Last Call comments

[ned+ietf]

Dave Cridland wrote:

> I strongly feel that positive statements have value, as they allow the
> community to gauge the level of review and consensus, and I suspect that
> human nature means that we get more reviews if people get to brag about it.

Agreed 100%.

But also consider the likely effect of calling certain comments "useless".

Discussions like this don't exactly fire me up with enthusiasm to expend 
additional time reviewing and commenting on documents not directly related to
what I do. And I rather doubt I'm alone in this.

Ned

Re: Language editing

[ned+ietf]

> On 08/05/2013 08:33, Ned Freed wrote:
> >> On 08/05/2013 03:28, John C Klensin wrote:
> >> ...
>  I'll also point out that this has diddley-squat to do with
>  formal verification processes. Again as Mark Anrdrews points
>  out, we deployed something with a restriction that
>  subsequently turned out to be unnecessary, and now we're stuck
>  with it. Indeed, had formal verification processes been
>  properly used, they would have flagged any attempt to change
>  this as breaking interoperability.
> >>> Also agreed.
> >
> >> To be clear, I'm no fan of formal verification either, but this
> >> *is* a case where the IETF's lapse in formality has come back to
> >> bite, and the Postel principle would have helped. Also, given the
> >> original subject of the thread, I don't see how language editing
> >> could have made any difference.
> >
> > Reread the notes about the history behind this in this thread. You haven't 
> > even
> > come close to making a case that formal verification of the standards would
> > have prevented this from happening.

> You are correct if only considering the mail standards. I suspect
> that a serious attempt at formal verification would have thrown
> up an inconsistency between the set of mail-related standards and
> the URI standard.

Which is relevant to the present situation... how exactly? And in any case, the
relevant URI standard incorporates the ABNF from RFC 2373, but doesn't
state whether or not it also inherits restrictions specified in prose
in that specification, which is where the restriction in RFC 2821
originated.

> However, I think the underlying problem here is
> that we ended up defining the text representation of IPv6 addresses
> in three different places, rather than having a single normative
> source. (ABNF in the mail standards, ABNF in the URI standard,
> and English in ipv6/6man standards.)

Except that wasn't the problem. The ABNF in the email standards is
consistent with what the other standards said when RFC 2821 was published. And
once that happened the die was cast as far as email usage was concerned. The
fact that the other standards later decided to loosen the rules in this
regard is what caused the inconsistency.

If you want to blame something, it has to be either the initial decision to
limit use of :: or the subsequent decision to remove that limit. And for
increased formalism to have helped it would have to have prevented one of those
from happening. I supose that's possible, but I certainly don't see it as
inevitable.

Ned

Re: Language editing

[ned+ietf]

> On 08/05/2013 03:28, John C Klensin wrote:
> ...
> >> I'll also point out that this has diddley-squat to do with
> >> formal verification processes. Again as Mark Anrdrews points
> >> out, we deployed something with a restriction that
> >> subsequently turned out to be unnecessary, and now we're stuck
> >> with it. Indeed, had formal verification processes been
> >> properly used, they would have flagged any attempt to change
> >> this as breaking interoperability.
> >
> > Also agreed.

> To be clear, I'm no fan of formal verification either, but this
> *is* a case where the IETF's lapse in formality has come back to
> bite, and the Postel principle would have helped. Also, given the
> original subject of the thread, I don't see how language editing
> could have made any difference.

Reread the notes about the history behind this in this thread. You haven't even
come close to making a case that formal verification of the standards would
have prevented this from happening. (Formal verification of implementation
compliance to the standards would of course have prevented Apple's client bug,
but that's a very different thing.)

You are, however, correct that this has nothing to do with specification
editing.

Ned

Re: Language editing

[ned+ietf]

> Maybe things have changed, but, if one actually believes the
> robustness principle, then, in the case Geoff cites, Exchange is
> simply non-conforming -- not because the spec prohibits
> rejecting on the basis of a fine distinction about IPv6 formats,
> but because doing so is unnecessary, inconsistent with the
> robustness principle, and, arguably, plain silly.

I'm afraid I'm going to have to disagree here. If you look at RFC 5321 and
are unaware of the history of how the text came about, it gives the definite
appearance of going out of its way to ban the use of :: to replace a single
0. A reasonable interpretation is therefore that such forms are disallowed
for a reason.

It's fine to be tolerant of stuff the relevant standard doesn't
allow but doesn't call out explicitly. But that's not the case here.

In any case, if you want to "fix" this, we could change RFC 5321 to accept this
form. But as Mark Andrews points out, you can't make it legal to send such
forms without breaking interoperability. I suppose we could make the change and
recycle at proposed, but that seems rather extreme to fix what is in fact a
nonissue.

I'll also point out that this has diddley-squat to do with formal verification
processes. Again as Mark Anrdrews points out, we deployed something with a
restriction that subsequently turned out to be unnecessary, and now we're stuck
with it. Indeed, had formal verification processes been properly used, they
would have flagged any attempt to change this as breaking interoperability.

Ned

Re: Language editing

[ned+ietf]

> Mark Andrews  wrote:
> >
> > Apples mail client is broken [IPv6:2001:df9::4015:1430:8367:2073:5d0]
> > is not legal according to both RFC 5321 and RFC 2821 which is all
> > that applies here.

>I was until today unaware how strong the feelings are on this
> "one-or-more" vs. "two-or-more" issue. I do not expect to change
> anybody's mind. :^(

>But I do object to calling that EHLO string "not legal".

It's syntactically illegal according to the ABNF in RFC 5321 itself, which
specifically states:

 IPv6-comp  = [IPv6-hex *5(":" IPv6-hex)] "::"
  [IPv6-hex *5(":" IPv6-hex)]
; The "::" represents at least 2 16-bit groups of
  ; zeros.  No more than 6 groups in addition to the
  ; "::" may be present.

>The 5321 reference names RFC 4291 as the source of address syntax
> (even if it gives BNF which says "two or more" if you delve deeply
> enough).

It may be the source, but the formal syntax specified in the document at hand
has to be the definitive one.

>RFC 4921 is clear about saying "one or more". The Errata posted
> against it claiming it should say "two or more" have been rejected.
> It is silly to argue under these conditions that Apple's EHLO string
> is "not legal".

No, what's silly is your argument that the ABNF in the actual specification of
how mail clients and servers are supposed to behave isn't the definitive
definition.

>BTW, RFC 5321 still contains the language about
> " if the verification fails, the server MUST NOT refuse to accept a
> " message on that basis.

And that language appears in the context of checking that the IP literal
in the HELO/EHLO actually corresponds to the IP address of the client. It
has nothing to do with syntactic validity.

> so IMHO enforcing any particular interpretation of what an IPv6
> address literal should look like is double-plus-ungood.

Then you should be arguing for a change in RFC 5321, because it is *very*
clear that this usage is not allowed.

Ned

Call for IESG narrative scribe volunteers

[IETF Chair]

The IESG narrative minutes are posted, whenever available, at 
http://www.ietf.org/iesg/minutes.html. Currently, Sue Hares and John Leslie are 
carrying the load of taking these notes. Previously, Richard Barnes also served 
in this role, but he has now other duties. We are very happy and grateful for 
the service the scribes are producing - big thank you! 

The IESG would like to recruit at least one more scribe. Other time commitments 
are not always allowing current volunteers to adequately cover all of the IESG 
meetings, and sharing the load would also be useful.

Volunteers should write to i...@ietf.org by May 10th.  We'll keep names 
confidential, unless people choose to volunteer in public.

The general guidelines are:

- at least one scribe attends the regular IESG telechats (17:30 - 20:00 CET / 
11:30 - 14:00 EST on alternate Thursdays).

- the scribe(s) will record narrative minutes of the discussions, but they will 
not take part in the discussions except to ask for clarifications.

- the narrative minutes will be published after review by the IESG.  The intent 
is to publish the narrative minutes within a month of the meeting.

- confidential items (principally personnel discussions) will not be reported 
in detail. The scribe will not take part in any sessions from which liaisons 
are excluded (e.g., nomination and appeal discussions).

The IESG scribes get a first hand opportunity to observe the IESG and their 
decision process, as well many interesting technical and other topics.

If we do not receive volunteers, then the narrative minutes service may not 
always be available.  We know how important this service is, however, for both 
the community and the IESG itself, so additional volunteers would be 
appreciated.

Jari Arkko
On behalf of the IESG

IAOC Announces Meeting Registration Gender Data Gathering Decision

[IETF Administrative Director]

On 11 April the IAOC announced that it was considering asking for 
gender information during the IETF meeting registration process 
starting with IETF 87, and asked for the community to provide feedback 
by 17 April as the IAOC planned to make a decision on 18 April.

The data is being gathered to benchmark and track gender participation 
at IETF meetings currently, over time, and to inform IETF diversity 
initiatives should any be undertaken.

The IAOC appreciates the feedback provided directly and the thoughtful 
discussion on the list.

After considering the feedback from the community and counsel, the 
IAOC approved the collection of gender data on the IETF meeting 
registration form.

A question about gender will be added to the registration form 
starting with the Berlin meeting (IETF 87).

Answering the gender question will of course be optional and the 
gender data will not be associated with individual registration 
records and only retained and reported in aggregate form.

Thanks again for your input.

Bob Hinden
Chair

videos and blog posts on home networking, buffer bloat

[IETF Chair]

The good folks at ISOC shot a number of videos during IETF-86 with experts on 
various topics. These videos are now available, take a look at the blog post 
John and I wrote:

http://www.ietf.org/blog/2013/04/bits-n-bytes-on-video/

The videos can also be accessed directly at:

http://www.youtube.com/watch?v=3SvhtLl8aTg (John Brzozowski on HIPnet)
http://www.youtube.com/watch?v=d-vwdD3Xtyg (Mark Townsley on HOMENET)
http://www.youtube.com/watch?v=NuHYOu4aAqg (Chris Griffiths and Dave Täht on 
buffer bloat)

There was also an earlier blog post that focused on the importance on running 
code, written together with Chris:

http://www.ietf.org/blog/2013/03/running-code-at-ietf-86-2/

All in all, I thought these demos and videos were very interesting. It is 
excellent that we are building implementations of the things that we specify in 
the working groups. And interestingly, Bits-n-Bytes has become a place to show 
some these results. Thanks to everyone who was involved, and the sponsors who 
made it possible! I also think it would be great to have even more of this in 
the coming IETFs. If you have ideas, let us know!

Jari Arkko

IAOC Overview remote participation

[Meetecho IETF support]

Dear all,

a virtual room has been reserved on the Meetecho system for the
IETF Administrative Oversight Committee session.

Access to the on-line session (including audio and video streams) will
be available (just a couple of minutes before session start time) at:

http://www.meetecho.com/ietf86/iaoc_overview

A tutorial of interactivity features of the tool can be found at:
http://ietf86.conf.meetecho.com

Cheers,
the Meetecho Team


This email has been automatically generated by The Meetecho Conferencing System 

Re: Beta testing of xml2rfc version 2

[IETF Chair]

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: Nomcom off in the wilderness: Transport AD

[Bert Wijnen (IETF)]

Dave, it seems to me that with your suggestion it feels as if
you (or we the community) want to redo some of the nomcom work?
I.e. you do not trust their evaluations?

They also have received (I presume) lots of feedback on the candidates
and probably did some interviews. We do not have that info. So tough
to challenge them based on only nominees statements.

Bert Wijnen

On 3/6/13 2:57 PM, Dave Crocker wrote:


On 3/6/2013 4:26 AM, Sam Hartman wrote:

However, there is something you can do. Take a quick moment to look at
the set of nominees and consider what you know about their
qualifications.

...
  > I'd also appreciate private feedback on how I could improve my approach

for raising this concern. I'm not at all sure that sending this message
was the best choice,

...


I don't have an opinion about the current candidates.  This note concerns Sam's 
effort:  I think it's thoughtful and reasonable,
within the bounds of the situation, IETF rules, and IETF culture.

And I have a further suggestion, which some other folk and I happened to have 
discussed privately some time ago and unrelated to the
specific TSV situation...

There's an option available that the candidates might want to consider, to 
facilitate the public review of candidate qualifications:

Candidates fill out a questionnaire for Nomcom review.  Roughly, it has two 
parts, with one that is available to Nomcom and the
appropriate Confirming Body, and a second that is withheld from the Confirming 
Body.

  Candidates could choose to circulate the first part publicly.

Nomcom is prohibited from making these documents public, but the candidates are 
not.

The long-standing argument against publicly issuing this information is that it 
might be seen as politicking, and the IETF Nomcom
process tries hard to avoid such opportunities.  The language in the forms is 
necessarily self-promoting.  After all, the candidate
is trying to explain why they think they are appropriate for a job.

However there is a difference between explaining why you think you are 
qualified, versus the hype of politicking.  One would hope
that IETF participants can tell that difference.  And it could be helpful for 
the community to see how a candidate sees themselves.

d/

Appointment of a Transport Area Director

[IETF Chair]

Dear IETF Community,

The 2012-2013 IETF nomination process has not yet filled the Transport
Area Director position despite several attempts to broaden the pool of
nominees.  The whole community conveys our most sincere gratitude to the
existing nominees for this position.  However, it seems that no candidate
has yet been found that meets the specific IESG-provided requirements and
is also able to make the necessary time commitment.

Requirements for IESG positions can be found at:
https://www.ietf.org/group/nomcom/2012/iesg-requirements

The TSVAREA session at IETF 86 will include a discussion on the
difficulty in locating a Transport Area Director candidate that meets
these position requirements and is also able to make the necessary time
commitment.  The outcome of the discussion cannot be predicted in
advance.  Since this discussion could lead to a change in the IESG
requirements, the IESG encourages the community to take part in this
discussion so that any changes are based on broad community input.

On behalf of the IESG,
 Russ Housley

Re: Internet Draft Final Submission Cut-Off Today

[ned+ietf]

On 02/27/2013 01:49 PM, Carsten Bormann wrote:
> On Feb 27, 2013, at 19:18, ned+i...@mauve.mrochek.com wrote:
>
>> routing around obstacles
> It turns out for most people the easiest route around is submitting in time.
>
> That is actually what counts here: how does the rule influence the behavior 
of people.
>
> Chair hat: WORKSFORME.  (And, if I could decide it, WONTFIX.)
+1.



As far as I can tell, the deadline actually serves the purpose of
getting people to focus on IETF and update their documents sufficiently
prior to the meeting, that it's reasonable to expect meeting
participants to read the drafts that they intend to discuss.   And I say
this as someone who, as an author, has often found the deadline to be
very inconvenient.


And your evidence for this is .. what exactly? Yes, the deadline makes the
drafts show up a bit sooner, but I rather suspect that the overwhelming
majority of people don't bother to do much reading in the inverval. I certainly
don't.

And given the ready available tools to tell the reader what's changed I don't
need to. In almost all cases for -nn where nn > 00 I can check what's changed
in a few minutes, and I can do it in the context of the actual work being done.

I don't really have any objection to a -00 cutoff, but the second cutoff
is nothing short of asinine.

In any case, I personally have basically stopped caring about the deadline and
I encourage others to do the same. If I make the deadline fine, if not I post
the update somewhere else, done.

Ned

Re: Internet Draft Final Submission Cut-Off Today

[ned+ietf]

> On Feb 26, 2013, at 5:38 PM, Pete Resnick  wrote:

> > But more seriously: I agree with you both. The deadline is silly.

> +1

+1

> The deadline originated because the secretariat needed time to post all of 
> those drafts (by hand) before the meeting.  The notion of an automated tool 
> that blocks submissions for two weeks before the meeting is just silly.

All the more so since it just leads people to use informal distribution
methods. I don't recall a case where a chair forbid the discussion of a draft
distributed this way.

I recall hearing something once about routing around obstacles... Pity we don't
internalize such principles fully.

Ned

Internet Draft Final Submission Cut-Off Today

[IETF Secretariat]

This is a reminder that the Internet Draft Final Submission (version -01
and up) cut-off is today, Monday, February 25, 2013. 

All Final Version (-01 and up) submissions are due by UTC 24:00.

All drafts can be uploaded using the ID submission tool located here:
https://datatracker.ietf.org/submit/

The Internet-Draft cutoff dates as well as other significant dates for IETF 86 
can be found at: 
https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86

Thank you for your understanding and cooperation. If you have any  questions or 
concerns, then please send a message to internet-dra...@ietf.org.

IETF chair's blog

[IETF Chair]

Jari has created a blog as an experiment to see if would be possible to
provide periodic status reports and other thoughts from the chair. Here's
the link:

http://www.ietf.org/blog/2013/02/chairs-blog/

One Week Left To Nominate YOUR Choice for the Internet Hall Of Fame!

[IETF Chair]

A reminder that the deadline for the Internet Hall of Fame nominations is 18 
February 2013. Individuals who have played a significant role in the 
conceptualization, building, and development of the Internet in any region or 
country are considered for induction.  Please take this opportunity to 
participate; your involvement will result in a highly diverse and 
well-qualified group of nominees!  

More details and the nomination form are available here: 
http://www.internethalloffame.org/nominations

Thanks for all you do for the Internet,
  Russ

Re: The RFC Acknowledgement

[ned+ietf]

> I try to include in the Acknowledgements section of any Internet
> Drafts I edit the names of anyone who comments on the draft if (1) the
> comment results in a change in the draft and (2) the commenter does
> not request that they be left out. If you comment on some draft and
> the draft is changed as a result and you want to be acknowledged and
> you are not added to the acknowledgements list, you should complain to
> the editor / author.

That's exactly the policy Nathaniel Borenstein and I agreed to use for MIME.
I've used it ever since for all the documents I have edited, and it seems to
have worked well. (And apologies to anyone whose name I have omitted under that
policy - if I did that it was entirely inadvertent.)

The only time I've ever had an acknowledgments section has been when an author
or contributor is deceased. This very unfortunate situation is quite delicate
and merits handling on a case-by-case basis; IMO no specific policy could
possibly be written to accomodate it.

Ned

Remote Participation Services

[IETF Chair]

Please see the attached report on the current status of remote participation in 
the IETF meeting.  Please notice at the end a call for potential experiments to 
explore ways that we can improve remote participation.

Russ Housley
IETF Chair

Bob Hinden
IAOC Chair


= = = = = = = = = 


Status of Remote Participation Services in the IETF Today

  Russ Housley
 1 February 2013

1.  Introduction

   For more than a decade, the IETF has tried to make it easier for 
   remote attendees to participate in regular and interim face-to-face
   meetings.  At the same time, some IETF Working Groups (WGs) have
   started to conduct virtual interim meetings.

   The IETF's current remote participation system ("RPS") consists of a
   outbound real-time audio stream for each session carried to remote
   attendees over HTTP, textual multi-user chat carried over XMPP
   (commonly called Jabber), and posting of slides prior to the WG
   session so that they can be downloaded from the IETF web site.

   WebEx and Meetecho are experimentally supported, offering outbound
   real-time audio stream synchronized to the slides for the remote
   participant.  Meetecho displays the Jabber Room on the screen with
   slides, and it can also be used to replay the audio and slides from
   a recording.
   
   Some WGs also employ ad-hoc tools, such as Skype for two-way audio and
   video conferencing and Etherpad for shared document editing.

2. Regular and Interim IETF Meetings

   Today, it is easy to remotely observe IETF sessions, but it is very
   difficult to participate in discussions.  However, several tools are
   used to accommodate remote participants.  To the greatest extent
   possible, these tools rely on IETF or other open standards, and they
   embrace both IPv4 and IPv6 without network address translation.

2.1. Audio

   Anyone can use a web browser to receive real-time audio of the IETF
   meeting sessions.  The URLs for the audio are announced in advance,
   and the audio recording becomes part of the session proceedings.

   It is quite difficult for a remote participant to have their voice
   heard in the session.  The WebEx and Meetecho systems can accommodate
   this with advance setup and testing.  However, allowing arbitrary
   remote participants to speak does not work well.  Connecting to the
   audio system in the meeting facility is quite problematic.  Further,
   a WG Chair would need sophisticated controls to maintain order if
   arbitrary remote participants were able to speak at any time.
   While WebEx and Meetecho provide some participation management
   features, but integration with in-room participation is needed.

2.2. Video

   In the 1990s as part of the multicast experiment, multicast video was
   made available, but this experiment has ended without evolving into a
   production service.

   As part of a separate experiment, some sessions use Meetecho to make
   video available to anyone with a web browser.  WG Chairs must request
   this coverage.  When Meetecho is used, the URLs are announced in
   advance, and the recording becomes part of the session proceedings.

2.3. Multi-User Chat

   Multi-user chat (MUC) is used both as a remote participation tool as
   well as a communication tool for local attendees, to raise and resolve
   issues without intruding on the presentation.  Each WG has a Jabber
   Room for Multi-User Chat, which employs the XMPP Standards Foundation
   (XSF) XEP-045 specification.  These Jabber Rooms can can be used at
   any time, not just during the IETF meetings.  During the session,
   remote participants that are listening to the audio are able to ask
   questions by typing them in the Jabber Room, and then someone in the
   physical room reads the question at the mic.  This is called
   MUC-to-Mic Relay.  The Jabber Room log becomes part of the session
   proceedings.

2.4. Slide Sharing

   Anyone can use a web browser to fetch the session slides.  WG Chairs
   are responsible for posting the slides prior to the session, and the
   slides (in PDF format) become part of the session proceedings.

   When Meetecho is used, the audio or video is presented in a
   synchronized fashion along with the jabber room and slides.

2.5. Remote Presenter

   When a presenter cannot attend, someone else usually presents their
   slides.  Some WG Chairs have tried remote presentations using WebEx
   and Meetecho.  Neither system is ideal, and the audio can include
   squeals and echos.  Both systems require advance setup and testing.

   The projection of the remote presenter's face as well as their slides
   seems to improve the experience for the people in the room, but we
   have only done this successfully a few times.  An extra projector and
   screen are needed for this to work well.

2.6.  Shared Text Document Editing

   In some sessions, there is an attempt to edit a text document with
   input from the local 

Re: Vestigial Features (was Re: CRLF (was: Re: A modest proposal))

[ned+ietf]

> On Jan 24, 2013, at 04:41, wor...@ariadne.com (Dale R. Worley) wrote:

> >> From: Carsten Bormann 
> >>
> >> I think in protocol evolution (as well as computer system evolution
> >> in general) we are missing triggers to get rid of vestigial
> >> features.
> >
> > That's quite true.  Let us start by rationalizing the spelling and
> > punctuation of written English (which is the coding system for *this
> > entire discussion*).  Once we've cleaned up that idiocy, we can start
> > in on SIP.

> I see I didn't make myself clear.
> I'm not suggesting we clean up vestigials in existing spec[ie]s, such as HTTP 
> or SIP.
> (We might even do that, see HTTPbis, but only very carefully.)

> My point was about the case when we clone new stuff off existing protocols.
> (SIP was cloned off HTTP which was cloned off SMTP which was cloned off FTP
> which at least has had strong kinship with Telnet, hence all these use NVT.)

Actually, in regards to NVT, there's something of a break in HTTP: text
material is *not* required to use CRLF as a line terminator. Any of LF, CR, or 
CRLF is permissible.

I really don't want to get into the history of this choice or for that matter
the results it has produced. Suffice it to say it has had some advantages and
some disadvantages.

> Staying in your analogy: when you design a new language based on English, 
> please do fix some of this stuff.
> (Maybe the analogy isn't that useful after all.)

> Actually, we haven't been that bad about this.

> E.g., we have been pretty good about getting rid of the madness of historic
> character coding by focusing on UTF-8 for new designs.

But a vital part of that choice is that it is backwards compatible with
US-ASCII.

> What I'm asking for: Apart from these big reformation projects, we also
> should occasionally fix little things.

Or not. How about instead of viewing these sorts past choices as things to be
fixed, we instead view them as what they were: Choices. And then decide, based
on the actual requirements of whatever we're doing, whether or not it makes
sense to make a change.

Sure, we can design some new format with LFs or CRs or maybe even line or page
separators as line breaks instead of CRLFs. And maybe that makes sense in some
cases. Or not: Such choices can have serious consequences if any degree of
backwards compatibility with exiting transfer services is desired. And constant
transcoding of stuff to make it work in various places is not necessarily a
winning approach.

> When "inventing" new stuff by drawing analogies off of old specs.

I really don't think unthinking copying from past specifications is the issue
here, your asssertions to the contrary notwithstanding.

Ned

Beta testing of xml2rfc version 2

[IETF Chair]

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

IETF Meeting Hotels for 2013

[IETF Administrative Director]

The IAOC has approved giving advance notice of the IETF Meeting hotel venues 
for 2013 as an experiment. 
Customarily such information has not been provided prior to registration 
opening for that meeting, however 
the IAOC is persuaded that it may be advantageous to attendees and wants to 
determine whether there are any 
unintended consequences.

IETF 88 March 10 - 15
Location: Orlando, FL
Venue:  Caribe Royale
Registration now open:  
<https://www.ietf.org/meeting/86/index.html>

IETF 87 July 28 - August 2
Location: Berlin, Germany
Venue:  InterContinental Berlin  
(Note: Reservations to open approximately 12 weeks before the 
meeting.)

IETF 88 November 3-8
Location:   Vancouver, BC, Canada
Venue:  Hyatt Regency Vancouver  
(Note: Reservations to open approximately 12 weeks before the 
meeting.)

Providing Venue information for 2013 is an experiment to determine impacts to 
participants, Secretariat, 
contracts, venue, and budget.  A decision will be made whether to continue to 
provide Venue information 
for 2014 after IETF 88.

Ray
IETF Administrative Director

Bits-N-Bites Sponsors Needed for Orlando

[IETF Chair]

The IAOC has decided to continue with the Bits-N-Bites event for meeting in 
2013.  We are seeking sponsors for the Bits-N-Bites event at IETF 86 in Orlando.

This is a fairly new community networking event.  The first Bits-N-Bites took 
place at IETF 84 in Vancouver.  The second Bits-N-Bites took place at IETF 85 
in Atlanta. People had a good time at both events, and the sponsor tables were 
busy.

Bits-N-Bites will bring together IETF participants, with exhibitors, product 
vendors, and service providers to share information, and showcase products and 
services in a social setting with food and drink.  Participants have an 
opportunity to network, speak with the sponsors, and enjoy the complimentary 
beer, wine, and hors d'oeuvres.  

Bits-N-Bites will be held Thursday evening, March 14th, from 7:00 - 9:00 PM at 
the meeting venue.

Sponsorship tables are still available!  For more information see 
<http://www.ietf.org/meeting/86/bits-n-bites.html> and contact Drew Dvorshak at 
dvors...@isoc.org.

 Russ Housley
 IETF Chair

 Bob Hinden
 IAOC Chair

Re: Last Call: (A Fast-Track way to RFC with Running Code) to Experimental RFC

[ned+ietf]

> Hi Ned,

> On 01/16/2013 03:40 AM, Ned Freed wrote:
> >> Actually I think you make a couple of great points that ought be
> >> mentioned in the draft about implementability. (No chance you'd
> >> have time to craft a paragraph? If not, I'll try pinch text from
> >> above:-) Now that you point it out like that, I'm irritated at
> >> myself for not having included it already! (It rings bells for me.)
> >
> > OK, I think the place for a new paragraph is just before the last
> > paragraph of section 2. How about something along the lines of:
> >
> >A complete and correct specification is not in and of itself a guarantee 
> > of
> >high quality implementations. What may seem like minor details can
> >increase implementation difficulty substantially, leading to 
> > implementations
> >that are fragile, contain unnecessary restrictions, or do not scale well.
> >Implementation experience has the potential to catch these problems 
> > before
> >the specification is finalized and becomes difficult to change.
> >
> > You might also want to change the final paragraph of the section a bit in
> > light of the addition; I'll leave that to you to work out.

> Did that, working copy at [1]. Lemme know if there're any changes
> that are needed.

It looks good to me. 

I also note that there's a reference to interoperability in the fourth
paragraph of section 1. Perhaps changing

   For example, a framework draft will not be a good candidate because
   implementations of such documents are not, of themselves,
   interoperable.

to something like

   For example, a framework draft will not be a good candidate because
   implementations of such documents are incomplete and therefore do
   not demonstrate either implementability or interoperability of an
   entire protocol.

would be in order.

Ned

Re: Last Call: (A Fast-Track way to RFC with Running Code) to Experimental RFC

[ned+ietf]

> Actually I think you make a couple of great points that ought be
> mentioned in the draft about implementability. (No chance you'd
> have time to craft a paragraph? If not, I'll try pinch text from
> above:-) Now that you point it out like that, I'm irritated at
> myself for not having included it already! (It rings bells for me.)

OK, I think the place for a new paragraph is just before the last
paragraph of section 2. How about something along the lines of:

   A complete and correct specification is not in and of itself a guarantee of
   high quality implementations. What may seem like minor details can
   increase implementation difficulty substantially, leading to implementations
   that are fragile, contain unnecessary restrictions, or do not scale well.
   Implementation experience has the potential to catch these problems before
   the specification is finalized and becomes difficult to change.

You might also want to change the final paragraph of the section a bit in
light of the addition; I'll leave that to you to work out.

Hope this helps.

Ned

Re: Last Call: (A Fast-Track way to RFC with Running Code) to Experimental RFC

[ned+ietf]

Martin Rex wrote:

> John Leslie wrote:
> >
> >I'm pretty darn uncomfortable _ever_ picking a fight with any
> > sitting AD, But I feel obligated to say this seems like a terrible
> > idea to me.
> >
> >As a background, I'm a long-time believer in "rough consensus" for
> > Proposed Standard and "running code" for advancement along the
> > standards track. I do not believe the two mix well.

> I don't have the resource to participate the discussion, but
> these statements capture my opinion pretty well.

I'm reluctantly going to have to join John and Martin, with one very important
difference: I think there is huge value in implementing specifications during
the process leading up to proposed standard. (As many people know, I do this
myself quite often for drafts I'm interested in.) I would rather phrase it as
having demonstrable interoperability for advancement, and ideally having
implementations done much earlier.

More specifically, where I part ways with this draft is in believing that very
early implementation helps find interoperability issues. I have not found that
to be the case. What it helps find are issues affecting implementability. In
the applications area at least, it's surprisingly easy to specify things that
look good on paper but turn out to suck when you try to code them. (My own sins
in this area are well known - RFC 2231 - and one of the reasons for that it is
one of the few RFCs I've written without implementing it first.)

Now, it's quite true that implementability problems can lead to
interoperability problems, like when different people take different shortcuts
in coding an unnecessarily problematic specification. But other outcomes are
possible, including fragility, unnecessary restrictions, and most especially
scalability problems.

Another problem with focusing on interoperability specifically as opposed to
overall implementability is that it makes it hard to argue that one or two
implementations provide that much benefit. In my experience having just one
implementation, even one done by a draft author, is surprisingly helpful in
cleaning up drafts.

I guess what I would like to see is for the draft to talk a little more about
finding implementation issues in general and a lot less about finding
interoperability issues specifically. I also think the draft goes a bit far in
the "carrots" it provides, but that may have more to do with my own experiences
in the applications area, where important comments have a way of only showing
up at the last second and where therefore the abbreviated process might be a
little dangerous to use.

Finally, I'm going to apologize for the tardiness of this comment, which really
should have been made sooner. I'm also going to apologize in advance for
probably not being able to fully participate in this discussion due to severe
time constraints.

Ned

Orlando IETF Codesprint

[IETF Chair]

Orlando IETF Codesprint

When:  Saturday, 9 March 2013, starting at 9:30 AM

Where: IETF Hotel

What:  A bunch of hackers get together to work on code for the
  IETF.  All code will become part of the open source IETF tools.

Who:   Hopefully you can help

Many of the results of previous codesprint activities are being used every day 
by the IETF community.  Shortly before the Paris meeting, we transitioned to a 
new database schema.  It makes many tasks much easier.  Please come to the 
codesprint and work to polish or improve existing tools, fix bugs, or make 
altogether new tools.  All efforts are appreciated and most welcome.

Steve Conte and Robert Sparks will be helping with advance planning.  Henrik 
Levkowetz will be coordinating the event in Orlando.  You can find more 
information here:

 http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF86Sprint

If you are able to participate, please sign up on the wiki at:

 http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF86SprintSignUp

Please support the tools development effort,
Russ

Re: I'm struggling with 2219 language again

[ned+ietf]

Dean, I am struggling constantly with 2119 as an AD, because if I take
the letter (and the spirit) of 2119 at face value, a lot of people are
doing this wrong. And 2119 is a BCP; it's one of our process documents.
So I'd like this to be cleared up as much as you. I think there is
active harm in the misuse we are seeing.



To Ned's points:



On 1/4/13 7:05 PM, ned+i...@mauve.mrochek.com wrote:
>> +1 to Brian and others saying upper case should be used sparingly, and
>> only where it really matters. If even then.
>>
> That's the entire point: The terms provide additional information as to
> what the authors consider the important points of compliance to be.
>



We will like end up in violent agreement, but I think the above
statement is incorrect. Nowhere in 2119 will you find the words
"conform" or conformance" or "comply" or "compliance", and I think
there's a reason for that: We long ago found that we did not really care
about conformance or compliance in the IETF. What we cared about was
interoperability of independently developed implementations, because
independently developing implementations that interoperate with other
folks is what makes the Internet robust. Importantly, we specifically
did not want to dictate how you write your code or tell you specific
algorithms to follow; that makes for everyone implementing the same
brittle code.


Meh. I know the IETF has a thing about these terms, and insofar as they  can
lead to the use of and/or overreliance on compliance testing rather than
interoperability testing, I agree with that sentiment.

OTOH, when it comes to actually, you know, writing code, this entire attitude
is IMNSHO more than a little precious. Maybe I've missed them, but in my
experience our avoidance of these terms has not resulted in the magical
creation of a widely available perfect reference implementation that allows me
to check interoperability. In fact in a lot of cases when I write code I have
absolutely nothing to test against - and this is often true even when I'm
implementing a standard that's been around for many years.

In such cases the use of compliance language - and yes, it is compliance
language, the avoidance of that term in RFC 2119 notwithstanding - is
essential. And for that matter it's still compliance language even if RFC 2119
terms are not used.

I'll also note that RFC 1123 most certainly does use the term "compliant" in
regards to capitalized terms it defines, and if nitpicking on this point
becames an issue I have zero problem replacing references to RFC 2119 with
references to RFC 1123 in the future.

All that said, I'll again point out that these terms are a double-edged sword,
and can be used to put the emphasis in the wrong place or even to specify
downright silly requirements. But that's a argument for better review of our
specifications, because saying "MUST do this stupid and couterproductive thing"
isn't fixed in any real sense by removing the capitalization.


The useful function of 2119 is that it allows us to document the
important *behavioral* requirements that I have to be aware of when I am
implementing (e.g., even though it's not obvious, my implementation MUST
send such-and-so or the other side is going to crash and burn; e.g.,
even though it's not obvious, the other side MAY send this-and-that, and
therefore my implementation needs to be able to handle it). And those
"even though it's not obvious" statements are important. It wastes my
time as an implementer to try to figure out what interoperability
requirement is meant by, "You MUST implement a variable to keep track of
such-and-so-state" (and yes, we see these in specs lately), and it makes
for everyone potentially implementing the same broken code.


Good point. Pointing out the nonobvious bits where things have to be done in a
certain way is probably the most important use-case for these terms.

Ned

Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]

[ned+ietf]

> On 07/01/2013 12:42, Stewart Bryant wrote:
> > Indeed an interesting additional question.
> >
> > My view is that you MUST NOT use RFC2119 language, unless you MUST use
> > it, for exactly that reason. What is important is "on the wire" (a term
> > that from experience is very difficult to define) inter-operation, and
> > implementers need to be free to achieve that though any means that suits
> > them.

> Agreed. Imagine the effect if the TCP standard had said that a particular
> congestion control algorithm was mandatory. Oh, wait...

> ... RFC 1122 section 4.2.2.15 says that a TCP MUST implement reference [TCP:7]
> which is Van's SIGCOMM'88 paper. So apparently any TCP that uses a more recent
> congestion control algorithm is non-conformant. Oh, wait...

> ... RFC 2001 is a proposed standard defining congestion control algorithms,
> but it doesn't update RFC 1122, and it uses lower-case. Oh, wait...

> RFC 2001 is obsoleted by RFC 2581 which obsoleted by RFC 5681. These both
> use RFC 2119 keywords, but they still don't update RFC 1122.

> This is such a rat's nest that it has a guidebook (RFC 5783, "Congestion
> Control in the RFC Series") and of course it's still an open research topic.

> Attempting to validate TCP implementations on the basis of conformance
> with RFC 2119 keywords would be, well, missing the point.

> I know this is an extreme case, but I believe it shows the futility of
> trying to be either legalistic or mathematical in this area.

Exactly. Looking for cases where the use/non-use of capitalized terms caused an
interoperability failure is a bit silly, because the use/non-use of such terms
doesn't carry that sort of weight.

What does happen is that implementation and therefore interoperability quality
can suffer when standards emphasize the wrong points of compliance. Things
work, but not as well as they should or could.

A fairly common case of this in application protocols is an emphasis on
low-level limits and restrictions while ignoring higher-level requirements. For
example, our email standards talk a fair bit about so-called "minimim maximums"
that in practice are rarely an issue, all the while failing to specify a
mandatory minimum set of semantics all agents must support. This has led to
lack of interoperable functionality in the long term.

Capitalized terms are both a blessing and a curse in this regard. They make it
easy to point out the really important stuff. But in doing so, they also
make it easy to put the emphasis in the wrong places.

tl;dr: Capitulized terms are a tool, and like any tool they can be misused.

Ned

Re: I'm struggling with 2219 language again

[ned+ietf]

> +1 to Brian and others saying upper case should be used sparingly, and
> only where it really matters. If even then.

That's the entire point: The terms provide additional information as to 
what the authors consider the important points of compliance to be.

> The notion (that some have) that MUST means you have to do something
> to be compliant and that a "must" (lower case) is optional is just
> nuts.

In some ways I find the use of SHOULD and SHOULD NOT be to be more useful
than MUST and MUST NOT. MUST and MUST NOT are usually obvious. SHOULD and
SHOULD NOT are things on the boundary, and how boundary cases are handled
is often what separated a good implementation from a mediocre or even poor
one.

> If the ARP spec were to say, "upon receipt of an ARP request, the
> recipient sends back an ARP response," does the lack of a MUST there
> mean the response is optional? Surely not. And if we make it only a
> SHOULD (e.g., to allow rate limiting of responses - a very reasonable
> thing to do), does lack of MUST now make the feature optional from a
> compliance/interoperability perspective?

> The idea that upper case language can be used to identify all the
> required parts of a specificition from a
> compliance/conformance/interoperability perspective is just
> wrong. This has never been the case (and would be exceeding painful to
> do), though (again) some people seem to think this would be useful and
> thus like lots of upper case language.

At most it provides the basis for a compliance checklist. But such checklists
never cover all the points involved in compliance. Heck, most specifications in
toto don't do that. Some amount of common sense is always required.

> Where you want to use MUST is where an implementation might be tempted
> to take a short cut -- to the detriment of the Internet -- but could
> do so without actually breaking interoperability. A good example is
> with retransmissions and exponential backoff. You can implement those
> incorrectly (or not at all), and still get "interoperability". I.e.,
> two machines can talk to each other. Maybe you don't get "good"
> intereoperability and maybe not great performance under some
> conditions, but you can still build an interoperabile implementation.

> IMO, too many specs seriously overuse/misuse 2119 language, to the
> detriment of readability, common sense, and reserving the terms to
> bring attention to those cases where it really is important to
> highlight an important point that may not be obvious to a casual
> reader/implementor.

Sadly true.

Ned

Acoustic couplers (was: Re: WCIT outcome?)

[ned+ietf]

On 1/2/2013 1:34 PM, ned+i...@mauve.mrochek.com wrote:
>> Now, your point about rewiring the jack may in fact be the reason for
>> _post-Carterphone_ acoustic couplers, but it was indeed at one time illegal
>> to connect directly (other than AT+T/WE supplied equipment).
>
> I'm skeptical about this last part. Prior to the advent of RJ-11 Bell System
> line cords used a large polarized four pin jack. After Carterphone all sorts 
of
> stuff started to appear to accomodate these, including extension cords,
> plug-jack passthroughs, and even "cube taps".



Acoustic couplers date back farther than the 4-pin plugs.


Of course. However, we're talking about post-Carterphone here. Carterphone was
1968, and I'm sure four pin plugs were in use by then.

Also keep in mind that AT&T fought the Carterphone decision for many years.
They got some state regulators to issue their own restrictions, but the FCC
nixed them all. Then they said a special protection device had to be used. The
FCC shot that down too. They also tried fees, but for that to work people had
to tell AT&T to charge them, which of course didn't happen.


...



> At one point there was something that said one phone in each home had to be
> directly wired without a plug. I don't know if this was a regulation, a phone
> company rule, or just a suggestion, but it also fell by the wayside after
> Carterphone.



It was usually enforced rigorously.  A given field tech might choose to
overlook a local mod, but they were authorized to remove such things.



So in my apartment, I installed a shutoff switch to the line, to be able
to sleep through attempts by my boss to call me in to work an additional
shift as a computer operator, at UCLA, around 1970 -- if I answered, I
was required to come in.  Remember there was no caller ID in those days.



The tech who needed to work on my phone service was very clear that he
was supposed to remove it.  After checking that I had handled the wiring
acceptably, he looked at me and said "so if I remove this, you'll
probably just reinstall it, right?"  He then left it in place.


A line mod was probably against the rules irrespective of Carterphone in those
days. But had you bought your own phone with a ringer switch and hooked that
up, that absolutely would have been covered by Carterphone. Of course you would
then have had to convince AT&T of that - see above.

Ned

Re: WCIT outcome?

[ned+ietf]

> > From: John Day 

> > I remember when a modem came with an 'acoustic coupler' because
> > connecting it directly to the phone line was illegal.
> > No, there was nothing illegal about it. The reason for acoustic
> > couplers was that the RJ-11 had been invented yet and it was a pain to
> > unscrew the box on the wall and re-wire every time you wanted to
> > connect.
> > ...
> > It may have been illegal in some countries but certainly not in the US.

> Huh? Remember the Carterphone decision?

Absolutely. Too bad the FCC didn't see fit to extend it to wireless.

> The one that overturned FCC Tariff Number 132: "No equipment, apparatus,
> circuit or device not furnished by the telephone company shall be attached to
> or connected with the facilities furnished by the telephone company, whether
> physically, by induction or otherwise."

> Now, your point about rewiring the jack may in fact be the reason for
> _post-Carterphone_ acoustic couplers, but it was indeed at one time illegal
> to connect directly (other than AT+T/WE supplied equipment).

I'm skeptical about this last part. Prior to the advent of RJ-11 Bell System
line cords used a large polarized four pin jack. After Carterphone all sorts of
stuff started to appear to accomodate these, including extension cords,
plug-jack passthroughs, and even "cube taps".

At one point there was something that said one phone in each home had to be
directly wired without a plug. I don't know if this was a regulation, a phone
company rule, or just a suggestion, but it also fell by the wayside after
Carterphone.

I certainly saw acoustic coupled equipment in use long after Carterphone, but
in my experience it was because of general intertia/unwillingness to do the
necessary engineering, not because of the lack of connectors.

Ned

30th Anniversary of Transition to TCP/IP

[IETF Chair]

Happy New Year.  It is already 2013 in some part of the world.

The ARPANET transitioned to TCP/IP on 1 January 1983.  That was 30 years ago, 
and it was a huge milestone in the journey toward the Internet as we know it.

You can see the transition plan.  Like so many other historic networking 
documents, it is an RFC.  See http://www.rfc-editor.org/rfc/rfc801.txt 

Happy New Year, 
  Russ

IETF 93 Venue Announced

[IETF Administrative Director]

The IAOC is pleased to announce Prague as the site for IETF 93 from July 19 - 
24 2-15.  
Prague was the site for IETF 68 in 2007 and IETF 80 in 2011.  

Happy holidays and best wishes for the new year.

Ray Pelletier
IETF Administrative Director

2013
  IETF 86   Orlando March 10-15 Host: 
Comcast and NBCUniversal
  IETF 87   Berlin  July 28 - August 2  
Sponsors to date:  DENIC, Eurid *
  IETF 88   Vancouver   November 3-8Host 
opportunity available *

* Contact Drew Dvorshak for Hosting and Sponsorship information  
dvors...@isoc.org

Orlando IETF Codesprint

[IETF Chair]

Vancouver IETF Codesprint

When:  Saturday, 9 March 2013, starting at 9:30 AM

Where: IETF Hotel

What:  A bunch of hackers get together to work on code for the
   IETF.  All code will become part of the open source IETF tools.

Who:   Hopefully you can help

Many of the results of previous codesprint activities are being used every day 
by the IETF community.  Shortly before the Paris meeting, we transitioned to a 
new database schema.  It makes many tasks much easier.  Please come to the 
codesprint and work to polish or improve existing tools, fix bugs, or make 
altogether new tools.  All efforts are appreciated and most welcome.

Steve Conte and Robert Sparks will be helping with advance planning.  Henrik 
Levkowetz will be coordinating the event in Vancouver.  You can find more 
information here:

  http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF86Sprint

If you are able to participate, please sign up on the wiki at:

  http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF86SprintSignUp

Please support the tools development effort,
 Russ

Re: request to make the "tools version" of the agenda the default

[Bert Wijnen (IETF)]

+1

On 11/29/12 7:11 PM, Wes Hardaker wrote:


So, the 'tools version' with all the wonderful spiffy links to helpful
things (the materials, the etherpad, the ...) and the spiffy
highlighting ability (Dark Red!  I love dark red!) has been very stable
and highly useful for quite a while now.  But the default link on the
web page still points to the less-useful HTML version (which has a link
at the top to get to the tools version).  I'd argue this is backwards at
this point, and the tools version is so much more useful (and just as
stable) as the plain-html version that it should be the default.  Can we
do that for March+?


[I know, we just *ended* a face-to-face meeting so why am I bringing up
face-to-face meeting topics so far before the next one?  That's unheard
of!  Call me crazy...]

Re: "IETF work is done on the mailing lists"

[ned+ietf]

> So here's my question:
> Does the community want us to push back on those situations?  Does the
> community believe that the real IETF work is done on the mailing
> lists, and not in the face-to-face meetings, to the extent that the
> community would want the IESG to refuse to publish documents whose
> process went as I've described above, on the basis that IETF process
> was not properly followed?

The issue isn't the lack of comments but any potential lack of opportunity to
comment. If the document was announced on the list, prefably including
ancillary about changes that have been made, and people chose not to comment
there, then that's fine. But if information about the document wasn't made
available - as is sometimes the case if the document isn't named under the WG - 
then that's a problem.

Ned

IETF Chair's Presentation at the Global Standards Symposium in Dubai

[IETF Chair]

Last Monday, I gave a short presentation on collaboration among standards 
development organizations at the Global Standards Symposium in Dubai, UAE.

The Internest Society has posted my slides and a transcript of my words.  These 
are available here: 
http://www.internetsociety.org/doc/remarks-global-standards-symposium-2012

I referenced the OpenStand principles in my comments.  These can be found at 
http:www.open-stand.org.

Leslie Daigle, the Chief Internet Technology Officer at the Internet Society, 
took this opportunity to write a brief post about OpenStand; it is available 
here: 
http://www.internetsociety.org/blog/2012/11/open-internet-standards-collaboration

Thanks,
  Russ

Round 2: Proposed IETF Meeting Dates 2018 - 2022

[IETF Administrative Director]

All


On 6 September the IAOC announced proposed meeting 
dates for 2018 - 2022 and requested community feedback 
before adopting.

Several points were raised.  

1.  IETF 110 21 - 26 March 2021

It was noted that those dates conflicted with a major 
religious holiday.  As this will impact travel the IAOC is recommending a
change to 7 - 12 March 2021.

2.  IETF 10617 - 22 November 2019

  It was commented that IETF 106 seemed a bit late in 
November and asked whether we are boxed in by other SDO
meetings, or was this by our own choice?

  Well, kind of boxed in, the week before is IEEE 802, and 
the week after is Thanksgiving in the US and a major travel 
holiday.

  The IAOC is recommending no change to these dates.

3.  2018, 2021, 2022 likely conflicts with ANSI T-10 with
November IETF meetings.

  The ANSI T-10 calendar has not been set.  November is a
short month with the Thanksgiving holiday and the IEEE 
802 meeting to avoid as well.  So, there is very limited 
flexibility to move the meeting.  The IAOC is recommending
no change for these meetings.

4.  Summer time meetings and school holidays. 

  We received comments about the overlap of meetings with
school holidays.  We schedule meetings March, July and
November, roughly 16 - 17 weeks apart.  The meetings can 
occur in July and occasionally include part of August.  It's
inevitable that a July meeting will overlap with someone's 
school holidays, whichever way the meeting is shifted during
this window.  Maintaining meetings three times a year 
doesn't seem to lend itself to a solution satisfactory to all.
 The IAOC is recommending no change to the summer 
schedules as proposed, unless there is another reason to do 
so.

All of the proposed dates for 2018 - 2022 are below.  

Comments appreciated to ietf@ietf.org by 4 December 2012.

Ray

2018
  IETF 101  18-23 March 2018
  IETF 102  22-27 July 2018
  IETF 103  4 - 9 November 2018

2019
  IETF 104  24 - 29 March 2019
  IETF 105  21 - 26 July 2019
  IETF 106  17 - 22 November 2019

2020
  IETF 107  22 - 27 March 2020
  IETF 108  26 - 31 July 2020
  IETF 109  15 - 20 November 2020

2021
  IETF 110  7 - 12 March 2021
  IETF 111  25 - 30 July 2021
  IETF 112  7 - 12 November 2021

2022
  IETF 113  20 - 25 March 2022
  IETF 114  24 - 29 July 2022
  IETF 115  6 - 11 November 2022

Re: Last Call: (LISP EID Block) to Informational RFC

[Bert Wijnen (IETF)]

Nice to try and keep it short.

But I was hoping for some more detail and explanation.
I have not followed the discussions (if any) in the WG
so I may be missing the reasons why you need this much
space. I would hope that the WG (if they have consensus
(which may be something different than "the WG felt"))
could elaborate or summarize the discussions that lead
to the conclusion that this amount of space is needed
and makes sense.

Pointers to the WG mlist discussions where the pros
and cons of various prefixes sizes are discussed or
summarize would also be welcome.

Bert

On 11/15/12 3:46 PM, Luigi Iannone wrote:

Hi Bert,

On 15 Nov. 2012, at 11:55 , Bert Wijnen (IETF)  wrote:

[snip]


So it is not asking just a /16 but also asking for reservation of a /12.

Pretty big space.

And in the list of reasons, I mainly read that it is "sufficiently large",
but not much about why it needs to be this big. Why would a smaller
allocation not be sufficient?



Well, to keep it short, the WG felt that /16 is the "right size", and that if 
the growth of LISP would be so important as to need a bigger space would be nice to have 
it contiguous (so implementations can just change the prefix length).

Luigi


Bert

Re: Last Call: (LISP EID Block) to Informational RFC

[Bert Wijnen (IETF)]

On Tue, Nov 13, 2012 at 3:45 PM, The IESG  wrote:
>
> The IESG has received a request from the Locator/ID Separation Protocol
> WG (lisp) to consider the following document:
> - 'LISP EID Block'
>as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf at ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be
> sent to iesg at ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>This is a direction to IANA to allocate a /16 IPv6 prefix for use
>with the Locator/ID Separation Protocol (LISP).  The prefix will be
>used for local intra-domain routing and global endpoint
>identification, by sites deploying LISP as EID (Endpoint IDentifier)
>addressing space.

Mmm... In section 5 it states:

   The working group reached consensus on an initial allocation of a /16
   prefix out of a /12 block which is asked to remain reserved for
   future use as EID space.  The reason of such consensus is manifold:

So it is not asking just a /16 but also asking for reservation of a /12.

Pretty big space.

And in the list of reasons, I mainly read that it is "sufficiently large",
but not much about why it needs to be this big. Why would a smaller
allocation not be sufficient?

Bert

RFP for IETF Meeting Network Services

[IETF Administrative Director]

The IETF Administrative Oversight Committee (IAOC), on behalf of the Internet 
Engineering Task Force
(IETF), announces this Request for Proposals for IETF Meeting Network Services. 
 The successful bidder 
will enter into a contract with the Internet Society.

The IAOC is seeking vendors to perform network services for  (IETF) meetings 
beginning in 2013 for a 
three-year (3) period, with an opportunity for two (2) one-year extensions. 
Generally, the services would
include: performing a pre-meeting site survey; developing a detailed network 
design; installing all equipment; 
conducting tests; and providing operations, systems management; user support 
functions during the meeting; 
and storage of IETF equipment. This is an indefinite delivery, indefinite 
quantity (IDIQ) contract.

The IETF conducts three, one-week meetings a year throughout the world.  
Attendance is in the range of 
1,100 to 1,300 per meeting.  The meetings are typically conducted in March, 
July and November.  Meeting 
venues include hotels with conference space (the preference), as well as 
standalone conference centers.  
Meeting space requirements are typically 40,000 square feet, comprised of 8 
meeting rooms holding between 
100 – 500 people; one Plenary room holding 1,000 people; a 120-seat terminal 
room; 8 offices; and a 
registration area.  

Generally, the wireless network must service all meeting rooms, terminal room, 
offices, the registration area, 
and public spaces.  Limited wired services are required in the meeting rooms 
and registration area, however,
the terminal room requires upwards of 150 drops.  Audio streaming and Jabber 
conference rooms are provided 
in addition to the wired and wireless network services for the meeting.

Connecting the IETF meeting to the Internet is done through a pair of redundant 
circuits. These circuits 
historically consist of a highspeed primary link and a lower speed backup link. 
 These links are generally
brought in specifically for the event, though existing venue links can 
sometimes be utilized for backup 
purposes.  

The IETF has equipment available to be used by the vendor, which is subject to 
change over time.  Vendor is 
to provide all other networking equipment including network servers, routers, 
switches, access points, and
cabling, and any equipment required by its staff in fulfilling the requirements 
of this contract.

Performance goals of the network are support of up to 2000 simultaneous 
connected devices with connectivity 
availability of at least 99% during the hours when session meetings are in 
progress, as well as the provision of 
Internet connectivity for headquarters hotel IETF guest rooms.

The RFP can be found at: <http://iaoc.ietf.org/rfpsrfis.html>

The anticipated schedule is as follows:

a. RFP Issued:  November 13, 2012.

b. Questions must be submitted by November 26, 2012 to 
t...@ietf-bids.org.
Responses will be posted by December 3, 2012 at 
< http://iaoc.ietf.org/rfpsrfis.html>

c. Proposal submitted by email due no later than 5 PM ET on December 
17, 2012.

d. Proposal Review Period:  December 17 - 31, 2012.

e. Notification of selection:  January 10, 2013

f. Contract Negotiation and Agreement:  January 14 - 28, 2013.

g. Contract Accepted:  February 14, 2013.

h. Contract Commencement: March 1, 2013.

Proposals must be received via email at t...@ietf-bids.org no later than 
December 17, 2012 5:00 P.M. ET.  All 
questions/inquiries must be submitted in writing and must be received no later 
than midnight, November 26, 
2012.  Responses to questions and inquiries shall be posted online at:  
<http://iaoc.ietf.org/rfpsrfis.html> by 
December 3, 2012. 

The point of contact regarding this RFP is the IETF Administrative Director, 
Ray Pelletier, i...@ietf.org.

Ray Pelletier

New on RIPE Labs: Global Effect of Hurricane Sandy as Seen in RIPE Atlas

[Bert Wijnen (IETF)]

Emile Aben, a colleague of mine did some more analysis.

In this new RIPE Labs article he looks at some of the effects Hurricane
Sandy had on the Internet data plane, as we can see them in traceroutes
done by RIPE Atlas:

https://labs.ripe.net/Members/emileaben/ripe-atlas-hurricane-sandy-global-effects

I figured that some of you might find this interesting.
Bert

Meetecho recording of the Plenary session

[Meetecho IETF support]

Dear all,

the full recording (synchronized video, audio, slides and jabber room)
of the Plenary session at IETF-85 is available.

You can watch it by accessing the following URL:
http://www.meetecho.com/ietf85/recordings

In case of problems with the playout, just drop an e-mail to 
ietf-t...@meetecho.com.


Cheers,
the Meetecho team

--
Meetecho s.r.l.
Web Conferencing and Collaboration Tools
www.meetecho.com

Re: Recall petition for Mr. Marshall Eubanks

[IETF Chair]

After a very brief consultation with the IESG, I have asked the Secretariat to 
block the verywarmc...@gmail.com email address from further posting to this 
mail list, and I have asked the Secretariat to delete the message from the mail 
list archive so that searches will not bring it up.

On behalf of the IESG,
Russ Housley

IESG Considering a Revision to NOTE WELL

[IETF Chair]

The IESG is considering a revision to the NOTE WELL text.  Please review and 
comment.

Russ



=== Proposed Revised NOTE WELL Text ===

Note Well

This summary is only meant to point you in the right direction, and
doesn't have all the nuances. The IETF's IPR Policy is set forth in
BCP 79; please read it carefully.

The brief summary:
  - By participating with the IETF, you agree to follow IETF processes.
  - If you are aware that a contribution of yours (something you write,
say, or discuss in any IETF context) is covered by patents or patent
applications, you need to disclose that fact.
  - You understand that meetings might be recorded, broadcast, and
   publicly archived.

For further information: Talk to a chair, ask an Area Director, or
review  BCP 9 (on the Internet Standards Process), BCP 25 (on the
Working Group processes), BCP 78 (on the IETF Trust), and BCP 79 (on
Intellectual Property Rights in the IETF).

Tao of the IETF

[IETF Chair]

As described in RFC 6722, the Tao of the IETF is published as a web page.  It 
can be found at http://www.ietf.org/tao.html.

In addition, five translations of the Tao are now available at 
http://www.ietf.org/tao-translations.html.  These languages represent the top 
five non-English languages spoken by people that attended recent IETF meetings.

I hope that these documents help new IETF attendees learn about the IETF 
culture.

Thanks,
Russ

Re: Recall petition for Mr. Marshall Eubanks

[Bert Wijnen (IETF)]

Thanks for extra info.

You can add me to the list who sign the request for recall.

Bert


--On Saturday, 03 November, 2012 11:36 -0400 Russ Housley
 wrote:


John:


I assume at this point the IAOC would like to pursue the
recall option?  If not, please be very clear about it to the
list as I haven't actually seen a request from the IAOC for
that process to proceed as far as I can tell.


Because I am personally very reluctant to see this handled by
recall, I want to ask a slightly different question:  Are the
people who met with Marshall convinced that he understood
that, if he did not resign, a recall was almost certain to be
initiated as our next step.  If the answer is "yes", he's made
his choice and I am ok with signing the petition.   If not, it
is possible that more discussion would be in order after the
petition process is complete.

I hope that, when Lynn accepts the petitions, another effort
(or several) will be made to et Marshall's attention -- it
presumably is not too late for him to resign until after the
relevant committee is appointed.


At the end of our visit, I believe that Marshall understood
that there were three possibilities:

1) Tell the community that he intends to resume participation;
2) Resign;
3) Do nothing, which would very likely result in a recall.

Russ

RIPE NCC ATLAS Measurements around Sandy

[Bert Wijnen (IETF)]

In case people are interested.

Some of you might be interested to know that we have
tried to see any impacts of Sandy via our ATLAS measurements.

Latest update of the graphs:
http://albatross.ripe.net/demo-area/sandy-2012/

Article that explains the graphs
https://labs.ripe.net/Members/emileaben/ripe-atlas-superstorm-sandy

Bert

IETF Trust Chair -- 25 Oct 2012

[IETF Administrative Director]

The Trustees of the IETF Trust took two actions today:
1.  Removed the current IETF Trust Chair
2.  Elected a new IETF Trust Chair

The Trustees passed the following resolution removing Marshal Eubanks as Trust 
Chair:

RESOLUTION
After consideration of the lack of participation by the Trust Chair in Trust 
matters for a 
period in excess of two months, and the failure of the Chair to respond to 
repeated 
attempts to contact him, the Trustees hereby remove Marshall Eubanks as the 
IETF 
Trust Chair effective 25 October at 10:15 AM EDT.

The resolution passed with seven of the nine votes, with two absentees, which 
included
Marshall.  

The Trustees took this action pursuant to the authority in the Trust 
Administrative 
Procedures (adopted 4-17-08) 
<http://trustee.ietf.org/docs/Trust_Procedures_2008.pdf>, which states:

The Chair serves at the pleasure of the Trustees and may be removed 
from that
position at any time by the Trustees.

Notice of the Trust meeting and its Agenda that specifically included Trust 
Chair 
Removal Vote was sent to all Trustees  on October 12, 2012.

Following this action the Trustees elected Ole Jacobsen as the Chair of the 
IETF Trust 
for the remainder of the term of Marshall Eubanks, that is, until March 13, 
2013.  
We appreciate Ole's volunteering for this position.

The Trustees thank Marshall for his contribution to the Trust as a Trustee and 
as an
 active, effective Chair from March 2009 through August 4, 2012.  His 
contribution 
will be missed.

Ray Pelletier
Trustee

Draft Network Services RFP for Community Comment

[IETF Administrative Director]

The IAOC is seeking community input on a proposed Network Services Request for 
Proposal.  The 
successful bidder(s) will have the opportunity to compete for delivering 
network services at IETF meetings.

The IAOC has decided that it wants to issue a Network Services RFP during the 
current one-year extension 
that VeriLan is working under to see whether it can identify other qualified 
providers, provide for a 
backup for VeriLan, and maybe introduce some competition and competitive prices 
for these services.

The RFP is located here under the Community Review section:
<http://iaoc.ietf.org/rfpsrfis.html>

Comments to the Tools Management Committee at t...@ietf-bids.org provided by 
5:00 PM EST 6 
November 2012 will be considered.

Proposed RFP Schedule

0.  Community review October 26 - November 6, 2012
1.  IAOC approves RFP for publication November 7, 2012
2. RFP Issued by email:  November 8, 2012.
3. Proposal submitted by email due no later than 5 PM EST
4. Proposal Review Period:  December 11 - 21, 2012.
5. Notification of selection:  January 3, 2013
6. Contract Negotiation and Agreement:  January 7 - 21, 2013.
7. Contract Accepted:  February 7, 2013.
8. Contract Commencement: March 1, 2013.

We appreciate your insight.  Thanks

Ray Pelletier
IETF Administrative Director

Re: I-D Action: draft-jaeggli-interim-observations-00.txt

[Meetecho IETF support]

Hi Joel,

nice work! Just a quick note about Section 3.2, with my Meetecho 
volunteer hat on :-)


In the mentioned section you state:


   Remote participation was supported by volunteers from meetecho using
   their own application.  Hotel okura wireless infrastrucuture was used
   to support the meeting.  An outage of the hotel network was observed
   during the opsec meeting with the result that remote participation
   would have been interupted for about 10 minutes had there been any to
   speak of.


As a matter of fact, our streaming laptops were not attached to the 
Okura Wifi network, but we were provided with wired connectivity per our 
request, and as such remote participants were not affected by the 
outage. This was done exactly to cope with issues like the one you 
mentioned, and this is the very reason why we always insist on asking 
for a wired connection for the streaming laptops.


Cheers,
Alessandro

Il 16/10/2012 17:39, joel jaeggli ha scritto:

On 10/15/12 2:53 PM, Adrian Farrel wrote:

ok, i am lost.  the draft is only an outline and has zero content?  is
it a quiz?

Treat it like that and see if you can give Joel the right answers.

01 is available. I imagine the SIDR experience was a bit different,
having been to another SIDR interim, I tried to call that out, but I
wasn't in the room.

http://tools.ietf.org/html/draft-jaeggli-interim-observations-01

For me: Did it make any difference to you that it was a LIM rather
than simply a
SIDR interim? Were logistics and resources worth the fee? Should we
hold future
LIMs, or do the scheduling and other issues mean that normal interims
are the
way forward?

cheers,
Adrian

Re: Gen-ART LC review of draft-leiba-5322upd-from-group-06

[ned+ietf]

> >> Channeling my inner Maslow, I see the present text as best, an additional
> >> sentence or two as next best, a sentence and a cite to the downgrade doc
> >> next in line, and including actual EAI examples in this doc as the worst
> >> choice.
> >
> > The problem I have with the current text is that it says 'what' motivated
> > the change, but not how it is useful for the intended class of uses.  The
> > reader is left entirely to guess.

> So, is it better to put in a sentence about representing non-ASCII
> text in the group name without including a replyable address?

> Or is it better to remove the notation about the EAI use case, and
> just say that it's stupid to have the restriction, so we're removing
> it?

If the alternative is to dig into EAI in any depth at all, the latter is far
preferable.

Ned

Re: Gen-ART LC review of draft-leiba-5322upd-from-group-06

[ned+ietf]

On 10/17/2012 2:32 PM, Ned Freed wrote:
> Channeling my inner Maslow, I see the present text as best, an additional
> sentence or two as next best, a sentence and a cite to the downgrade doc next
> in line, and including actual EAI examples in this doc as the worst choice.




The problem I have with the current text is that it says 'what'
motivated the change, but not how it is useful for the intended class of
uses.  The reader is left entirely to guess.



Self-actualization among the inadequately-informed invites fantasy more
than it invites utility.


That depends on both the utility and the desirability of repeating the existing
use case, doesn't it? The EAI use case of downgraded messages is one that only
exists because of a nasty confluence of restrictions and which we absolutely do
not want to see repeated in any other context.

If you really think this is important to explain why we're making this change
against the overall context of RFC 5322 - and I most certainly do not agree
that it is important to do so - then the best "use case" to add is the negative
one: The elimination of an unnecessary restriction that isn't followed in
practice.

I see no way to explain the narrow EAI use case in this context without either
dragging in a whole bunch of EAI that has no business being here or leaving
various things dangling. Either way the average reader looking at general
message usage isn't going to get it, and the more you try and waltz around this
the more likely you are to get exactly the outcome you fear: Someone is going
to see some sort of parallel with some problem they are trying to solve (some
sort of deliberate form of address obfuscation scheme immediately comes to
mind) and proceeds to make a mess of things.

Ned

P.S. It really would be best if this could wait until there was an update
to RFC 5322. But that's not how the timing has worked out, so this is the
best alternative available.

Re: Gen-ART LC review of draft-leiba-5322upd-from-group-06

[ned+ietf]

> --On Wednesday, October 17, 2012 12:00 -0700
> ned+i...@mauve.mrochek.com wrote:

> >> A single sentence summarizing what benefit is achieved with
> >> the change, along with a couple of usage examples, would go a
> >> long way towards showing how this update helps in practical
> >> ways.
> >
> > I could live with a single sentence, but I strongly object to
> > the inclusion
> > of examples, for the reasons I gave in my original response.

> Would a possible middle ground be to include a single
> well-crafted sentence with an informative citation of
> draft-ietf-eai-popimap-downgrade?  That document does contain
> examples and an explanation of that particular use case.

> I'd prefer to avoid that entirely for the same reasons Ned
> cites, but it would, IMO, be good to get on with this rather
> than quibbling for days or weeks.

Channeling my inner Maslow, I see the present text as best, an additional
sentence or two as next best, a sentence and a cite to the downgrade doc next
in line, and including actual EAI examples in this doc as the worst choice.

FWIW.

Ned

Re: Gen-ART LC review of draft-leiba-5322upd-from-group-06

[ned+ietf]

On 10/17/2012 10:49 AM, ned+i...@mauve.mrochek.com wrote:
>> Minor issues:
>
>> 1. It is not clear from the draft what the use case for using the group
>> construct is.  Section 3 talks about the issues with using the group
>> construct and recommend limited use, but this is the only information.
>
> The main driver for this work is to add support for EAI downgrade mechanisms,




Although the Intro text cites this, it doesn't explain how the change
will help.  Nor is this explained elsewhere in the document.



A single sentence summarizing what benefit is achieved with the change,
along with a couple of usage examples, would go a long way towards
showing how this update helps in practical ways.


I could live with a single sentence, but I strongly object to the inclusion
of examples, for the reasons I gave in my original response.

Ned

Re: Gen-ART LC review of draft-leiba-5322upd-from-group-06

[ned+ietf]

> Minor issues:

> 1.It is not clear from the draft what the use case for using the group
> construct is.  Section 3 talks about the issues with using the group
> construct and recommend limited use, but this is the only information.

The main driver for this work is to add support for EAI downgrade mechanisms,
although a good case can also be made that the present restrictions on group
usage are silly, limiting and unnecessary. (The silliness arises from the
observation that these restrictions enforced by most agents in the field.)

It is far from clear that it makes sense to clutter up this very clean and
crisp specification with a bunch of EAI use case scenarios, especially since
this is an update to RFC 5322 that could in theory be merged into the main
document in the future. A decision taken long ago for both RFC 5321 and 5322
was to keep them as free of entanglements with technology that's layered on top
of them (e.g., MIME, various SMTP extensions) as possible.

In any case, the decision of the group was not to do this.

> 2.Section 2.1 says "If the sender field uses group syntax, the group
> MUST NOT contains more than one mailbox."  Why use a group name for a single
> mailbox?

Why not? I'm sorry, but this question makes no sense. A group is a
characteristic attached to a collection of zero or more addresses. A group
containing a single member is every bit as valid as a construct as a group
containing 20 members. Or zero, for that matter.

Ned

Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols

[IETF Chair]

Based on the comments received from the IETF community and the IEEE RAC, the 
draft IESG statement has been updated.  Comments on the revised text are 
solicited.

On behalf of the IESG,
Russ


--- REVISED DRAFT IESG STATEMENT ---

SUBJECT: Ethertype Assignments for IETF Protocols

The IEEE Registration Authority (IEEE RA) assigns Ethertypes with
oversight from the IEEE Registration Authority Committee (IEEE RAC).
(See http://standards.ieee.org/develop/regauth/ethertype/.)  Some IETF
protocol specification make use of Ethertypes.  All Ethertype requests
are subject to review by a consultant to the IEEE RA followed by
IEEE RAC confirmation. 

Since Ethertypes are a fairly scarce resource, the IEEE RAC has let us
know that they will not assign a new Ethertype to a new IETF protocol
specification until the IESG has approved the protocol specification for
publication as an RFC.  In exceptional cases, the IEEE RA is willing to
consider "early allocation" of an Ethertype for an IETF protocol that is
still under development as long as the request comes from and has been
vetted by the IESG.

To let the IEEE RAC know that the IESG has approved the request for an
Ethernet assignment for an IETF protocol, all future requests for
assignment of Ethertypes for IETF protocols will be made by the IESG.

Note that playpen Ethertypes have been assigned in IEEE 802 [1] for use
during protocol development and experimentation.


[1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001).
IEEE standard for Local and Metropolitan Area Networks:
Overview and Architecture -- Amendment 1: Ethertypes for
Prototype and Vendor-Specific Protocol Development.

Bits-N-Bites Event in Atlanta

[IETF Chair]

We are pleased to announce Bits-N-Bites, the community networking experimental 
event that will take place for the second time at IETF 85 in Atlanta.  

This event will bring together IETF participants, with exhibitors, product 
vendors, and service providers to share information, and showcase products and 
services in a social setting with food and drink.

Bits-N-Bites will be held Thursday evening, November 8th, from 7:00 - 9:00 PM.

The Sponsors for this event include IPSO Alliance, Huawei, China Telecom, 
Tsinghua University, ICANN, and the Internet Society.  Sponsorship tables are 
still available! For more information see 
<https://www.ietf.org/meeting/85/bits-n-bites.html> and contact Drew Dvorshak 
at dvors...@isoc.org.

Please come, network, speak with the sponsors, and enjoy the complimentary 
beer, wine, and hors d'oeuvres.  

Russ Housley
IETF Chair

Bob Hinden
IAOC Chair

Revised Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[IETF Chair]

The IESG has updated the draft IESG Statement based on the many comments that 
have been received.  This revised text shows the linkage to RFC 2026 in a much 
more explicit manner, and it preserves the ability of the IESG to remove an 
Internet-Draft from the Public I-D Archive without a court order.  That said, 
the IESG firmly believes that the collection of I-Ds provide important 
historical records for the open and transparent operation of the IETF.  
Therefore, removal of a I-D from the  Public I-D Archive should teated as a 
significant event.  As a result, this statement requires IESG consensus is 
needed to remove an I-D from the Public I-D Archive.

Comments from the community are solicited on the revised draft IESG statement.

On behalf of the IESG,
Russ

--- DRAFT IESG STATEMENT ---

SUBJECT: Removal of an Internet-Draft from the IETF Web Site

SUBJECT: Removal of an Internet-Draft from the IETF Web Site

Internet-Drafts (I-Ds) are working documents of the IETF.  RFC 2026,
BCP 9, describes the purpose of I-Ds, and it also provides some policies
that govern the I-D Repository.  RFC 2026 says:

   During the development of a specification, draft versions of the
   document are made available for informal review and comment by
   placing them in the IETF's "Internet-Drafts" directory, which is
   replicated on a number of Internet hosts.  This makes an evolving
   working document readily available to a wide audience, facilitating
   the process of review and revision.

   An Internet-Draft that is published as an RFC, or that has remained
   unchanged in the Internet-Drafts directory for more than six months
   without being recommended by the IESG for publication as an RFC, is
   simply removed from the Internet-Drafts directory.  At any time, an
   Internet-Draft may be replaced by a more recent version of the same
   specification, restarting the six-month timeout period.

   An Internet-Draft is NOT a means of "publishing" a specification;
   specifications are published through the RFC mechanism described in
   the previous section.  Internet-Drafts have no formal status, and are
   subject to change or removal at any time.

I-Ds provide important historical records for the open and transparent
operation of the IETF.  It should be noted that individuals and groups,
including the IAB and IRTF Research Groups, have chosen to distribute
working documents as I-Ds.

I-Ds are stored in two places on the IETF web site.  First, current I-Ds
are stored in the I-D Repository.  Second, current and past I-Ds are
stored in a Public I-D Archive.

The policies associated with I-D Repository are discussed in RFC 2026,
and this IESG statement offers no additional policies regarding the
I-D Repository.

As RFC 2026 says, the entries in the I-D Repository are subject to
change or removal at any time; however, I-Ds generally remain in the
Public I-D Archive to support easy comparison with previous versions.
This availability facilitates review, comment, and revision.

An I-D will only be removed from the Public I-D Archive under unusual
circumstances with consensus of the IESG.  If you are aware of abuse or
misuse that warrants removal of an I-D from the Public I-D Archive,
please write to i...@ietf.org and explain the situation.  At its
discretion, the IESG may consult counsel or the IETF community before
taking any action on such requests.  If circumstances permit, a removed
I-D will be replaced with a tombstone file that describes the reason that
the I-D was removed from the Public I-D Archive.

When an I-D is removed from the Public I-D Archive, a copy will be kept
in a location accessible by the IETF Secretariat.  This private location
is described in RFC 2026 as follows:

  ... Internet-Drafts that
  have been removed (for any reason) from the Internet-Drafts
  directories shall be archived by the IETF Secretariat for the sole
  purpose of preserving an historical record of Internet standards
  activity and thus are not retrievable except in special
  circumstances.
  
The IESG, IAB, IAOC, or the Internet Society Board of Trustees can
request the IETF Secretariat to search this private location in
support of responses to appeals, responses to subpoenas, or other
handling of legal matters.  The IETF Secretariat is expected to make
the results of searches of the private location available as needed to
appropriately respond such matters.

Antitrust FAQ

[IETF Chair]

The IETF does not have a formal antitrust policy.  In fact, the ANTITRUST BOF 
concluded that a formal policy was not needed.  However, educational material 
is needed so that all IETF participants are aware of the the law.  The first 
draft of a FAQ to fill this need has been developed.  Please review the FAQ, 
and if you discover any issues raise them in response to this message.

http://www.ietf.org/playground/antitrust-faq.html

Thanks,
  Russ

Re: Obsoletes/Updates in the abstract (Was: Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07)

[ned+ietf]

> On Sep 21, 2012, at 11:14 AM, Pete Resnick  wrote:

> > [Changing the subject and removing GenArt and the document authors/chairs]
> >
> > On 9/21/12 10:52 AM, Glen Zorn wrote:
> >
>  -- The abstract should mention that this obsoletes 5721
> >>
> >> Why?  There is a statement in the header, 10 lines above the abstract, 
> >> that says "Obsoletes: 5721 (if approved)".
> >
> > The IESG put this into the nits check before my time. The Last Call and 
> > publication announcements normally contain only the abstract, not the 
> > metadata above, and I believe the thinking was that if you are a person who 
> > scans through those announcements, you probably would (and would want to) 
> > take notice of documents that purport to obsolete or update document that 
> > you recognize. We could probably change the tool to add the metadata to the 
> > announcements, but apparently quite a few people read "abstracting" 
> > services that grab the abstracts of newly published documents. Not much we 
> > can do for them.
> >
> > It's certainly useful to some folks. Necessary? (*Shrug*) Not enough wasted 
> > bits for me to care one way or the other.
> >

> As a Gen-ART reviewer, I called it out for exactly the reasons Pete mentions,
> and care about the same amount :-) But putting it there seems to hurt nothing,
> and maybe help just a little bit in some cases.

That's your opinion. Others, myself included, strongly disagree.

Ned

Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[IETF Chair]

The IESG has updated the draft IESG Statement based on the many comments that 
have been received.  It is clear that the community wants the IESG to be able 
to remove an Internet-Draft from the Public I-D Archive without a court order 
to do so.  That said, the IESG firmly believes that the collection of I-Ds 
provide important historical records for the open and transparent operation of 
the IETF.  Therefore, removal of a I-D from the  Public I-D Archive should 
teated as a significant event.

Comments from the community are solicited on the revised draft IESG statement.

On behalf of the IESG,
Russ

--- DRAFT IESG STATEMENT ---

SUBJECT: Removal of an Internet-Draft from the IETF Web Site

Internet-Drafts (I-Ds) are working documents of the IETF.  I-Ds provide
important historical records for the open and transparent operation of
the IETF.  Other individuals and groups, including the IAB and IRTF
Research Groups, have chosen to distribute working documents as I-Ds.

I-Ds are stored in two places on the IETF web site.  First, current I-Ds
are stored in the I-D Repository.  Second, current and past I-Ds are
stored in a Public I-D Archive.

While entries in the I-D Repository are subject to change or removal
at any time, I-Ds generally remain in the Public I-D Archive to support
easy comparison with previous versions.  This availability facilitates
review, comment, and revision.

An entry in the I-D Repository is removed as part of normal process
when it expires after six months, when it is replaced by a subsequent
I-D, or when it is replaced by the publication of an RFC.  In all
of these situations, the I-D remains in the Public I-D Archive.

An I-D will only be removed from the Public I-D Archive with consensus
of the IESG.  There are two situations when the IESG will take this
action.  First, to comply with a duly authorized court order.  Second,
to resolve some form of abuse.  If possible, a removed I-D will be
replaced with a tombstone file that describes the reason that the I-D
was removed from the Public I-D Archive.

When an I-D is removed from the Public I-D Archive, a copy will be kept
in a location accessible only by the IETF Leadership and the IETF
Secretariat.  This private location may be searched by the IETF
Leadership or the IETF Secretariat when responding to appeals,
responding to subpoenas, or otherwise handling to legal matters.

If you are aware of abuse that warrants removal of an I-D from the
Public I-D Archive, please write to the i...@ietf.org and explain the
situation.  At its discretion, the IESG may consult counsel or the IETF
community before taking any action on such requests.

Bits-N-Bites Sponsors Needed for Atlanta

[IETF Chair]

We are seeking sponsors for the Bits-N-Bites event at IETF 85 in Atlanta.

This is a fairly new community networking experimental event; the first 
Bits-N-Bites took place in at IETF 84 in Vancouver.  The Inaugural Sponsors in 
Vancouver were Juniper, Huawei, ICANN, IPSO Alliance, and the Internet Society. 
People had a good time, and the sponsor tables were busy throughout the event.

Bits-N-Bites will bring together IETF participants, with exhibitors, product 
vendors, and service providers to share information, and showcase products and 
services in a social setting with food and drink.  Participants have an 
opportunity to network, speak with the sponsors, and enjoy the complimentary 
beer, wine, and hors d'oeuvres.  

Bits-N-Bites will be held Thursday evening, November 8th, from 7:00 - 9:00 PM 
at the meeting hotel.

Sponsorship tables are still available!  For more information see 
<http://www.ietf.org/meeting/85/bits-n-bites.html> and contact Drew Dvorshak at 
dvors...@isoc.org.

  Russ Housley
  IETF Chair

  Bob Hinden
  IAOC Chair

Re: Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

[ned+ietf]

On 09/19/2012 04:24 AM, Ben Campbell wrote:
> 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-ietf-eai-simpledowngrade-07
> Reviewer: Ben Campbell
> Review Date: 2012-09-18
> IETF LC End Date: 2012-09-20
>
> Summary: This draft is mostly on the right track, but has open issues
>
> Major issues:
>
> -- I'm concerned about the security considerations related to having a
> mail drop modify a potentially signed message.
...



Hm, sounds like a misunderstanding. Did you understand that the
modification happens in RAM, and that the message stored unmodified and
has the valid signature? If not I suppose extra verbiage is needed.


I think this is already pretty clear: The texts says things like "present"
and "serve". It takes a pretty deliberate misreading to miss those words.

Moreover, stating that this "happens only in RAM" may not be correct. A server
could choose to store a downgraded version so it doesn't have to be rerendered,
for example. The point is that version isn't going to be presented to a client
that supports EAI, not that it only happens in RAM.


The signature issue has been discussed. The answer is more or less: The
WG expects EAI users to use EAI-capable software, and to accept partial
failure when using software that cannot be updated.



This entire draft is draft is about damage limitation when an EAI user
uses EAI-ignorant software (e.g. your phone, if you do your main mail
handling on a computer but occasionally look using the phone). That
there will be damage is expected and accepted. IMO it's unavoidable.


I think that's more a matter of fact, not opinion. If your software is
incapable of presenting something, it's incapable of presenting something.
The only question is whether you get a downgraded version the software is
capable of handling or nothing. EAI allows that choice to be made by
the implementation or operationally.


> Minor Issues:
>
> -- It's not clear to me why this is standards track rather than informational.



I don't remember. Perhaps because it needs to update 3501.



> -- section 3, 2nd paragraph:
>
> Are there any limits on how much the size can differ from the actual 
delivered message? Can it be larger? Smaller? It's worth commenting on whether 
this could cause errors in the client. (e.g. Improper memory allocation)



An input message can be constructed to make the difference arbitrarily
large. For instance, just add an attachment with a suggested filename of
a million unicode snowmen, and the surrogate message will be several
megabyte smaller than the original. Or if you know that the target
server uses a long surrogate address format, add a million short Cc
addresses and the surrogate will be blown up by a million long CC addresses.



I doubt that this is exploitable. You can confuse or irritate the user
by making the client say "downloading 1.2MB" when the size before
download was reported as 42kb, that's all. I wish all my problems were
as small.


If it's exploitable it almost certainly is what I refer to as the "tiny twig on
the attack tree". That is, if there's a size-related issue there are going to
be much easier ways to exploit it than this.

I suppose some folks may believe that describing these sorts of twigs is 
valuable. I disgree and believe it to be unncesssary clutter that is likely to

end up detracting from overall security.


I'll add a comment and a reminder that the actual size is supplied along
with the literal during download.



> -- "Open Issues" section: "Should Kazunori Fujiwara’s downgrade document also 
mention DOWNGRADED?"
>
> Good question. It seems like they should be consistent on things like this. 
(This is really more a comment on that draft than this one.)



I think I've made up my mind that in this case it doesn't matter.
Kazunori's task is complex reversible downgrade and has the Downgraded-*
header fields, why then bother with the DOWNGRADED response code? But
it's not my decision.


I agree it doesn't matter.


> -- Abstract should mention that this updates 3501



Really? A detail of this document updates a minor detail of that
document, that's hardly what I would expect to see in a single-paragraph
summary.


Exactly right. This is a silly thing to do.


I know someone who likes to repeat the Subject in the first line of the
email body text. Just in case I didn't see it the first time, I suppose.


The policy for EAI documents, which was agreed to by the working group and
which is now reflected in a number of RFCs, is not to put this sort of nonsense
in the abstract.

Ned

Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols

[IETF Chair]

I propose the following rewording to address the issue that has been raised.

Russ

= = = = = = = = =

The IEEE Registration Authority Committee (RAC) assigns Ethertypes.
(See http://standards.ieee.org/develop/regauth/ethertype/.)  Some IETF
protocol specification make use of Ethertypes.  Since Ethertypes are a
fairly scarce resource, the IEEE RAC has let us know that they will not
assign a new Ethertype to a new IETF protocol specification that needs
one until the IESG has approved the protocol specification for
publication as an RFC.

To let the IEEE RAC know that the IESG has approved an IETF protocol
specification for publication, all future requests for assignment of
Ethertypes for IETF protocol specifications will be made by the IESG.

Note that playpen Ethertypes have been assigned in IEEE 802 [1] for use
during protocol development and experimentation.


[1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001).
IEEE standard for Local and Metropolitan Area Networks:
Overview and Architecture -- Amendment 1: Ethertypes for
Prototype and Vendor-Specific Protocol Development.