John C Klensin | 3 Jul 20:06 2015

Procedural queston (was: Re: Call for comment: <draft-iab-doi-04.txt> (Assigning Digital Object Identifiers to RFCs))

Question about the status of this document.

The document is listed as having a single author.  The IAB has
issued a call for comments, which I assume means that the IAB
intends to publish in the IAB Stream.  Is the intent to add the
IAB as author and attach the usual IAB stream trimmings to
indicate that the IAB is taking responsibility for it?  Or to
modify the document to indicate that it is being published by
the IAB at the request of the RFC Series Editor?  If the answer
to both questions is "no", why is this in the IAB stream rather
than being handled as an independent submission?


Russ Housley | 3 Jul 16:05 2015

Gen-ART Review of draft-ietf-tzdist-service-09

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

This review is in response to a request for early Gen-ART review.

Document: draft-ietf-tzdist-service-09
Reviewer: Russ Housley
Review Date: 2015-06-05
IETF LC End Date: 2015-06-17
IESG Telechat date: 2015-07-09

Summary: Ready

Major Concerns:  None

Minor Concerns:  None

Other Comments:  Thanks for addressing my comments on the previous version.

Benoit Claise | 3 Jul 08:22 2015

Posting a draft with a YANG model

Dear all,

If you plan on posting a draft with a YANG model, please run this draft 
It will extract and compile the YANG model for you, according to the RFC 
6087 rules ("pyang --ietf" option).
Next, the tools behind, i.e. 
pyang and xym, will be integrated in idnits. This is planned for this 
coming IETF 93 hackathon/code sprint.

Regards, Benoit

Jinsong Wu | 2 Jul 21:26 2015

Extended deadline July 15 - CFP: IEEE Green Standardization and Industry Issues at Globecom 2015


IEEE International Workshop on Green Standardization and Industry
Issues for ICT and Relevant Technologies (GSICT)
Organized in conjunction with IEEE Global Communications Conference

[Paper submission link]

[Important Dates on US Time EDT]
– Extended paper submission deadline: July 15, 2015
– Paper Acceptance Notification: September 1, 2015
– Camera Ready papers due: October 1, 2015

[Scope and Topics]

This workshop is to collect results and visions of standards,
regulations, policies, industry issues and efforts on global green
revolutions relevant to information and communication technologies
(ICT) and other relevant issues, including both the impact of ICT on
the environments and the impact of environments on ICT. This workshop
will exchange views on issues of strategic importance such as
environmental protections, resource efficiency, climate changes, and
energy efficiency, and how ICT can help boost the transition to an
environmentally-friendly economy. Environmental sustainability for the
ICT sector has impacted and will continue impacting the industry’s
reaction to the outcomes of the United Nations Conference on
Sustainable Development (Rio+20). The current world would not survive
without information and communication technologies, whose widespread
use has changed people’s lives dramatically and boosted economic
growth. However, the very success of these technologies has made them
a growing contributor to various environmental impacts. At the same
time, they may offer ways of reducing negative environmental impacts
in other industries such as water resource management, air pollution
reduction, energy generation, building and transport. This workshop
may also provide guidance on green ICT procurement, detailing green
principles to be applied when procuring goods, products and services.
Another issue considered in this workshop is greening ICT supply
chains relating to conflict minerals, and the way the ICT industry is
managing its supply chain in that context. This workshop may also
investigate the overall sustainability of lifestyle choices, a number
of companies may have responded by providing consumers with
information on the eco-impact of the products they buy and use.

The IEEE International Workshop on Green Standardization and Industry
Issues for ICT and Relevant Technologies (GSICT) would be initiated as
a forum for scientists, engineers, standardization professionals,
policy makers, researchers, practitioners, and students to present
their latest research results, visions, ideas, developments, surveys
in green standardization and industry issues in ICT and relevant
technologies that can support existing and future developments and
efforts and promote global green revolutions.

Researchers and professionals are encouraged to submit original
relevant contributions in all major areas, which include, but not
limited to:

– Green standardizations for systems, devices, interfaces, adapters
– Green algorithms, protocols, approaches, solutions for any
industrial ICT standards and relevant systems
– Green issues, activities, efforts, approaches, and applications in industries
– Visions, ideas, roadmaps, and solutions on green standardization and
industry issues for ICT and relevant technologies
– Test suites for assessment of green standardizations and solutions
– Green battery solutions
– Green standardization and industry issues for computing and
information technologies
– Green standardization and industry issues for electronics
– Green standardization and industry issues for Internet of things
– Green standardization and industry issues for smart grids
– Green standardization and industry issues for communications and networking
– Procedure for recycling materials in information and communication
technology goods
– Measurement methods to characterize rare metals in information and
communication technology goods
– Best practices for green data centers and cloud computing
– Energy and resource efficiency metrics and measurement
– Standardizations for green offices and buildings
– Overview and general principles of methodologies for assessing the
environmental impact of information and communication technologies
– Methodology for environmental life cycle assessment
– Methodology for energy consumption and greenhouse gas emissions
impact assessment of information and communication technologies in
– Framework for information and communication technologies and
adaptation to the effects of climate change
– Life-cycle management of ICT goods
– Surveys on any topics of green standardization and industry issues

[Submission Procedure]

Submitted papers must represent original material which is not
currently under review in any other conference or journal and has not
been previously published. Paper length should not exceed 7-pages (6
pages without extra page charge) standard IEEE conference two-column
format (including all text, figures, and references). Please see the
Author Information page for submission guidelines in the IEEE GLOBECOM
2015 web site All submitted
papers will go through a peer review process. All accepted and
presented papers will be included in the IEEE GLOBECOM 2015
proceedings and IEEE digital library. IEEE reserves the right to
exclude an accepted and registered but not presented paper from the
IEEE digital library.

John C Klensin | 2 Jul 20:38 2015

Registry for "info" URI type


In doing a bit of research for the recent discussion of DOIs on
the IETF list, I discovered (again) that:

There is an "info" URI Scheme, listed in the registry at
"info" is defined in RFC 4452, which is referenced, as having a
separate registry of public namespaces.  IANA does not maintain
that registry (unlike the registries for assorted parameters and
tokens for some other URI types.

There is no hint on the IANA pages that such a subsidiary
registry exists or where to find it.  It appears to me that
there should.  That is probably a policy matter for IANA and the
community but I urge that it be considered.

The question is particularly important at this point for at
least two and possibly three reasons:

(1) The registry to which RFC 4452 points,, identifies a five-year-old page that
states that the registry is closed to new registrations and
contains language that can be construed as generally deprecating
the "info" scheme.

(2) The registry itself (link on the above page), contains
registration entries for "info:ark", "info:doi", "info:hdl", and
a rather large number of other identifier systems, several of
which might be appropriate for identification of IETF documents
and other digital resources.

(3) At least part of the explanation given in RFC 4452 about why
an "info" scheme is needed rather than using "urn" scheme
namespace registrations will soon be obsolete given changes that
are in progress in the URNBIS WG.   If NISO (the organization
designated by RFC 4452 as responsible for the registry) and OCLC
(the organization actually managing the registry) are convinced
that the "info:" scheme has outlived its usefulness (as the link
in (1) implies), than either we should be working with them to
deprecate (or at least issue an Applicability Statement about)
RFC 4452 and the scheme and/or should be considering whether it
would be useful to convert some or all of the identifiers into
URN namespaces.


An aside:  As far as I can tell, the "info" scheme and the
namespaces it supports are precisely an example of comment in
RFC 3896 about Uniform Resource Names that are not part of the
"urn:" scheme.  That comment has been the source of a lot of
trouble and confusion; it is not clear to me whether this
concrete example makes things better or worse.

Bernard Aboba | 2 Jul 02:15 2015

RE: [new-work] WG Review: Selection of Language for Internet Media (slim)

I believe that this Charter is poorly suited to developing solutions to the problem faced by disabled users of realtime emergency services.  

In the case of access to emergency services by the disabled, the goal is not "selection of the best-fit language", but rather, routing of the call and media so as to pull together the services best fitting the emergency situation and the disabilities of the caller, as well as the capabilities of the device and intermediaries which may sit between the caller and the PSAP.  Not only are media and language intrinsically linked, but also, the ways in which calls are routed is influenced and in some cases prescribed by regulation and national standards.  

Simply put, draft-gellens-slim-negotiating-human-language lacks appropriate consideration of the problem context.  Specifying it as the starting point is therefore inappropriate. As an example, today the call flow described in Section 4.5 would most likely result in rejection of the video portion of the call by the PSAP, leaving the dispatcher with no means of communicating with the hearing-impaired caller, thus leaving the caller worse off than they are today attempting to make an emergency call within the (cumbersome and error/delay-prone) Video Relay Service.   A fuller consideration of the problem context would involve consideration of current operation of relay services and proposals for their evolution.  Attempting to develop this problem context within a WG that is also attempting to deal with language-selection in email would be frustrating at best. 

A sensible Charter would also probably include liaisons with disability rights organizations, groups specifying the operation of relay services, and groups considering next steps for access to emergency services. 

> From: iesg <at>
> To: new-work <at>
> Date: Fri, 26 Jun 2015 08:36:05 -0700
> Subject: [new-work] WG Review: Selection of Language for Internet Media (slim)
> A new IETF working group has been proposed in the Applications and
> Real-Time Area. The IESG has not made any determination yet. The
> following draft charter was submitted, and is provided for informational
> purposes only. Please send your comments to the IESG mailing list (iesg
> at by 2015-07-06.
> Selection of Language for Internet Media (slim)
> ------------------------------------------------
> Current Status: Proposed WG
> Assigned Area Director:
> Barry Leiba <barryleiba <at>>
> Mailing list
> Address: slim <at>
> To Subscribe:
> Archive:
> Charter:
> Description of Working Group:
> A mutually comprehensible language is helpful for human communication.
> This is true across a range of circumstances and environments. In
> general, the problem is most acute in situations where there is not a
> clear choice for a single language, such as environments lacking
> contextual or out-of-band information regarding the identity of the
> parties and the language to be used.
> The group will address two specific cases that most urgently need a
> technical solution: One problem space is non-real-time communication,
> specifically email for one-to-many or where the set of recipients is
> dynamic or different recipients require different languages; the other is
> real-time communication, specifically emergency calling, preferably also
> useful for other cases where the parties may not know each other
> personally or where one party wishes to accommodate people with varying
> language and media needs.
> In the real-time communication case, language and media are intrinsically
> linked, for example, signed languages require a video media.
> While the two use cases are in different contexts (real time and
> non-real-time), the fundamental goal is the same: to enable selection of
> the best-fit language(s) for a specific situation. Some of the details
> will also be in common across the cases, e.g., the language tags. Having
> a single WG address both cases makes it clear that these are two aspects
> of the same basic problem. A single WG also makes it easier to maximize
> similarities and avoid unnecessary fragmentation of the solutions, and
> facilitates broader review.
> The group will produce two documents, one for email, and one for
> real-time communications.
> In the email case, the group will determine a MIME based solution that
> enables a single email message to contain multiple language versions of
> the content, with provisions to help clients select a best fit version.
> In the real-time communication case, the group will produce a
> specification based on draft-gellens-slim-negotiating-human-language,
> enabling negotiation of a human language per media stream. The
> specification must be suitable for use in emergency communications as
> specified in RFC 6443 and RFC 6881 (which use SIP and SDP to negotiate
> media); it is desirable to also be suitable for use in non-emergency
> real-time communications that share the same call set-up and media
> negotiation protocols. The mechanism will permit the caller's media and
> language needs and preferences to be matched against what the called
> party is able to provide. The mechanism will permit resources (e.g.,
> translation, relay, media) to be allocated or engaged as early as
> possible in the call set-up or for the call to be routed or handled
> specially (e.g., routed to a resource able to provide a needed language
> and/or media). Alternatives such as doing the negotiation in SIP have
> been thoroughly explored in the past and are out of scope (although the
> scope might be extended after the SDP mechanism has been advanced).
> By adding language to the existing media negotiation mechanism as used in
> RFC 6443 and RFC 6881, the group can meet the basic use cases with
> minimal added complexity and be able to enhance later for additional use
> cases as needed.
> Milestones:
> Oct 2015 - Submit "Multiple Language Content Type" to the IESG (based
> on draft-tomkinson-slim-multilangcontent)
> Feb 2016 - Submit "Negotiating Human Language in Real-Time
> Communications" to the IESG (based on
> draft-gellens-slim-negotiating-human-language)
> _______________________________________________
> new-work mailing list
> new-work <at>
IAB Chair | 1 Jul 20:34 2015

Call for comment: <draft-iab-doi-04.txt> (Assigning Digital Object Identifiers to RFCs)

Dear colleagues,

This is an announcement of an IETF-wide Call for Comment on

The document is being considered for publication as an Informational RFC
within the IAB stream, and is available for inspection here:

The Call for Comment will last until 2015-07-29. Please send comments to
iab <at>

Best regards,
Andrew Sullivan
IAB chair
On behalf of the IAB

Roni Even | 1 Jul 20:02 2015

Gen-ART LC review of draft-ietf-bmwg-issu-meth-01

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <>.

Please resolve these comments along with any other Last Call comments you may receive.

Document:  draft-ietf-bmwg-issu-meth-01
Reviewer: Roni Even

Review Date: 2015–7-1

IETF LC End Date: 2015–7-2

IESG Telechat date:


Summary: This draft is ready for publication as an Informational  RFC.



Major issues:


Minor issues:


According to the abstract this document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event. My reading is that it captures the typical procedures and as such is an informational document. It does not recommend any specific procedure yet it RECOMMEND in section 7 defines normative recommendation of which parameters SHOULD be reported in what I understand is a written statement.  I was wondering if all parameters are needed and when you can report only part of them , maybe just make it non normative


Nits/editorial comments:


Randy Bush | 30 Jun 10:16 2015

sigcomm handles newcomers

it is a smaller conference, but has a proportionally bigger breeding age
crowd.  first year demand was light.  but it is an admirable step.


IETF Agenda | 27 Jun 02:08 2015

IETF 93 Final Agenda

IETF 93 - Prague, Czech Republic
July 19 - 24, 2015

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 versions of the agenda. 

Information about IETF 93 in Prague can be found here:

Thomas Narten | 26 Jun 06:53 2015

Weekly posting summary for ietf <at>

Total of 75 messages in the last 7 days.

script run at: Fri Jun 26 00:53:01 EDT 2015

    Messages   |      Bytes        | Who
  2.67% |    2 | 41.15% |   443309 | robert.w.withers <at>
 12.00% |    9 |  5.23% |    56336 | touch <at>
  5.33% |    4 |  4.49% |    48394 | phill <at>
  5.33% |    4 |  2.99% |    32197 | john-ietf <at>
  4.00% |    3 |  3.20% |    34425 | adrian <at>
  4.00% |    3 |  2.13% |    22966 | rg+ietf <at>
  4.00% |    3 |  2.13% |    22951 | pierre.francois <at>
  4.00% |    3 |  1.78% |    19145 | johnl <at>
  4.00% |    3 |  1.77% |    19041 | mnot <at>
  4.00% |    3 |  1.50% |    16178 | randy <at>
  2.67% |    2 |  1.80% |    19348 | eckert <at>
  2.67% |    2 |  1.61% |    17306 | peter <at>
  1.33% |    1 |  2.87% |    30867 | jwu_res <at>
  2.67% |    2 |  1.52% |    16337 | rjsparks <at>
  2.67% |    2 |  1.47% |    15802 | harald <at>
  1.33% |    1 |  2.68% |    28868 | dmznr <at>
  2.67% |    2 |  1.34% |    14423 | joelja <at>
  1.33% |    1 |  1.43% |    15433 | allison.mankin <at>
  1.33% |    1 |  1.32% |    14244 | jordi.palet <at>
  1.33% |    1 |  1.03% |    11073 | mstjohns <at>
  1.33% |    1 |  0.97% |    10398 | erosen <at>
  1.33% |    1 |  0.92% |     9873 | serrhini <at>
  1.33% |    1 |  0.87% |     9409 | matthew <at>
  1.33% |    1 |  0.86% |     9288 | clint.chaplin <at>
  1.33% |    1 |  0.86% |     9263 | huitema <at>
  1.33% |    1 |  0.85% |     9124 | sebastien.klahr <at>
  1.33% |    1 |  0.83% |     8922 | dave <at>
  1.33% |    1 |  0.81% |     8701 | narten <at>
  1.33% |    1 |  0.80% |     8574 | execd <at>
  1.33% |    1 |  0.78% |     8450 | dharkins <at>
  1.33% |    1 |  0.73% |     7909 | woody <at>
  1.33% |    1 |  0.70% |     7586 | job <at>
  1.33% |    1 |  0.67% |     7246 | jabley <at>
  1.33% |    1 |  0.66% |     7107 | ynir.ietf <at>
  1.33% |    1 |  0.66% |     7100 | lars <at>
  1.33% |    1 |  0.65% |     7037 | faber <at>
  1.33% |    1 |  0.64% |     6917 | olejacobsen <at>
  1.33% |    1 |  0.62% |     6700 | nico <at>
  1.33% |    1 |  0.58% |     6196 | ahmedbakhat <at>
  1.33% |    1 |  0.57% |     6162 | mcr <at>
  1.33% |    1 |  0.57% |     6135 | go.awofadeju <at>
  1.33% |    1 |  0.53% |     5674 | cos <at>
  1.33% |    1 |  0.46% |     4962 | agenda <at>
100.00% |   75 |100.00% |  1077376 | Total