John C Klensin | 13 Feb 05:01 2016

draft-klensin-iaoc-member-01 (was: Re: I-D Action: draft-hardie-iaoc-iab-update-00.txt)


Largely in response to the call from Andrew and others to post
an actual I-D with an alternate proposal, I've just posted
draft-klensin-iaoc-member-01.  Note that this is a -01 version
of one of the proposals, referred to in a few postings, to
reform the IAOC membership (and the IAB and IETF Chair roles in
it) a few years ago.   It differs from the earlier version in
several respects, but the most important one is that it contains
considerable discussion and rationale for what is being
proposed, probably saving readers of this list some rather long
email messages from me.

A few things it does not address, or makes proposals about, that
are different from what I think have been trends on the list are
worth calling out:

--On Wednesday, February 03, 2016 15:30 +1300 Brian E Carpenter
<brian.e.carpenter <at>> wrote:

> I think the IETF Chair slot is a different matter. Yes, the
> IETF Chair is also the IESG Chair, but I don't believe s/he is
> in the IAOC on behalf of the IESG. On the contrary, it's on
> behalf of the IETF. I think it's exactly right that the IETF
> Chair votes in the IAOC, because nobody else has the same
> overview, and also because I believe that any IETF Chair who
> did not closely track the IAOC's business would be
> irresponsible.

I believe most of the reasoning above but not the conclusion.
(Continue reading)

Thomas Narten | 12 Feb 06:53 2016

Weekly posting summary for ietf <at>

Total of 147 messages in the last 7 days.

script run at: Fri Feb 12 00:53:01 EST 2016

    Messages   |      Bytes        | Who
 11.56% |   17 | 10.68% |   143911 | phill <at>
 10.20% |   15 |  7.63% |   102862 | touch <at>
  8.84% |   13 |  6.93% |    93365 | fgont <at>
  6.80% |   10 |  4.91% |    66113 | mohta <at>
  3.40% |    5 |  4.55% |    61265 | brian.e.carpenter <at>
  2.72% |    4 |  3.87% |    52121 | warren <at>
  3.40% |    5 |  2.64% |    35621 | ned+ietf <at>
  2.72% |    4 |  3.17% |    42650 | john-ietf <at>
  2.72% |    4 |  2.91% |    39240 | al4321 <at>
  2.04% |    3 |  3.29% |    44318 | douglasroyer <at>
  2.72% |    4 |  2.50% |    33635 | marka <at>
  2.72% |    4 |  2.42% |    32658 | ietf-dane <at>
  1.36% |    2 |  3.60% |    48513 | rbonica <at>
  2.04% |    3 |  2.80% |    37698 | mstjohns <at>
  2.04% |    3 |  2.29% |    30860 | ynir.ietf <at>
  2.04% |    3 |  2.02% |    27224 | peter <at>
  2.04% |    3 |  1.93% |    26002 | ajs <at>
  2.04% |    3 |  1.91% |    25774 | jari.arkko <at>
  2.04% |    3 |  1.91% |    25738 | fred.l.templin <at>
  1.36% |    2 |  1.79% |    24061 | lear <at>
  1.36% |    2 |  1.36% |    18372 | ggx <at>
  1.36% |    2 |  1.36% |    18370 | jeff.hodges <at>
  1.36% |    2 |  1.19% |    16077 | barryleiba <at>
  0.68% |    1 |  1.87% |    25145 | paitken <at>
(Continue reading)

Doug Royer | 11 Feb 23:10 2016

IAB <at> mailing list closed, yet asks for comments?

iab <at> is a closed list for members only. So why are they asking
for comments on IETF lists?

Its a bit confusing, a post to the ietf-announce mailing list called for
comments to be sent to: iab <at>

 "...Please send comments to iab <at> For comments on individual
   drafts, please include the relevant document filename in the subject
   line. ...."

What's the point of the request if we can't participate in the
discussion or know if their are points to reply to?

(Copy of original email below...)

> From: IAB Executive Administrative Manager <execd <at>>
> To: "IETF Announcement List" <ietf-announce <at>>

This is an announcement of an IETF-wide Call for Comment on
the RFC Format Drafts. These documents are being considered for
publication as Informational RFCs within the IAB stream.  The suggested
reading order is:

1. The big picture

- - - Flanagan, H., "RFC Format Framework",

2. The underlying vocabulary
(Continue reading)

Kari Hurtta | 10 Feb 16:51 2016

Last Call: <draft-ietf-httpbis-alt-svc-12.txt> "reasonable assurances" on Host Authentication and "h2c"

I sent yesterday comment about draft-ietf-httpbis-alt-svc-12.txt
to ietf-http-wg <at> and authors. Just before annoucement.

Seems that this is now correct place. So I resend it. This is
combination of two messages.


| 2.1. Host Authentication
|   Clients MUST have reasonable assurances that the alternative service
|   is under control of and valid for the whole origin.

I have impression that on absence of other protocol, this is mean to
forbid use plain HTTP/2 (ie "h2c"), because there is no "reasonable

But is reader understanding that? There is examples which use "h2c".

This does not give that

|                                   However, if "" is
|   offered with the "h2c" protocol, the client cannot use it, because
|   there is no mechanism in that protocol to establish the relationship
|   between the origin and the alternative.

(Continue reading)

=JeffH | 9 Feb 01:09 2016

Re: wrt draft-ietf-uta-email-tls-certs

Hi Alexey,

 >On 02/02/2016 00:54, =JeffH wrote:
 >> I was taking a look at wrt draft-ietf-uta-email-tls-certs and noted that
 >> it says this in Section 3..
 >>    [...]
 >>                                        Matching is performed according
 >>    to the rules specified in Section 6 of [RFC6125], including the
 >>    relative order of matching of different identifier types,
 >>    "certificate pinning" and the procedure on failure to match.  The
 >>    following inputs are used by the verification procedure used in
 >>    [RFC6125]:
 >>    [...]
 >>    The rules and guidelines defined in [RFC6125] apply to an email
 >>    server certificate, with the following supplemental rules:
 >>    [...various supplemental rules to add to those defined in RFC6125.. ]
 >> ..thus I am curious as to why draft-ietf-uta-email-tls-certs does not
 >> officially update RFC6125 -- should it not (in addition to updating four
 >> other RFCs as it notes) ?
 >"Supplemental rules" are inputs to RFC 6125 procedure (such as use of
(Continue reading)

Alexey Eromenko | 7 Feb 13:47 2016

Is Fragmentation at IP layer even needed ?

Hi All,

I'm re-evaluating TCP/IP stack again with my ongoing IP-FF research.

My question: Is packet fragmentation at IP layer even needed ?

Basically here are few possibilities:

1. Fragmentation-and-reassembly at every hop. (I don't know if anybody implements it)
2. IPv4 style-fragmentation -- fragmentation per every hop, reassembly at destination end.
3. IPv6-style-fragmentation -- fragmentation only at source end, reassembly at destination end.
4. No fragmentation at all (the advantage here: faster Router processing vs #1 or #2 and less implementation bugs); Assuming standard packet size is defined at 1280 bytes, like in IPv6
5. MTU path discovery via ICMP -- RFC-1981
6. MTU path discovery via TCP (or other Transport) -- RFC-4821 (or other way)

I'm leaning towards 4 + 6 solution in my own protocol, IP-FF.
What do you think ?
Should IP layer provide fragmentation ?

-Alexey Eromenko "Technologov"
Peter Yee | 6 Feb 04:39 2016

Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06

I am the assigned Gen-ART reviewer for this draft.  The General Area Review
Team (Gen-ART) reviews all IETF documents being processed by the IESG for
the IETF Chair.  Please treat these comments just like any other last call
comment.  For background on Gen-ART, please see the FAQ at

Document: draft-ietf-lisp-eid-block-mgmnt-06
Reviewer: Peter Yee
Review Date: February 5, 2016
IETF LC End Date: February 5, 2016
IESG Telechat date: February 18, 2016

Summary: This draft has serious issues, described in the review, and needs
to be rethought. [Not ready]

The draft attempts to specify the framework for the management of
experimental LISP EID sub-prefixes, but really could use some additional
work to flesh out the management aspects that are left unsaid.

This draft fixes only two minor nits I raised in my review of the -04
version.  Nothing else has been addressed, nor have I received any feedback
on that review.  In light of this, I have little new to add.  It is possible
that the agreement between the IANA and the RIPE NCC will alleviate the
major concern I had with the draft, but not being privy to that agreement, I
can't make that determination.

My original review with the unaddressed comments can be found here:

Andrew G. Malis | 5 Feb 22:42 2016

RtgDir review: draft-ietf-tsvwg-circuit-breaker-11.txt


I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the IESG. For more information about the Routing Directorate, please see ​

It would be helpful if you could consider these comments along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-tsvwg-circuit-breaker-11.txt
Reviewer: Andy Malis
Review Date: February 5, 2016
IETF LC End Date: February 9, 2016
Intended Status: Best Current Practice


I have some minor concerns about this document that I think should be resolved before publication.

Major Issues:

No major issues found.

Minor Issues:

Page 3, first paragraph: There are no citations to the claim that non-congestion-controlled traffic "can form a significant proportion of the total traffic traversing a link". Sure, video is a major part of Internet traffic these days, but much Internet video is dynamically adaptive. One or more citations would be useful.

Section 4: There are so many issues that they should be numbered, so that they can be referred to individually (from another document, for example).

Page 11: In my opinion, the second and third requirements on this page should be "MUST"s rather than "SHOULD"s.

Page 12, discussion of "In-Band" near the bottom of the page: This paragraph implies that an in-band control method will always provide fate-sharing of the control and regular traffic. It may provide fate-sharing, but that is by no means assured. For example, the network may be using ECMP, or traffic tunnels for data but not control traffic.

Section 5: I'm not sure why Section 5 is a separate section, and not integrated into Section 3 as new subsections, which I think would be an improvement.

Page 13, first paragraph: "presented in figure 2" -> "presented in figures 1 and 2".

Page 19, fourth paragraph: This paragraph states that "IP-based traffic is generally assumed to be congestion-controlled". This is true for TCP-based traffic, but I would not make such an assumption for all IP-based traffic.


The abbreviation "CB" is defined early in the document, but is hardly if ever used thereafter, rather "Circuit Breaker" is almost always spelled out. It may be useful to actually use the abbreviation.

Page 3, first paragraph, fifth line, "connection" -> "connections".

Figure 1: Move the vertical line between the "Measure" and "Trigger" boxes one space to the right.

Page 10, fourth paragraph: "If necessary, MAY combine" -> "If necessary, a CB MAY combine".

Page 11, fifth paragraph: "needs to be" -> "MUST"

Page 12, second paragraph: There are two separate references to Section 8. One combined reference should be sufficient.

Page 12, second to last paragraph: "in-Band" should have the "i" capitalized.

Page 15, last paragraph: "tranport" -> "transport"

Page 17, fifth paragraph: "Pseudo Wire" -> "PW"


Fernando Gont | 5 Feb 19:05 2016

Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols (Fwd: New Version Notification for draft-gont-predictable-numeric-ids-00.txt)


We have published a new IETF I-D entitled "Security and Privacy
Implications of Numeric Identifiers Employed in Network Protocols".

It sheds light on the security and privacy implications of predictable
numeric identifiers, which have affected (and still affect) several IETF
protocols for ages, and that in some cases (such as IPv6 IIDs) can be
leveraged for pervasive monitoring.

The I-D is available here:

For the time being, at least, we expect discussion to happen on the SAAG
mailing-list (<saag <at>>).

Your feedback will be appreciated.


Best regards,

-------- Forwarded Message --------
Subject: New Version Notification for
Date: Thu, 04 Feb 2016 08:29:45 -0800
From: internet-drafts <at>
To: Ivan Arce <stic <at>>, Fernando Gont
<fgont <at>>

A new version of I-D, draft-gont-predictable-numeric-ids-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-predictable-numeric-ids
Revision:	00
Title:		Security and Privacy Implications of Numeric Identifiers
Employed in Network Protocols
Document date:	2016-02-04
Group:		Individual Submission
Pages:		32

   This document performs an analysis of the security and privacy
   implications of different types of "numeric identifiers" used in IETF
   protocols, and tries to categorize them based on their
   interoperability requirements and the assoiated failure severity when
   such requirements are not met.  It describes a number of algorithms
   that have been employed in real implementations to meet such
   requirements and analyzes their security and privacy properties.
   Additionally, it provides advice on possible algorithms that could be
   employed to satisfy the interoperability requirements of each
   identifier type, while minimizing the security and privacy
   implications, thus providing guidance to protocol designers and
   protocol implementers.  Finally, it provides recommendations for
   future protocol specifications regarding the specification of the
   aforementioned numeric identifiers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat

nalini.elkins | 5 Feb 16:44 2016

Mentoring Feedback IETF 94 and Plans for Buenos Aires

First, let me thank the wonderful mentors who kindly and generously gave of their time and effort to make the mentees feel welcome.  Without everyone's support, we would not have a mentoring program.

If you would like to sign up to mentor for IETF95 in Buenos Aires, please do so here!  We need you!  (In particular for Speed Mentoring.)   

Sign up is here: 

For IETF94: We had about 45 mentees and about 25 mentors.  Not all mentees had a unique mentor.  Some mentees only attended our workshop or social gatherings.  This is quite a jump from IETF93 where we had 17 mentees.  I believe that the growth is attributable to better publicity & the events such as Speed Mentoring, the workshop given by Fred Baker on "Journey from I-D to RFC", and the support for lunch & social event that the mentoring team provided.

We hope to have 60-80 mentees in Buenos Aires.  I believe that is possible with the sessions we have planned.  We will be able to serve 30 people in Speed Mentoring alone. 

Mentee Experience
The mentee experience for IETF94 was good.  For example, in the question: "If you had a mentor assigned to you, what was your experience?"

The results were: 

Great experience                      61.1%   11 
Good or better than I expected 33.3%    6 
Could have been better              5.6%    1 
Not very well at all                      0.0%    0 
answered question                               18 
skipped question                                  13 

(Not all mentees answered the survey) 

Similar results were found for Speed Mentoring. I think the best thing is that nearly 100% of the mentees said that they would recommend mentoring and the mentoring events to others.

There were also some very nice comments from mentees such as:

"I think the speed mentoring was a great event. All mentors in speed mentoring were very helpful and opened the conversations themselves which helped a lot. I came into IETF with the thought at the back of my mind that there is always the mentoring team to help me and it proved 100% right."

You may see the results of the mentoring survey summary & feedback for IETF94 below:

IETF94 Mentoring Program Summary: 
IETF94 Overall Comments        : 
IETF94 Speed Mentoring Comments: 

This is the survey feedback for IETF93 - for comparison purposes.  (The number of mentees who responded here is for people who have ever participated in the mentoring program, not just IETF93)

Mentoring Program Summary IETF93:

What worked & will be expanded
Speed Mentoring, the workshop given by Fred Baker on "Journey from I-D to RFC", and the support for lunch & social event that the mentoring team provided. 

The Speed Mentoring logistics need to be improved.  It was a very good experience for all, I believe, but a bit chaotic.  The mentoring team will address this & smooth out.

We will invite mentors to participate for lunch also.  Monday and Tuesday we have a lot of mentees for lunch.  By Wed, many people have found their way socially & come just because they kind of like us!

What did not work
We tried two things which did not work: Shadow Mentoring and Remote Mentoring.  

Shadow mentoring is where the mentee attends the same sessions as the mentor.  What happened was that mentors and mentees wanted to attend different sessions and ended up separating.

Remote mentoring is where the mentee is not physically present.  The problem with this is that out of 8 potential remote mentees only 2 responded to an initial email asking them of their interests.  Those 2 we matched but we felt that if the individual could not even respond to an email asking them questions, then how interested and committed are they?

We understand that remote mentoring needs to happen and will think about how this can be done better.

New for IETF95
1. We want to do a session on: "Unwritten Rules and Values of the IETF".  This is because quite a few mentees have questions about the culture of the IETF and myths abound.  Please take a look at:

Please let me know what you think and any comments you have.

2. Crisis Mentors: some mentees wanted to have mentors available who would be available to go for a cup of coffee (or whatever) and support when their presentation was torn to shreds in a WG.  It happens.  It has happened to me.  It is nice to have someone to say "Hang in there.  Try again.  This is how you might do better next time."

Some have asked if this is not the job of the mentor to do this.  I think that is great for the mentor to do it but it is nice to have some other perspectives also.  The mentoring team will also provide support in these cases.

Thank you again to everyone for your help & please let me know any comments or questions.

Nalini Elkins
IETF Mentoring Team

Inside Products, Inc.
(831) 659-8360
Marco Davids | 5 Feb 15:13 2016
Gravatar login


I'm using the service as described below to keep up with 
IETF mailinglists:

I'm logging in with my datatracker credentials.

However, since this morning the login fails. Logging in via still works.

Is it just me or is there a more generic problem?



Attachment (smime.p7s): application/pkcs7-signature, 5730 bytes