S Moonesamy | 24 Oct 19:30 2014

Re: Adapting/adopting RFC 7154 for International Conference on Open Repositories


I received a message from the Open Repositories [1] to adopt or adapt 
RFC 7154.  The RFC is restricted to modifications within the IETF 
Standards Process.  Would it be an issue to allow the guidelines to 
be reused outside the IETF?

I would like to suggest proper attribution for the people who 
contributed text as I was merely the editor and to contact the IETF 
Trust for any usage of "IETF".

S. Moonesamy

1. http://sites.tdl.org/openrepositories/

Thomas Narten | 24 Oct 06:53 2014

Weekly posting summary for ietf <at> ietf.org

Total of 93 messages in the last 7 days.

script run at: Fri Oct 24 00:53:03 EDT 2014

    Messages   |      Bytes        | Who
  5.38% |    5 |  9.10% |   113449 | edward.lewis <at> icann.org
  4.30% |    4 |  8.20% |   102273 | ivancic <at> syzygyengineering.com
  6.45% |    6 |  5.63% |    70171 | lizho.jin <at> gmail.com
  2.15% |    2 |  7.98% |    99532 | shollenbeck <at> verisign.com
  4.30% |    4 |  3.05% |    38026 | jmh <at> joelhalpern.com
  2.15% |    2 |  4.62% |    57659 | lloyd.wood <at> yahoo.co.uk
  4.30% |    4 |  2.31% |    28744 | mnot <at> mnot.net
  3.23% |    3 |  3.28% |    40855 | ron.even.tlv <at> gmail.com
  2.15% |    2 |  3.78% |    47143 | david.black <at> emc.com
  3.23% |    3 |  2.60% |    32394 | barryleiba <at> computer.org
  1.08% |    1 |  4.35% |    54211 | eclipticplane2002 <at> yahoo.co.uk
  2.15% |    2 |  3.06% |    38173 | kfall <at> kfall.net
  2.15% |    2 |  2.84% |    35382 | juanfraire <at> gmail.com
  2.15% |    2 |  2.72% |    33970 | sunqi.csnet.thu <at> gmail.com
  2.15% |    2 |  1.55% |    19328 | chair <at> ietf.org
  2.15% |    2 |  1.51% |    18806 | abdussalambaryun <at> gmail.com
  2.15% |    2 |  1.45% |    18024 | daedulus <at> btconnect.com
  2.15% |    2 |  1.19% |    14869 | sm+ietf <at> elandsys.com
  2.15% |    2 |  1.18% |    14656 | ietf-secretariat <at> ietf.org
  2.15% |    2 |  1.17% |    14638 | iab-chair <at> iab.org
  2.15% |    2 |  1.11% |    13872 | jari.arkko <at> piuha.net
  2.15% |    2 |  1.10% |    13656 | stephen.farrell <at> cs.tcd.ie
  2.15% |    2 |  1.08% |    13491 | mcr+ietf <at> sandelman.ca
  2.15% |    2 |  1.07% |    13333 | alexey.melnikov <at> isode.com
(Continue reading)

Barry Leiba | 23 Oct 16:13 2014

Re: Last Call: <draft-leiba-cotton-iana-5226bis-08.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

Hi, SM, and thanks for the review.  Sorry for the delay in responding.

  "For IETF protocols, that role is filled by the Internet
   Assigned Numbers Authority (IANA) [RFC2860]."

Given that there seems to be a service mark for "Internet Assigned Numbers Authority", shouldn't there be an IPR disclosure?

Not that I can tell.  We use "IANA" and its expansion regularly, and I see no reason to change anything about that here (this also goes to your other comments about changing how we refer to IANA).

  "IANA services are currently provided by the International Corporation
   for Assigned Names and Numbers (ICANN)."

According to www.icann.org there is an "Internet Corporation For Assigned Names and Numbers".

Yes, I mis-expanded it (or 5226 did; I'm not bothering to check).  Corrected in my working version.
  'For this document, "the specification" as used by RFC 2119 refers to
   the processing of protocol documents within the IETF standards

There was a thread about registration policies (see http://www.ietf.org/mail-archive/web/ietf/current/msg88598.html ).  My reading of the quoted text is that the key words do not apply to documents in the IRTF and Independent Streams.

This document is about the IETF stream.  It's up to the other streams to specify that this document applies to them as well, and I believe that they do.  There's a lot of stuff that is defined to apply to "the IETF standards process" that other streams also use.

  "In particular, when a registry policy that requires involvement of
   Working Groups, directorates, or other bodies to be actively involved
   and to support the effort, requests frequently run into concerns that
   "it's not worth doing a Standards-Track RFC for something this
   trivial," when, in fact, that requirement was created by the Working
   Group in the first place, by placing the bar that high."

Are directorates involved in registry policy?

They certainly could be.  I don't see a reason not to mention them.
I suggest changing "Standards-Track RFC" to RFC as even an RFC is a high bar and it is a non-trivial requirement.

It's an example of an argument I've actually heard, and I'm inclined to leave it.

In Section 3.3:

  "In order to allow assignments in such cases, the IESG is granted
   authority to override registration procedures and approve assignments
   on a case-by-case basis."

In other words the registry policy used is "IESG Approval".  There is already a good description of that in Section 4.10.  I do not see the need to emphasize that the IESG has the authority to do so.

It seems that Section 3.3 is trying to address a different problem than what is in RFC 7120, i.e. the registration procedure does not adequately cover the reality of registry operation.  For example, there was an RFC published because an email address had to be updated.  It is onerous to go through such an effort for an email address change.  If that happens a few times it is a sign that the registration procedure should be updated.

Indeed, and that's exactly what section 3.3 says: that it's a sign that an update is needed.  I think this section is valuable, and don't think it should be removed or changed.  It's important to talk about the IESG being able to override things where necessary.

Thanks again for the thorough review.


Jari Arkko | 22 Oct 18:36 2014

thoughts on ITU plenipotentiary conference from ISOC

I wanted to pass this along:


There is also a matrix of proposals and their potential impacts:



Bob Hinden | 22 Oct 03:59 2014

*** Final Reminder: "Nerds in Paradise" T-shirt order window closes soon!

*** Final Reminder: "Nerds in Paradise" T-shirt order window closes soon!

The order window closes in about 22 hours at 23:59:00 UTC on October 22, 2014.

Available sizes are Men's and Womens: S, M, L, XL, XXL, XXXL

Color is pink. Print is black, similar to:


Send your order to: nerds <at> ietf.org

Include: Your name, your e-mail address, size and quantity.

You will be required to pay in CASH when collecting your shirt(s) in Honolulu. No mail orders or credit card
payments available.

Bob Hinden Joel Jaeggli Ole Jacobsen

(We promise to stop spamming now)
Martin Stiemerling | 21 Oct 12:08 2014

Re: [dtn] proposed DTN workgroup - what is process being followed?

Hi Lloyd,

Thanks for sharing your concerns and see my replies in the text below:

Am 18.10.14 um 16:27 schrieb Lloyd Wood:
> I see that the Hawaii IETF 91 agenda is out:
> https://datatracker.ietf.org/meeting/91/agenda.txt
> This lists a DTN WG meeting on the Thursday.

It is listed as a WG, as it is expected to be a WG by the start of the 
IETF-91 meeting. Right now, DTN is still in the stage of a proposed 
Working Group, i.e., the final decision if there will be a DTN working 
group is still to be made.

The draft charter for external review has just been sent out on 10/22.

> I am somewhat puzzled by this, as I was under the impression that
> discussion of whether to form a DTN workgroup or not was still underway;
> I thought it was currently blocked.
> https://datatracker.ietf.org/doc/charter-ietf-dtn/ballot/

The charter is not blocked anymore, as the concerns in the IESG got 

I am not sure how to arrive at the impression that the formation of a 
DTN WG is blocked in principle. My personal impression from the BOF 
session at IETF-90 in Toronto was and still is that there is sufficient 
community interest, including multiple vendors that would build on top 
of the DTN protoocls, in moving forward to standardize the DTN protocols.

This is also noted in the meeting minutes and I did double-check the 
audio recordings of the session:

There is sufficient community interest to move this forward, though 
there is no clear plan on how the technical issues for each protocol 
should be addressed. However, the technical issues do not need to be 
addressed in the BOF - that is the task of the WG to be formed.

There have been a number of discussions on the DTNWG mailing list about 
the charter scope and the wording, plus an additional call to clarify 
open issues. The output was the charter on the list that was sent to the 
me as AD and sent to the IESG, modulo tweaks suggested by me.

> I see that concerns about technical direction were raised - but really,
> if it's technically the wrong direction for the proposed group to take,
> does having consensus even help? If it's believed to be technically
> wrong, isn't that a BLOCK?
> This second DTN workgroup discussion is after a first DTN BOF for a
> proposed WG at IETF 90, based on the idea of pushing the problematic
> IRTF Bundle Protocol onto standards track. That was told to go away and
> rethink the idea, and has proposed a slightly reworded charter... based
> on pushing the problematic IRTF Bundle Protocol onto standards track.
> The basic intent under the wordsmithing is unchanged, as far as I can see.

Stephen also expressed his concerns that extending or keep using the 
bundle protocol is his opinion problematic. This can be the case, but 
apparently a community has interest in moving forward with the current 
DTN protocols and standardize them.

> In case I've missed the whole review process and the
> we're-forming-a-DTN-WG-huzzah celebration, I'd just like to remind
> everyone that I had some serious and well-thought-out objections to the
> previous
> we're-pushing-the-problematic-IETF-Bundle-Protocol-onto-standards-track
> charter for the proposed WG.
> Now that the charter has been revised to be a slightly different
> we're-pushing-the-problematic-IETF-Bundle-Protocol-onto-standards-track
> charter, those objections are still entirely valid, as far as I can see.
> I'm in the fortunate position of being outside the US govt program
> world, and not being funded to work on the Bundle Protocol or by anyone
> who thinks bundling is a great idea, so I'm able to offer actual
> concrete opinions. No conflict of interest.
> My concerns break down into:
> - Political - CCSDS thinks the Bundle Protocol is theirs, and has
> already modified the RFC5050 Bundle Protocol further to suit its needs
> in their Blue Book and ancillary protocols that haven't been documented
> in the IRTF or IETF. Thus, either an IETF DTN WG denies that existence,
> or has to cooperate with them - and since CCSDS is the only real Bundle
> Protocol user, forced cooperation it is. Which means modifying anything
> already codified in the CCSDS standards will be very difficult; the aim
> will be to push what is there through as a standard, problems or no.

Concerns about CCSDS using the bunde protocol were raised quite early 
and I am in contact with them to find out where any issues are and how 
we can forward. The right thing to do, will be to send a liaison 
statement from the DTNWG to CCSDS given that the WG is established.

> - Procedural - I haven't seen any discussion of how this political
> cooperation of two very different standards bodies can be made to work
> in practice, and previous history (CCSDS making SCPS diverge from the
> TCP/IP base) suggests it won't; divergence without benefit for the IETF.
> How can a protocol be both CCSDS blue book and IETF standards track,
> when two different groups are pulling it in two different directions?
> Who has authority and change control?

The owner of the protocol has change control and in the case of the DTN 
protocols the current protocol specifications are owned by the IRTF. It 
is always diffculty if there are branches of the protocol spec which are 
not reported and/or ported back to the protocol owner.

I see this as a diffcult point, but not a show stopper. This will need 
serious work on both ends, but I can see that either side, i.e., CCSDS 
and IETF, will do their share.

> - Technical. The Bundle Protocol has some well-documented problems.
> Fixing those while also pushing for standards track and coordinating
> with CCSDS, which will raise already-standard and installed-based
> concerns, frankly seems impossible.

This can be a tough point, but there are two choices: do nothing or 
start working on a solution.

We will see what the outcome is.

> http://www.ietf.org/mail-archive/web/dtn/current/msg00043.html
> http://www.ietf.org/mail-archive/web/dtn/current/msg00054.html
> http://www.ietf.org/mail-archive/web/dtn/current/msg00187.html
> has some expansion on this, and our 'Bundle of Problems' paper lists a
> number of things, while giving a basic tutorial on how you would design
> a transport protocol for difficult environments, that haven't been fixed
> in the DTNRG's Bundle Protocol in the five years since that paper was
> published.
> - Luminal. These should hopefully be enlightening.
> So, can someone please say what process and milestones/dates are being
> followed here. If this is still in the process of making a decision,
> where is it, exactly?

We follow the regular WG chartering process. There is now a proposed 
working group with a draft charter for external review and comment. The 
final decision if the WG will be chartered or not has not been made yet.



S Moonesamy | 20 Oct 01:28 2014

Re: Media type for PGP message?

Hi Tim,
At 08:10 17-10-2014, Tim Bray wrote:
>I'm actually a little out of touch with the drill on a media-type
>registration daft.  Does it need a WG?

The short answer is no.

You could send the registration request (RFC 6838) to 
https://www.ietf.org/mailman/listinfo/media-types and run the draft 
through apps-discuss <at> ietf.org if you are aiming for a RFC.  I suggest 
contacting one of the Application Area Directors for the process details.

S. Moonesamy 

Jari Arkko | 19 Oct 07:47 2014

Re: proposed DTN workgroup - what is process being followed?


Good question. It is customary that working groups being proposed to be created (like DTN is) are given a
slot in the schedule. If the working group creation goes through before the meeting, the slot will be a
regular working group meeting. If it does not go through, depending on circumstances we’d either run
the meeting as a BOF or cancel it.

That was the process part. I’ll let others comment on the substance part of your comments.


IETF Chair | 18 Oct 05:38 2014

Budget and fees for 2015

Some time ago we asked the community about IETF meeting fees and the possible
need to raise them due to increasing costs. 

I wanted to inform you that this week the IAOC has adopted the IETF 2015 budget
and 2016 - 2017 budget projections. The budget has been submitted to ISOC
as a part of their overall budget process that is ongoing. 

All information is available at


The budget includes the increased registration fees from 2014 to 2015 as follows:

Early Bird               $650 to $700
Late Registration    $800 to $875
Day Pass                $350 to $375
Student (Full Time) $150 to $150

Jari Arkko
IETF Chair

Ole Jacobsen | 18 Oct 03:32 2014

*** Reminder and update "Nerds in Paradise" T-shirts ***

**** UPDATE: We will offer women's style T-shirts as well as the 
originally announced range of sizes. If you have already ordered
and would like to make a change, please respond with the details.

**** REMINDER: The deadline is approaching, send in your order today!

Dear IETF 91 Attendee,

Twenty-five years ago, the IETF met in Honolulu for IETF 15. This was 
long before the days of hosts and sponsors and thus long before there 
were any official T-shirts for attendees.

A small group of IETFers got together and decided that it would be fun 
to create a T-shirt. The now-famous "Nerds in Paradise" imprint was 
designed by Julia Topolcic and became, as far as we know, the first 
IETF shirt ever. It was printed locally in Honolulu and distributed to 
those who had signed up for it.

This is what the shirt looked like: 


To commemorate IETF 15 and that T-shirt, we are planning to produce a 
Version 2.0 in the same ad hoc fashion, based closely on the original 
design. The cost per T-shirt will about US $ 15.00, priced to offset 
the cost of this excercise. The final price will depend on how many 
shirts we order. If there are surplus funds, we will donate them to 
the Open Internet Endowment:


If you wish to pre-order, please let us know what size and how many 
you want by 23:59:00 UTC on October 22, 2014. Available sizes are:
Men's and Women's: S, M, L, XL, XXL, XXXL. 

Send your order to: nerds <at> ietf.org. You will be required to pay in
CASH when collecting your shirt in Honolulu. We expect to distribute
the shirts on Sunday afternoon, November 9. 

Mail orders are NOT available, we suggest you ask an IETF 91 attendee
to collect the shirt for you if you are unable to attend in person.

See you in Honolulu!

Bob Hinden
Joel A. Jaeggli
Ole J. Jacobsen

IETF Agenda | 18 Oct 02:25 2014

IETF 91 Final Agenda

91st IETF Meeting - Honolulu, HI, USA
November 9 - 14, 2014

The final agenda is now available.


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 91st IETF meeting in Honolulu, HI, USA can be found here: https://www.ietf.org/meeting/91/index.html

Thank you and see you in Honolulu!


The IETF Secretariat