Ole Jacobsen | 2 Sep 22:57 2015

Updated area map for IETF 94


Hi,

The good folks at WIDE have put together a new Google map which you 
can see by following the link "Alternative Hotels Map" at:

 http://ietf.org/meeting/94/index.html

This map is "hand made" rather than auto-generated from a search and
includes the all the contracted overflow hotels [1] and additional 
local 
information such as:

* Transportation (train stations)
* Shops and restaurants
* Post Office, ATMs
* Sight-seeing (for example The Cup Noodle Museum)

This isn't the "final word" on local information and will likely
evolve and improve as we get closer to IETF 94.

[1] You can find even more hotels by using a standard Google map 
search.

60 days until IETF 94!

Ole

Ole J. Jacobsen
Editor and Publisher
(Continue reading)

Robert Sparks | 2 Sep 16:20 2015

Summary of LC comments (so far) on RFC1984 to BCP

Here is my summary of the last call discussion on
status-change-rfc1984-to-best-current-practice
so far for comment

The last call is open for a few more days.

A relatively high number of comments were sent in response
to this last call.

Many participants expressed support for this status change,
including people that were IAB or IESG members when RFC1984
was published. The current IAB expressed support for the
change.

Several people expressed concern that it was not clear why
this change was proposed. The relevance of citing RFC20's
status change was questioned. The discussion resulted in
agreement to remove the mention of RFC20. The remaining
text should focus clearly on the motivations for making the
change. It was suggested to explicitly note in the
status-change document that this is an exceptional action,
but that it falls within the processes laid out by RFC2026.

Concern was expressed that it would be difficult to find
the history explaining this change. A note in the tracker
is a difficult artifact find, or even to know to look for.
It was pointed out that the RFC Editor maintains a list
of approved status changes at
<status-change-rfc1984-to-best-current-practice>.
The IESG should consider further changes to improve
(Continue reading)

Adam Roach | 2 Sep 16:17 2015

Blog: NETVC goals and status

IETF [bcc NETVC working group]:

The IETF blog has a brief post up about the goals and status of the IETF 
NETVC (Internet video codec) work now underway:

http://www.ietf.org/blog/2015/09/aiming-for-a-standardized-high-quality-royalty-free-video-codec-to-remove-friction-for-video-over-the-internet/

/a

Dave Crocker | 2 Sep 03:48 2015
Picon

Fwd: New Version Notification for draft-crocker-rfc2418bis-wgguidelines-01.txt

G'day,

Last Spring, Ralph and I submitted the initial version of a draft
revision to Working Group Guidelines and Procedures.

As the draft explains:

> 1.1.  Background
> 
>    This version is organized as an aid to (new) working group
>    participants both as an introduction and as a later reference.
> 
>    o  It describes existing IETF rules and practices and does not
>       describe or suggest any changes.
> 
>    Specifically this version of the document:
> 
>    o  Replaces general IETF tutorial material that it had with pointers
>       to independent versions
> 
>    o  Incorporates work from a number of targeted efforts over the years
> 
>    o  Reorganizes content to aid direct use by working group
>       participants
> 
>    o  Distinguishes between formal IETF requirements and processes,
>       versus common practices chosen by working groups, where the latter
>       are primarily discussed in a non-normative external IETF Wiki
>       (Appendix C) that can be continually revised by the community.

(Continue reading)

John Levine | 1 Sep 18:39 2015

Who do I talk to about the new mail archive?

I have a niggle about the bulk message download.

Tnx,
John

E Taylor | 29 Aug 02:16 2015

Re: Last Call: <draft-ietf-dane-openpgpkey-05.txt>

Hello,

The -05 draft looks good to me, but I've found a couple of typos /
consistency issues, and I have one recommendation for a functional
change.  This latter issue is one that has been discussed before, but I
wanted to make the point from my perspective here:

I think that, in practice, software that makes OPENPGPKEY lookups is
going to:
* check if the lookup fails, then
* detect if the email address being looked up contains any
capitalisations, and if so
* check if the lowercase version of the email address has an OPENPGPKEY
record available.
If it does find a record for the lowercase version in this situation,
the software's interface is going to prompt the user to ask if they are
happy to accept the lowercase version instead.  For non-interactive
lookups, I imagine there will be a config option (perhaps defaulting to
false or an empty list of domains) which determines whether the software
does this obvious best-effort lookup rather than failing.

Therefore my recommendation is that the draft add language saying that
implementers MAY attempt to look up the lowercase version of an email
address if the value entered by the user fails, but use it only if the
user has made some explicit confirmation that this is a reasonable thing
to do.  Mandating that software do something less useful, against the
user's wishes, in all circumstances, seems like too much to ask.

The more minor issues I list below:

(Continue reading)

Thomas Narten | 28 Aug 06:53 2015
Picon

Weekly posting summary for ietf <at> ietf.org

Total of 33 messages in the last 7 days.

script run at: Fri Aug 28 00:53:02 EDT 2015

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  9.09% |    3 | 22.55% |    81496 | ramon.casellas <at> cttc.es
  9.09% |    3 |  7.26% |    26230 | superuser <at> gmail.com
  9.09% |    3 |  6.61% |    23898 | rjsparks <at> nostrum.com
  6.06% |    2 |  4.06% |    14672 | olejacobsen <at> me.com
  3.03% |    1 |  6.72% |    24277 | dieter.sibold <at> ptb.de
  3.03% |    1 |  3.51% |    12694 | david.somers-harris <at> rakuten.com
  3.03% |    1 |  3.47% |    12556 | david.black <at> emc.com
  3.03% |    1 |  3.28% |    11868 | narten <at> us.ibm.com
  3.03% |    1 |  3.21% |    11598 | rpelletier <at> isoc.org
  3.03% |    1 |  3.19% |    11536 | suresh.krishnan <at> ericsson.com
  3.03% |    1 |  2.93% |    10578 | alexander.vainshtein <at> ecitele.com
  3.03% |    1 |  2.84% |    10272 | jiangsheng <at> huawei.com
  3.03% |    1 |  2.64% |     9528 | housley <at> vigilsec.com
  3.03% |    1 |  2.57% |     9283 | abdussalambaryun <at> gmail.com
  3.03% |    1 |  2.52% |     9123 | marka <at> isc.org
  3.03% |    1 |  2.50% |     9034 | nomcom-chair-2015 <at> ietf.org
  3.03% |    1 |  2.43% |     8795 | jcurran <at> istaff.org
  3.03% |    1 |  2.30% |     8319 | tjc <at> ecs.soton.ac.uk
  3.03% |    1 |  2.21% |     7980 | lear <at> cisco.com
  3.03% |    1 |  2.20% |     7949 | pds <at> lugs.com
  3.03% |    1 |  2.18% |     7877 | d3e3e3 <at> gmail.com
  3.03% |    1 |  2.06% |     7451 | jari.arkko <at> piuha.net
  3.03% |    1 |  1.98% |     7170 | hildjj <at> cursive.net
  3.03% |    1 |  1.61% |     5814 | hosnieh.rafiee <at> huawei.com
(Continue reading)

Robert Sparks | 26 Aug 22:38 2015

SecDir review for draft-ietf-conex-destopt-09

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: On the right track with open issues

I was also the Gen-Art reviewer for this draft
My Gen-Art Review can be found here:
<http://mailarchive.ietf.org/arch/msg/gen-art/kxvhQcl3d2fS5aX_4nXUqGRBy0w>
Please skim that review if you have not already seen it for context.

This document defines a new IPv6 Destination Option. It relies on AH to 
detect any tampering (particularly removal) with the option.

The document is currently formulated to simply define the option, and 
leaves it to other documents to describe when to use the option and how 
audit mechanisms in protocols that use the option can protect themselves 
from likely attacks. If the document clarifies that the option must not 
be used except by a protocol that has defined these things, I believe 
sufficient effort has been put into the security considerations. If the 
group intends for this option to be usable without such an additional 
protocol definition, this document needs to contain more discussion.

Alexander Vainshtein | 26 Aug 09:25 2015

RE: [Pals] Last Call: <draft-ietf-pals-vccv-for-gal-05.txt> (Using A Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator) to Proposed Standard

Hi all,
I have read the latest version of the draft and support making it a Proposed Standard RFC

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein <at> ecitele.com

-----Original Message-----
From: Pals [mailto:pals-bounces <at> ietf.org] On Behalf Of The IESG
Sent: Wednesday, August 26, 2015 1:19 AM
To: IETF-Announce
Cc: pals <at> ietf.org
Subject: [Pals] Last Call: <draft-ietf-pals-vccv-for-gal-05.txt> (Using A Generic Associated
Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator) to Proposed Standard

The IESG has received a request from the Pseudowire And LDP-enabled Services WG (pals) to consider the
following document:
- 'Using A Generic Associated Channel Label as a Virtual Circuit
   Connectivity Verification Channel Indicator'
  <draft-ietf-pals-vccv-for-gal-05.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please
send substantive comments to the ietf <at> ietf.org mailing lists by 2015-09-08. Exceptionally, comments
may be sent to iesg <at> ietf.org instead. In either case, please retain the beginning of the Subject line to
allow automated sorting.

Abstract
(Continue reading)

Ray Pelletier | 25 Aug 10:49 2015

Reg Fee Discount for W3C TPAC Meeting in Sapporo

All;

We are pleased to announce that, as part of an effort to encourage
cross-pollination, the W3C is offering a 50% registration fee
discount to attend the upcoming TPAC 2015 meeting in Sapporo, Japan
(October 26-30) to members of the IETF community who have not
attended a W3C meeting in the last five years. The cost to attend is
$42.50 per day if you pay by October 7. Registrations that remain
unpaid after October 7 will increase to $85 per day.

If you are interested in this opportunity, please register using
this URL: https://www.w3.org/2015/11/tpac_ietf_reg.

The TPAC 2015 schedule is at
http://www.w3.org/2015/10/TPAC/schedule.html.  Please note that the
50% discount only applies to those who have not attended a W3C
annual meeting in the last five years.

The IETF is offering a reciprocal 50% registration fee discount to
IETF 94 for W3C members who have not attended an IETF meeting since
November 2013.

Ray
IAD

Murray S. Kucherawy | 25 Aug 06:01 2015
Picon

NomCom procedures revision

Some months ago I started the work of editing a revision to the NomCom procedures (RFC7437bis).  We made progress on some points, but seem to have stalled on revising the requirements for qualifying to serve on NomCom.

The draft I have recently expired.  Is there any interest in taking another run at this now?  Alternatively, is it worth publishing what we did accomplish, and leaving that one point for a later attempt?

http://datatracker.ietf.org/doc/draft-kucherawy-rfc7437bis/

-MSK

Gmane