MH Michael Hammer (5304 | 22 Apr 23:01 2014

Don't shoot the messenger... AOL is publishing DMARC p=reject as of today.

As I had indicated in a previous post, I expected that AOL might follow Yahoo in publishing p=reject as a means of mitigating a specific type of abuse they were experiencing.



S Moonesamy | 22 Apr 20:53 2014

Review of draft-kucherawy-dmarc-base-04

Hi Nevil,

I reviewed draft-kucherawy-dmarc-base-04.  I am copying the review to 
Murray as a courtesy, and ietf <at> as there has been a lot of 
discussion about the matter on that mailing list.  I presume that a 
healthy technical dialog with the authors is appropriate.  I'll defer 
to you on how to handle the review.

draft-kucherawy-dmarc-base-04 proposes a scalable mechanism by which 
a mail sending organization can express, using the Domain Name 
System, domain-level policies and preferences for message validation, 
disposition, and reporting, and a mail receiving organization can use 
those policies and preferences to improve mail handling.  It's a 
length document (76 pages).  The mechanism builds upon IETF 
specifications such as DKIM, SPF and ARF.  I'll use the soon-to-be 
published specification for SPF as a reference instead of the 
reference listed in the document.

In my opinion the document is not ready for publication in the 
Independent Submissions Stream.  Overall, the is more discussion 
about policy, anti-abuse, etc. compared to technical material.  There 
is a significant amount of tutorial material in the document.  My 
suggestion is to explain how the mechanism works, then provide the 
details without getting into lengthy details unless the intention is 
to set best common practices.  The usage of RFC 2119 key words comes 
out as prescribing requirements instead of focusing on 
interoperability.  The IANA requests seem problematic as it might not 
fit the assertion of IANA allocations not requiring IETF action.

The main issue is that the proposed mechanism extends SPF to cover a 
header field.  That may work well with personal messages, 
notifications about bank payments, etc.  It can be overly restrictive 
in cases where a MUA is not being used, e.g. someone entering his/her 
email address for use as the author of a notification (see ).

 From Section 1:

   "DMARC differs from previous approaches to policy advertisement (e.g.,
    [SPF] and [ADSP]) in that:

    o  Authentication technologies are:

       1.  decoupled from any technology-specific policy mechanisms; and

       2.  used solely to establish reliable per-message domain-level

    o  Multiple authentication technologies are used to:

       1.  reduce the impact of transient authentication errors

       2.  reduce the impact of site-specific configuration errors and
           deployment gaps

       3.  enable more use cases than any individual technology supports

I read the following:;id=849627

It's difficult to determine whether there was a reduction in impact 
compared to previous email authentication initiatives.  DMARC 
actually couples two email policy mechanisms instead of decoupling them.

DMARC attempts to solve the phishing problem (see Section 1.2) by 
preventing bad people from sending mail which claims to come from 
legitimate senders.  Section 1.2 sounds like a mix between problem 
definition and marketing.  The following sentence is difficult to understand:

   "Thus, DMARC is significantly informed by ongoing efforts to enact
    large-scale, Internet-wide, anti-phishing measures."

The document then states that:

   "Although DMARC can only be used to combat specific forms of exact-
    domain spoofing directly, the DMARC mechanism is a substantial step
    towards the creation of reliable and defensible message streams."

The above sentence tries to sell the technology.

 From Section 2.1:

   "One common attack on Internet users involves imitating mail from a
    reputable mail sender while including malicious content of some kind.
    The most damaging version of this attack, both to end-users and to
    organizations, uses the RFC5322 From: address of the reputable

In simple terms, the technology is about protecting the email address 
that is visible to the end-user.

According to Section 3, the document uses terminology from RFC 
5598.  I suggest further review of the document to ensure consistent 
usage of the terminology in that RFC.

 From Section 4:

   "A Mail Receiver MUST consider an arriving message to pass the DMARC
    test if and only if one or more of the underlying message
    authentication mechanisms pass with proper identifier alignment."

The above sets a requirement based on underlying message 
authentication mechanisms.  I gather that it is the mechanisms 
defined in Section 3.1.1.

 From Section 6:

   "Mail Receivers MAY choose to reject or quarantine email even if email
    passes the DMARC mechanism check."

The above can be interpreted in two ways:

   (a) The specification is getting into local (receiver) policy.

   (b) The organization advertising a DMARC policy takes responsibility
       for all messages that pass the DMARC mechanism check.

   "Mail Receivers are encouraged to maintain anti-abuse technologies
    to combat the possibility of DMARC-enabled criminal campaigns."

The above sentence does not belong in a document that defines a 
mechanism.  Who determines what is a criminal compaign?

   "Mail Receivers need to make a best effort not to increase the likelihood
    of accepting abusive mail if they choose not to comply with a Domain
    Owner's reject, against policy."

The above sounds like preaching for anti-abuse.

   "At a minimum, addition of the Authentication-Results header field
   (see [AUTH-RESULTS]) is RECOMMENDED when delivery of failing mail
    is done."

Why is that header field recommended as a minimum?

   "Mail Receivers are only obligated to report reject or quarantine
    policy actions in aggregate feedback reports that are due to DMARC

The above sentence binds or compels mail receivers.  I don't think 
that it is the purpose of a technical specification to set moral or 
legal obligations.

  "If local policy information is exposed, abusers can gain insight
   into the effectiveness and delivery rates of spam campaigns."

It sounds like the document is also trying to mitigate spam problems.

   "Mail Receivers SHOULD also implement reporting instructions of DMARC
    in place of any extensions to SPF or DKIM that might enable such

The above recommendation is to replace extensions defined in IETF 
specifications with what is defined in the document.

 From Section 7.3.1:

   "Operators implementing this specification also implement an augmented
    version of [AFRF] as follows:"

The above extends an IETF specification.

In Section 7.4:

   "These reports SHOULD include as much of the message and message header
    as is reasonable to support the Domain Owner's investigation into what
    caused the message to fail authentication and track down the sender."

The recommendation looks like what one would usually see in a legal document.

In Section 8:

   "If the RFC5322.From domain does not exist in the DNS, Mail Receivers
    SHOULD direct the receiving SMTP server to reject the message."

Why is there such a recommendation?  What is a mail receiver?  I am 
asking the question as there is "receiving SMTP server" in that sentence.

In Section 10.1:

   "Have no RFC5322.From field (which is also forbidden under RFC 5322

Where is it stated in RFC 5322 that it is forbidden?  That RFC 
specifies a syntax for the Internet Message Format.

   "Such messages SHOULD be rejected."

Why should such messages be rejected?

   "Heuristics applied in the absence of use by a Domain Owner of either
    SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be
    the case that the Domain Owner wishes a Message Receiver not to
    consider the results of that underlying authentication protocol at

This is more of a reminder that there was agreement in some IETF 
working group not to say anything about Best-Guess-SPF.

In Section 10.3:

   "If email is subject to the DMARC policy of "quarantine", the Mail
    Receiver SHOULD quarantine the message."

The above prescribes what the mail receiver should do.

   "If email is subject to the DMARC policy of "reject", the Mail
    Receiver SHOULD reject the message (see Section 15.4)."

The above has been a subject of debate on several mailing lists.

Section 14 is about privacy considerations.  The mechanism proposed 
in this document enables the domain name registrant to track usage of 
its domain name in email across DMARC-compliant sites on the internet 
without prior agreement between the relevant entities.  Based on my 
reading of RFC 6591 I think that the privacy considerations does not 
explain the extent of the data exposure.  The reader may construe 
"sender and recipient identifiers" as the email addresses of the 
sender and recipient only.

In Section 14.4:

   "This document encourages use of secure transport mechanisms to
    prevent loss of private data to third parties that may be able to
    monitor such transmissions.  Unencrypted mechanisms should be

Given the state spying reports an encouragement to use secure 
transport mechanisms sounds like a feeble attempt at securing the 
private data which will be sent across the internet.

 From Section 15.4:

   "550 5.7.1 Email rejected per DMARC policy for"

I note that the company that has been mentioned in DMARC discussions 
does not follow the example given.

Section 16 describes IANA registry updates.  I suggest contacting the 
IETF Application Directors for information about the procedure to be 
followed for the registry updates.

Section 16.4 defines a DMARC Tag Registry.  The proposed registry 
policy for new entries is to have "a published RFC that has had IETF 
Review".  I suggest that the authors contact the IESG for advice 
about this registry.  It is highly unusual to have a RFC in the 
Independent Submissions Stream requesting the creation of a (IANA) registry.

 From Section 17.4:

   "Generally, display name attacks are out of scope for DMARC"

Are display name attacks out of scope or not?  The above can be 
interpreted as display attacks are out of scope when it is convenient 
to say that.  Section 17.4 discusses about mechanisms to mitigate 
these attacks.

I read the appendices quickly.  Appendix A.1 explains why S/MIME is 
bad.  Appendix B explains how SMTP works.  Appendix C proposes a XML 
Schema and descriptions of

S. Moonesamy

Sam Hartman | 22 Apr 02:11 2014

Thanks for improved editing function over at the rfc-editor

I've been through a number of auth48s lately and I just noticed that the
editing process that the RFC editor is using introduces significantly
fewer errors than it used to.
Back ind the 2004-2007 era, it was actually very common to see authors
objecting to a number of auth48 changes.  I saw this in my own documents
as well as documents in my area.

I see fewer documents these days, but I do see enough documents that I
have confidence in my claim that the auth48 process seems to be much
smoother than it used to be.

This is really nice.  Thanks for the ongoing great work.

Lawrence Rosen | 20 Apr 19:18 2014

Author disclosures and conflict of interest

I’ve been skimming recent threads  on this list relating to work done (or not done) at IETF and was reminded of this from Science Magazine:


Authorship Form and Conflict-of-Interest Statement

To meet its responsibility to readers and to the public to provide clear and unbiased scientific results and analyses, Science believes that manuscripts (including Brevia, Essays, Perspectives, Policy Forums, Reports, Research Articles, Reviews, and Viewpoints) should be accompanied by clear disclosures from all authors of the nature and level of their contribution to the article, their understanding regarding the obligation to share data and materials, and any affiliations, funding sources, or financial holdings that might raise questions about possible sources of bias. Before manuscript acceptance, therefore, authors will be asked to sign an authorship/conflict-of-interest form. Specific information will be sent to most authors at the time of manuscript revision.

Authorship Form and Statement of Conflicts of Interest [PDF]


Part IV regarding “Conflict of Interest” is particularly relevant to standards organizations such as IETF. Such a disclosure requirement would further encourage everyone to trust and implement IETF specifications.


This document follows the recommendations in On Being a Scientist: A Guide to Responsible Conduct in Research, The National Academies Press, Third Edition (2009).




Lawrence Rosen

Rosenlaw & Einschlag (

3001 King Ranch Road, Ukiah, CA 95482

Cell: 707-478-8932   Fax: 707-485-1243


IETF Chair | 20 Apr 14:48 2014


I wanted to highlight that next week the NetMundial meeting ( will be run in Sao
Paulo, Brazil. Pointers to agendas, draft outcome documents, etc. can be found from my blog:

Jari Arkko, IETF Chair

Abdussalam Baryun | 19 Apr 12:24 2014

Open source running code or closed industry code (was Re: "why I quit writing internet standards")

Hi IETFers,

Firstly, IETF standards need to be more available to community through
open sources, specially the security standards to help the community
to avoid attacks from big organisations. I suggest that a new IETF
Area to be open for Open Source. We need to make comments on all our
standards that are not available open sources. In IETF it is still not
clear its standards implementation practices in the community, we need
informational documents that decsribe its standards' tests and
possible scenario failures.

Secondly, the industry is running codes (closed source) of our
standards but no much feedback about their performance in IETF. The
IETF should get more input from open source communities that can help
to make IETF more driven by user-engineers than industries.

Thirdly, both people and organisations, that volunteer their running
codes into the new IETF area will help to build a better Internet
future. If we get open source volunteers into IETF with their
input/code/documents, then we will get better performance in our
standards and in the future directions.

Comments below,

On 4/14/14, Alia Atlas <akatlas <at>> wrote:
> On Mon, Apr 14, 2014 at 11:57 AM, David Meyer <dmm <at>> wrote:
>> On Mon, Apr 14, 2014 at 8:08 AM, George, Wes < <at>>
>> wrote:
>>> I’m surprised that no one has sent this out yet:
>>> "Summary: After contributing to standards organizations for more than
>>> seven
>>> years, engineer Vidya Narayanan decided it was time to move on. Although
>>> she
>>> still believes that these organizations make the Internet a better
>>> place,
>>> she wonders about the pace of change versus the pace of organizations."
>>> My thoughts-
>>> There are some nuggets of truth in what she says in this article, and in
>>> some of the comments. I think that the problems are real, so there’s
>>> value
>>> in taking the criticism constructively, despite the fact that the author
>>> chose to focus on the problems without any suggestions of solutions.
>>> "while the pace at which standards are written hasn’t changed in many
>>> years,
>>> the pace at which the real world adopts software has become orders of
>>> magnitude faster."
>>> …
>>> "Running code and rough consensus, the motto of the IETF, used to be
>>> realizable at some point. … In the name of consensus, we debate
>>> frivolous
>>> details forever. In the name of patents, we never finish.”
>>> …
>>> "Unless these standards organizations make radical shifts towards
>>> practicality, their relevance will soon be questionable.”
>>> I don’t have too many big ideas how to fix these problems, but I’ll at
>>> least
>>> take a crack at it in order to spur discussion. My paraphrase of the
>>> problem
>>> and some discussion follows.
>>> - We’ve lost sight of consensus and are too often derailed by a vocal
>>> minority of those willing to endlessly debate a point.
>>> Part of the solution to that is reiterating what consensus is and is
>>> not,
>>> such as draft-resnick-on-consensus so that we don’t confuse a need for
>>> consensus with a need for unanimity. Part of the solution is IETF
>>> leadership
>>> helping to identify when we have rough consensus encumbered by a debate
>>> that
>>> will never resolve itself, without quieting actual disagreement that
>>> needs
>>> continued discussion in order to find a compromise. I don’t have good
>>> suggestions on how to make that second half better.
>>> - We don’t have nearly enough focus on running code as the thing that
>>> helps
>>> to ensure that we’re using our limited cycles on getting the right
>>> things
>>> out expediently, and either getting the design right the first time, or
>>> failing quickly and iterating to improve
>>> The solution here may be that we need to be much more aggressive at
>>> expecting any standards track documents to have running code much earlier
>>> in
>>> the process. The other part of that is to renew our focus on actual
>>> interop
>>> standards work, probably by charter or in-group feedback, shift focus
>>> away
>>> from BCP and info documents. Perhaps when considering whether to proceed
>>> with a given document, we need test as to whether it’s actively
>>> helpful/needed and ensure that we know what audience would be looking at
>>> it,
>>> rather than simply ensuring that it is “not harmful” and mostly within
>>> the
>>> WG’s chartered focus.

I recommend to separate between designers and implementers. Each have
different challenges and different tasks, so I suggest different
WGs/DTs or a new IETF Area. The way IETF was doing in the past is
excellent process because we have designers interactions, but we need
more volunteer implementers and we may need implementers to have more
interaction within IETF.

>> My friend  <at> colin_dixon pointed this out to me yesterday, and I've been
>> giving it quite a bit of thought since then (I have a nascent blog on
>> the topic of how open source and standards orgs might
>> productively/efficiently work together; follow up to

Thanks, it is an important draft for the IETF General Area to
consider. I suggested before that the IETF general Area should have
some WGs for important issues because the area is not performing well,
and many issues are not getting good conclusions by the community.
IESG will like to leave every thing general for only its input and we
as community have no input only if IESG decides. However, if we do
like you and write our own draft it may get attention from existing
participants, but who left IETF like Vidya Narayanan or may be many
others (who unsubscribed from IETF list) will not get chance to say
their opinion because there was no convincing community system for
general works in IETF General Area.

>> What I can say is that after seeing the kind of progress that several
>> open source communities make (they do epitomize the best of the IETF's
>> running code/rough consensus ethic), one does have to wonder if
>> traditional standards making is either obsolete or in dire need of a
>> make over. What is needed, IMO, is a reimagining of how the standards
>> process interacts with the open source movement specifically focused
>> on how they can compliment one another.

I agree with you, but IMO the way of doing that needs to be within
IETF organisation not outside IETF. Those open source community should
be welcomed to join WGs within one new IETF Area. Maybe there are
problems within IETF management with those communities management,
which may delay movements.

> [Alia] It would be very useful to have a functional model for how the
> two can compliment each other.  We also tend to talk about open-source
> as a single monolith - when it can have very different models for
> accepting in changes, how and who runs the community, who is really
> participating (open source doesn't mean non-corporate) etc.

The IETF should be running its running code, some of community are
sending messages to WG asking of code sources but they may get no
respond, isn't that a shame of IETF to have no clue what to respond or
to have no document related to running code tests. The IETF runs the
standards for the community, so I expect the IETF to help community to
participate in its standards by making an IETF area available for
community to run the IETF standards.

>  Some of
> what the IETF does is the architecture and requirements thinking about
> how the solution should fit in - while some of the open-source is
> about getting a solution implemented ASAP.

Yes, but after the IETF standard is published don't we think we need
to implement publicly (i.e. openly) that so the IETF vision is
targeted to make the Internet better place for users or community.
Does IETF leave the industry to manage/influence the change of

>  IMHO, a spiral is useful
> with an easy way of interaction.  With I2RS, as a WG chair, I
> suggested having experimental drafts describing solutions that were
> being implemented - but haven't seen any.   A question is what is
> needed to encourage the interactions.

Mostly industries don't do volunteering open source only for specific
reasons, but people may do volunteering open sources just to fulfill
the IETF vision.

> [Alia] Diversity of implementation is important as is stability of a
> standard and it being understood how to change/upgrade for different
> versions.  These don't come automatically via open-source.

IETF General Area still did not solve the diversity problem overall,
but for implementation diversity, IMO, we need a new IETF area that is
responsible to manage IETF open sources of its running code in the

Best Wishes,


S Moonesamy | 18 Apr 15:41 2014

RE: Internet Technology Adoption and Transition

Hi Lloyd,
At 00:57 18-04-2014, l.wood <at> wrote:
>the correct url is
>no trailing minus. why cite a broken url?

I should have removed the URL instead of citing it.

>evolution in the smtp space? Um, DMARC?

I am reading "SMTP" narrowly and did not consider DMARC as part of the space.


examples of DNSSEC-based applications are mentioned and there is the following:

    "The DMARC wg is working on higher-level use of DKIM and SPF."

The technology for those two specifications is mostly related to DNS.

>for thoughts on http as an hourglass waist, see
>- it's a little hard to see http as a waist when it's so tightly 
>coupled to tcp. That is unlikely to change, as the benefits of 
>uncoupling are for edge cases.

Thanks for the URL.  I would say yes to the comment about tightly 
coupled.  I'd say that they are seen as the transport and you end up 
with other protocols being designed on top of that.

>many involved in the ietf, myself included, began contributing as 
>grad students. As with academic paper review, it's how the 
>interested/enthusiastic/unpaid learn.


S. Moonesamy 

Thomas Narten | 18 Apr 06:53 2014

Weekly posting summary for ietf <at>

Total of 333 messages in the last 7 days.

script run at: Fri Apr 18 00:53:02 EDT 2014

    Messages   |      Bytes        | Who
 13.81% |   46 | 11.01% |   352055 | mfidelman <at>
  6.61% |   22 |  5.18% |   165582 | johnl <at>
  5.71% |   19 |  5.46% |   174711 | superuser <at>
  3.60% |   12 |  5.39% |   172371 | mhammer <at>
  4.80% |   16 |  3.45% |   110360 | tytso <at>
  3.30% |   11 |  4.11% |   131557 | dave <at>
  3.90% |   13 |  3.18% |   101792 | brian.e.carpenter <at>
  3.30% |   11 |  3.53% |   112824 | hsantos <at>
  0.30% |    1 |  5.94% |   189934 | kathleen.moriarty.ietf <at>
  2.70% |    9 |  2.02% |    64650 | mcr+ietf <at>
  2.40% |    8 |  2.09% |    66759 | sm+ietf <at>
  2.40% |    8 |  2.03% |    64900 | ned+ietf <at>
  2.10% |    7 |  1.65% |    52708 | dougb <at>
  1.20% |    4 |  2.48% |    79209 | seth.p.johnson <at>
  1.50% |    5 |  2.03% |    64985 | doug.mtview <at>
  1.80% |    6 |  1.60% |    51254 | ynir.ietf <at>
  0.90% |    3 |  2.14% |    68602 | bclaise <at>
  1.50% |    5 |  1.38% |    44016 | aldrin.ietf <at>
  1.50% |    5 |  1.32% |    42297 | presnick <at>
  1.50% |    5 |  1.28% |    40930 | listsebby <at>
  1.20% |    4 |  1.52% |    48654 | abdussalambaryun <at>
  1.50% |    5 |  1.19% |    38044 | scott <at>
  1.20% |    4 |  1.47% |    47008 | <at>
  1.50% |    5 |  1.11% |    35519 | john-ietf <at>
  1.50% |    5 |  1.06% |    34047 | dhc <at>
  1.20% |    4 |  1.32% |    42162 | nobo <at>
  1.20% |    4 |  1.12% |    35760 | rwfranks <at>
  0.90% |    3 |  1.39% |    44407 | tnadeau <at>
  0.90% |    3 |  1.32% |    42195 | douglasroyer <at>
  1.20% |    4 |  1.02% |    32589 | spencerdawkins.ietf <at>
  1.20% |    4 |  0.84% |    26839 | mrex <at>
  1.20% |    4 |  0.80% |    25569 | dcrocker <at>
  0.60% |    2 |  1.27% |    40515 | andy <at>
  0.90% |    3 |  0.77% |    24542 | ietf <at>
  0.90% |    3 |  0.70% |    22302 | johnl <at>
  0.90% |    3 |  0.69% |    22132 | hallam <at>
  0.90% |    3 |  0.66% |    21029 | ted.lemon <at>
  0.90% |    3 |  0.65% |    20882 | l.wood <at>
  0.90% |    3 |  0.60% |    19332 | wes <at>
  0.60% |    2 |  0.72% |    23107 | dmm <at>
  0.60% |    2 |  0.47% |    14985 | marka <at>
  0.60% |    2 |  0.46% |    14738 | worley <at>
  0.60% |    2 |  0.45% |    14302 | vesely <at>
  0.60% |    2 |  0.41% |    13155 | cabo <at>
  0.60% |    2 |  0.39% |    12408 | jhaas <at>
  0.30% |    1 |  0.68% |    21632 | cdel <at>
  0.60% |    2 |  0.35% |    11148 | iab-chair <at>
  0.30% |    1 |  0.64% |    20386 | <at>
  0.30% |    1 |  0.62% |    19676 | spromano <at>
  0.30% |    1 |  0.58% |    18645 | r.e.sonneveld <at>
  0.30% |    1 |  0.49% |    15752 | hector.santos45 <at>
  0.30% |    1 |  0.44% |    14225 | <at>
  0.30% |    1 |  0.37% |    11767 | aaron.ding <at>
  0.30% |    1 |  0.36% |    11543 | tjw.ietf <at>
  0.30% |    1 |  0.34% |    10882 | akatlas <at>
  0.30% |    1 |  0.29% |     9374 | narten <at>
  0.30% |    1 |  0.27% |     8622 | warren <at>
  0.30% |    1 |  0.26% |     8352 | rpelletier <at>
  0.30% |    1 |  0.25% |     8136 | agmalis <at>
  0.30% |    1 |  0.25% |     8108 | jari.arkko <at>
  0.30% |    1 |  0.25% |     7942 | fergie <at>
  0.30% |    1 |  0.24% |     7758 | serrhini <at>
  0.30% |    1 |  0.24% |     7644 | rwfranks <at>
  0.30% |    1 |  0.23% |     7428 | thomas <at>
  0.30% |    1 |  0.23% |     7405 | melinda.shore <at>
  0.30% |    1 |  0.22% |     7161 | scott.brim <at>
  0.30% |    1 |  0.22% |     6953 | hartmans-ietf <at>
  0.30% |    1 |  0.21% |     6806 | stephen.farrell <at>
  0.30% |    1 |  0.21% |     6744 | fenton <at>
  0.30% |    1 |  0.21% |     6679 | adrian <at>
  0.30% |    1 |  0.21% |     6619 | jelte.jansen <at>
  0.30% |    1 |  0.21% |     6576 | abhishekv.verma <at>
  0.30% |    1 |  0.20% |     6503 | olejacobsen <at>
  0.30% |    1 |  0.20% |     6336 | bzeeb-lists <at>
  0.30% |    1 |  0.20% |     6249 | randy_presuhn <at>
  0.30% |    1 |  0.19% |     6134 | syedalisuleman <at>
  0.30% |    1 |  0.18% |     5874 | tglassey <at>
  0.30% |    1 |  0.17% |     5476 | randy <at>
  0.30% |    1 |  0.16% |     5249 | kent <at>
  0.30% |    1 |  0.16% |     5020 | rjsparks <at>
100.00% |  333 |100.00% |  3198522 | Total

Ray Pelletier | 17 Apr 20:02 2014

Re: [Recentattendees] ACTION: 2014 Meeting Venue Preference Survey


Thank you for your participation in the survey.

We received 659 responses.

The top 5 venue preferences for each region are:

Sydney		329
Hong Kong	326
Tokyo		322
Singapore	261
Auckland		250

Barcelona	351
Rome		261
Paris		249
Berlin		244
Prague		224

US & Canada	
San Francisco	335
Vancouver	301
New York		270
Boston		266
Montreal		252

You can find all the results for the 15 venues per region here:  <>

Just a reminder about the survey:
The purpose of the 2014 Meeting Venue Preference Survey is to inform the IAOC during  its 
IETF meeting venue selection process of the community's preferred future meeting venues.

While being guided by this information, the IAOC will select actual venues following its due diligence, 
including site visits of specific hotel and conference facilities and other factors.   Other factors
cost, travel burden, venue surroundings, access, safety, risks, etc.   The IAOC is currently (March 2014) 
reviewing venues for 2017. 

We are still missing T-Shirt pictures for the T-Shirt Picture Gallery:  

Submit your entries here:  <>

Thanks again for your guidance.


On Mar 27, 2014, at 8:07 PM, Ray Pelletier <rpelletier <at>> wrote:

> All;
> The purpose of this anonymous, 7 question 2014 Meeting Venue Preference Survey is to inform the IAOC
during  its IETF meeting venue selection process of the community's preferred future meeting venues.
> While being guided by this information, the IAOC will select actual venues following its due diligence,
including site visits, of specific hotel and conference facilities and other factors.   Other factors
include cost, travel burden, venue surroundings, access, safety, risks, etc.   The IAOC is currently
reviewing venues for 2017. 
> Thanks for your continuing guidance and support.
> Ray
> IETF Administrative Director
> _______________________________________________
> Recentattendees mailing list
> Recentattendees <at>

TGLASSEY | 16 Apr 22:28 2014

We need to add the ability to upload attachments to the IPR Filings.

In any number of instances the simple attachment of a sublicensing 
agreement or assignment contract which is already on file with the PTO 
to a IETF filing to ease parties doing diligence on these IP's would be 
a stroke of brilliance here.

It also would allow the IETF to take a more arms-length approach because 
it is accepting IP Statements in both its framework and language as 
described by BCP78 and 79 but also in adding the ability to reference a 
directly uploaded content document as part of the publication of the IP 




Personal Email - Disclaimers Apply

Aaron Yi DING | 17 Apr 10:59 2014

IETFer's work received ACM Computing Review

picked up by the Computing Review, by a couple of ietfers (e.g., Jouni Korhonen, Jörg Ott, Jon Crowcroft)

Bridging the gap between Internet standardization and networking research

ACM Computing Review
Bridging the gap between the network research community and Internet standards is an important topic. Most network research has not been turned into an Internet standard, while some research comes a long way in order to become an Internet standard. Very few studies investigate this issue because it extends beyond purely technical concerns.

The authors have an advantage in investigating this issue since they have tightly collaborated on projects with academic researchers and industrial professionals. They thoroughly present their observations and share their experiences in this paper. The challenges for this gap are defined in two parts: technical challenges and nontechnical challenges. A good point is that the authors share the nontechnical challenges that might be ignored by researchers and industrial professionals. The authors, aware of the gap, also find two major opportunities that can extend research works to standardization contributions, which is encouraging to networking researchers.

Based on their past experiences, the authors share two concrete case studies: mobile traffic offloading and Internet protocol version 6 (IPv6) transition technologies. The mobile traffic offloading case shows substantial scientific results, but it also shows an under-performing standardization effort. This case proves that the proposal, which does not fit in an existing mindset, is usually a failure. On the other hand, the case of IPv6 transition technologies shows good results in both academia and industry, because the research proposal has extensibility and minimum impact on the existing infrastructure. The authors then share their lessons and suggestions to bridge the gap. These are honest and useful to both academia and industry. Readers will see the potential for comprehensive collaboration between networking research and Internet standardization.

ACM SIGCOMM CCR chief editor:

"Its focus is to identify ways to bridge the gap between the networking community and the Internet standardization bodies. The authors, from Broadcom, Nokia, University of Cambridge, Aalto University and University of Helsinki, are describing the differences and similarities between how the two communities operate. They further provide interesting data on the participation of academic and industrial researchers in standardization bodies. They discuss ways to minimize the friction that may exist as a particular technology is making the leap from the scientific community into the industry."

Two cents,