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> gmail.com> wrote:
> On Mon, Apr 14, 2014 at 11:57 AM, David Meyer <dmm <at> 1-4-5.net> wrote:
>> On Mon, Apr 14, 2014 at 8:08 AM, George, Wes <wesley.george <at> twcable.com>
>> wrote:
>>> I’m surprised that no one has sent this out yet:
>>> http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/
(Continue reading)

S Moonesamy | 18 Apr 15:41 2014

RE: Internet Technology Adoption and Transition

Hi Lloyd,
At 00:57 18-04-2014, l.wood <at> surrey.ac.uk 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.
(Continue reading)

Thomas Narten | 18 Apr 06:53 2014

Weekly posting summary for ietf <at> ietf.org

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> meetinghouse.net
  6.61% |   22 |  5.18% |   165582 | johnl <at> taugh.com
  5.71% |   19 |  5.46% |   174711 | superuser <at> gmail.com
  3.60% |   12 |  5.39% |   172371 | mhammer <at> ag.com
  4.80% |   16 |  3.45% |   110360 | tytso <at> mit.edu
  3.30% |   11 |  4.11% |   131557 | dave <at> cridland.net
  3.90% |   13 |  3.18% |   101792 | brian.e.carpenter <at> gmail.com
  3.30% |   11 |  3.53% |   112824 | hsantos <at> isdg.net
  0.30% |    1 |  5.94% |   189934 | kathleen.moriarty.ietf <at> gmail.com
  2.70% |    9 |  2.02% |    64650 | mcr+ietf <at> sandelman.ca
  2.40% |    8 |  2.09% |    66759 | sm+ietf <at> elandsys.com
  2.40% |    8 |  2.03% |    64900 | ned+ietf <at> mauve.mrochek.com
  2.10% |    7 |  1.65% |    52708 | dougb <at> dougbarton.us
  1.20% |    4 |  2.48% |    79209 | seth.p.johnson <at> gmail.com
  1.50% |    5 |  2.03% |    64985 | doug.mtview <at> gmail.com
  1.80% |    6 |  1.60% |    51254 | ynir.ietf <at> gmail.com
  0.90% |    3 |  2.14% |    68602 | bclaise <at> cisco.com
  1.50% |    5 |  1.38% |    44016 | aldrin.ietf <at> gmail.com
  1.50% |    5 |  1.32% |    42297 | presnick <at> qti.qualcomm.com
  1.50% |    5 |  1.28% |    40930 | listsebby <at> me.com
  1.20% |    4 |  1.52% |    48654 | abdussalambaryun <at> gmail.com
  1.50% |    5 |  1.19% |    38044 | scott <at> kitterman.com
  1.20% |    4 |  1.47% |    47008 | david.black <at> emc.com
  1.50% |    5 |  1.11% |    35519 | john-ietf <at> jck.com
(Continue reading)

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:  <https://www.ietf.org/meeting/>
(Continue reading)

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,
S Moonesamy | 16 Apr 19:26 2014

RE: Let's talk (was: DMARC: perspectives from a listadmin of large open-source lists)

Hi Mike,
At 20:44 15-04-2014, MH Michael Hammer (5304) wrote:
>I think this conflates two different issues:


>1) Cost to participation. While I may work for a larger 
>organization, much if not most of my participation is in addition to 
>my other work obligations. I know of other folks in a similar 
>situation. I participated before I worked at a large organization, I 
>participated when I had my own small business and I may choose to 
>participate in the future if my circumstances change. There are 
>other people whose occupation consists solely of standards work. I 
>don't have any meaningful answer to your comment. Quite frankly, I'm 
>asking myself why I should personally continue to engage with the 
>IETF process at all. It's not as if my employer is demanding it. Do 
>I really want to be engaging with IETF after a 16 hour day working 
>on other stuff? It must be masochism.

One of the reasons to participate in the IETF is self-interest.  The 
IETF standard for IETF participants is attending three out of five 
meetings.  A small business cannot afford that cost.  The list of 
volunteers is at https://datatracker.ietf.org/nomcom/ann/58250/  How 
many of the people are from small businesses?

>2) Getting ignored or minority view. I don't believe it is simply a 
>function of company size - at least for the WGs I've participated 
>in. I'd assert that at least in the email/email auth WGs it's more a 
>function of long term participants, many of whom have calcified 
>positions (across the spectrum). I can think of at least one person 
>from a relatively large company who gets ignored a fair bit, so size 
>is not necessarily a factor. I've been in the minority view on 
>various issues in the WGs I've participated in. That's life - I 
>chose Betamax. To a certain extent it's also a function of who is 
>wrangling the WG and how they manage the WG. I don't really think 
>about whether a person is with a large company, a small company or 
>an individual - I'm more interested in the quality and practicality 
>of their ideas. I'm more of a security and operations guy and that 
>colors my perspective.

The usual explanation for the ways things are is "That's 
life".  That's what gets you (used in a general sense) calcified 
positions, specifications that takes years to be published and other 
IETF problems.

>I'm not sure if you are looking for a response to Dave Cridland's 
>message in the context of DMARC specifically. As I noted when I 
>first posted to this group, I don't speak on behalf of DMARC and my

I wasn't looking for a response as I have been staying out of DMARC 

>  comments are on a personal basis. When DMARC came along, as a 
> sender I only had to publish a p=reject policy. We (my employer) 
> had done the heavy lifting in terms of changing our mailing 
> practices back in 2007 before there was a dmarc.org or a spec. I 
> had some concerns about a wide open WG but wasn't necessarily 
> against it. My concerns were more along the line of how much of a 
> grind it might be on a personal basis (after my experiences with 
> other WGs). I do recognize that others made a significant 
> investment in implementing running code to make things work. I 
> think a lot of people underestimate what was involved and overly 
> discount concerns about radical modifications to the spec. When I 
> did my original effort in 2007 it was a five month project 
> involving quite a few people to change how our websites handled 
> mail to accommodate strong authentication for SPF and DKIM. I'll 
> also point out that the interoperability event for DKIM didn't take 
> place until 2008 which meant I was somewhat going out on a limb. 
> I'm sure that for others to do their DMARC implementations on the 
> mailbox provider side several years later it was a larger effort 
> than what I went through. My personal belief is that nobody was 
> looking to get an IETF rubber stamp. Perhaps the concerns might 
> have been communicated differently and perhaps there might have 
> been a little less skepticism as to intent.

Rewriting a specification from scratch is rather silly if there isn't 
a good reason to do that.  In my opinion the purpose of a working 
group is to review the drafts and send work of acceptable quality to 
the Area Director.  It is possible to take into consideration the 
constraints of the various parties if there is a public 
explanation.  At the same time the parties could consider that 
hinting for an IETF rubber stamp is going to be problematic.

I'll highlight a comment from Stephen J. Turnbull:

   "It might help if you gave us the annotated version of what you do like
    about it, instead of telling us that everything we've been doing for
    20 years is wrong, and that we're crazy to object to the violation of
    the most fundamental and ancient email RFC (not to mention violating
    copyright law in every Berne Convention signatory) by corrupting the
    authorship information of each post we process."

If it is difficult to explain in English words, show the source 
code.  It is worthwhile to look into the interoperability issues.  It 
may not be possible to solve all of them quickly.  That's not a 
significant problem as long as a working group does not break too much stuff.

>So on to the mail list issue. On one level I want to say not my 
>issue. I don't publish p=reject for any domains with users that send 
>to mail lists so as I've said, my ox isn't getting gored. There were 
>plenty of discussions in the DKIM working group about 1st party 
>signatures vs 3rd party signatures and trust and reputation and who 
>should do what and who wouldn't do what. At the end of the day the 
>can was kicked down the road. So here we are. I don't have any 
>answers for this group. I've already stated in a previous post how I 
>think it will play out. I'm leaning towards just walking away and 
>spending cycles on something as that is more productive from my 
>perspective. The juice just isn't worth the squeeze.

It's okay to say "not my issue".  It is an issue if most people in 
the group say "not my issue".  If there isn't any progress on the 
issue the note to the Area Director could be "the working group does 
not have the competence to address this issue".

>I don't think you are likely to see someone speaking up in that 
>particular way. "My boss has bad ideas" posted to a public forum is 
>not a career enhancing move even if phrased politely. Those sorts of 
>issues would likely get resolved internally or the person would 
>likely choose to move to another roost if it is a significant issue. 
>That's just common sense. At least for me, in the WGs I've 
>participated in, I've had a lot of latitude because the issues are 
>technical and it is more me keeping management apprised of what is 
>happening and what I'm doing than me getting directives. I can't 
>speak for others or other organizations. I don't have anything to 
>sell or market so I have no reason to use marketing language. My 
>goal is to protect end users from maliciousness that tries to 
>leverage our domains and brands - things like SPF, DKIM and DMARC 
>help do that in conjunction with other efforts such as takedowns, 
>blocking, prosecutions, etc. I also get involved in other anti-abuse 
>efforts that have nothing to do with my employer - because I believe 
>it is the right thing to do. Standards are just one piece of the puzzle.

Speaking about career enhancing moves, common sense dictates that it 
is to be assumed that the individual is the mouthpiece of the 
organization (I am not inferring that you are).  In my opinion 
reviews from individuals affiliated with the companies listed on the 
web page might not fit within the objectivity guidelines.  It may be 
difficult to find an external reviewer if Dave Cridland does not wish 
to donate his intellectual property rights.

Takedowns, blocking, prosecutions, brand protection, etc. are 
non-technical issues.  These issues could be discussed if it helps 
the average participant to understand the puzzle.  Past DKIM and SPF 
discussions could be listed under "gives the WG Chair(s) a headache".

Is this work doable?  I don't know.  Would I put effort to solve 
Company X is breaking the internet?  No, as it is an expense which I 
cannot afford.  Did I learn anything from the discussions on the 
previous topic?  Yes. :-)

S. Moonesamy 

S Moonesamy | 16 Apr 00:36 2014

Let's talk (was: DMARC: perspectives from a listadmin of large open-source lists)

Hi Mike,
At 13:30 15-04-2014, MH Michael Hammer (5304) wrote:
>My experience with regard to working groups is that it is 
>(technically) easy to participate and does not necessarily involve 
>any particular costs. I don't go to IETF meetings but have 
>participated in WG sessions during IETF meetings through jabber. Not 
>the optimal solution but it works. I think that the notion of 8000lb 
>gorillas somewhat misrepresents the situation. Some of the active 
>participants in the working groups I've been involved with continue 
>their involvement even when they change employers. With that in 
>mind, I believe that in many cases it truly is the individual and 
>not the individual as mouthpiece for the organization. I also 
>believe that the 8000lb gorillas have many of the same interests as 
>smaller organizations and individuals even though there are times 
>where interests may diverge. It's also clear to me that there is not 
>uniformity of interests across constituencies within large 
>organizations. It's complex. So let's talk.

It is, as you mentioned, complex.  I'll be one-sided in this 
comment.  There is a cost to participation on the mailing lists and 
to attend meetings.  There is a higher burden for a small company or 
an individual.  People from small companies sometimes get ignored or 
it is like the minority view (see Dave Cridland's message at 
http://www.ietf.org/mail-archive/web/ietf/current/msg87389.html ).

I can understand that an individual is not the mouthpiece of the 
organization if that individual sometimes speaks up to say that 
management is saying X but he or she does not think that it is a 
great idea.  You have tried to be positive by discussing about this 
publicly, politely and without resorting to marketing 
language.  Let's see who else would like to talk.

S. Moonesamy  

Miles Fidelman | 15 Apr 21:41 2014

re. DMARC - apropos cooperation, or lack there-of by yahoo

Apropos the recent discussion, it strikes me that this exchange of email 
w/ Yahoo might be of interest:

On one of the pages pointed to by Yahoo's blog announcement of their 
DMARC policy change, they posted this invitation: "If you are a 
developer of mailing list software and would like help adding features 
to allow participants from domains with DMARC p=reject, please contact 
us at dmarc-help <at> yahoo-inc.com."

So... I took them up on it, by sending this:

From: Miles Fidelman [mailto:mfidelman <at> meetinghouse.net]
Sent: Saturday, April 12, 2014 6:28 PM
To: dmarc-help <at> yahoo-inc.com
Subject: do you support Original-Authentication-Results?
I'm not a mailing list software developer, but I'm sure interested in 
patching the software we use (Sympa).
The most pressing question right now is whether your DMARC 
implementation supports Original-Authentication-Results - which would 
allow us to actually support DMARC transparently to list subscribers.A 
related question is knowing which other large ISPs, who honor p=reject, 
also honor Original-Authentication-Results.
Miles Fidelman

To which, I received this in response:

-------- Original Message --------
From: 	Mailing Help <dmarc_help <at> yahoo.com>
Reply-To: 	Mailing Help <dmarc_help <at> yahoo.com>
Subject: 	Subject: do you support Original-Authentication-Results?
To: 	mfidelman <at> meetinghouse.net <mfidelman <at> meetinghouse.net>
MIME-Version: 	1.0
Content-Type: 	multipart/alternative; 

Greetings Miles.
Yahoo Mail is not currently supporting OAR headers. We’re reviewing 
possible solutions in regards to OAR headers and how to act upon them 
from trusted third parties. Our primary goal at this time is to 
eliminate Mail Spoofing for email that does not originate from our mail 
I’d like to work with you in the near future if and when we’d like to 
test new changes. Can I add you as a contact Miles?
Kendrick - Yahoo Mail


Talk about not helpful.

Miles Fidelman

S Moonesamy | 15 Apr 21:23 2014

Re: DMARC: perspectives from a listadmin of large open-source lists

Hi Dave,
At 00:42 15-04-2014, Dave Cridland wrote:
>Given the expense and difficulty of IETF participation for smaller 
>organisations and individuals, it's hard for them to club together 
>and stand up to the 8000lb gorillas.

The above is an obvious problem or difficult situation that people do 
not want to talk about.

Publication in the IETF Stream usually entails giving up change 
control.  Sometimes that does not work out well; see RFC 6109.  The 
process is tedious.  It does not have to be like that if people make 
room for agreement.  In simple terms, people can discuss about X for 
the next three years or there can be a short discussion and a 
solution within the next three months.

The summary of the DMARC BoF is at 
According to that message there was agreement for the IETF to take on 
the DMARC base specification.

S. Moonesamy 

S Moonesamy | 15 Apr 01:50 2014

RE: DMARC: perspectives from a listadmin of large open-source lists

Hi Mike,
At 09:53 14-04-2014, MH Michael Hammer (5304) wrote:
>The fact is that a vocal constituency led by John Levine made it 
>extremely clear that MLMs were out of scope and there was zero 
>interest on the part of the MLM community in discussing ways in 
>which MLMs could be made to work in an email authentication 
>framework even if there were any MLM operators willing to do so. His 
>stated solution has been and continues to be that list operators 
>should drop any participants who post from a domain publishing 
>p=reject and to prevent any new participants from joining from a 
>domain that publishes p=reject. The record is quite clear on this 
>and is available to anyone who wishes to peruse email archives, blog 
>posts, etc. I view this as local policy and up to the list operator. 
>I'm not confident how well this will ultimately work for many 
>organizations the operators manage lists for. Just to be clear, the 
>preceding is more of a question than an assertion.

I don't think that there is zero interest from the Mailman community 
(that's my interpretation of the Mailman discussions).  Mailman 
developers do not participate in the IETF.  There is an employee of a 
well-known company who has been arguing for changes to the mailing 
list management software since a long time.  The Mailman patch for 
DMARC was written by Jim Popovitch and Phil Pennock ( 

Mailing list traffic is not significant in comparison with overall 
mail traffic.  At the risk of sounding insensitive there isn't a 
business case for some providers to support mailing list traffic.  I 
would consider John Levine's point about making it out of 
scope.  There's still the problem of what to do about mailing lists.

S. Moonesamy