Thomas Narten | 22 May 06:53 2015
Picon

Weekly posting summary for ietf <at> ietf.org

Total of 54 messages in the last 7 days.

script run at: Fri May 22 00:53:02 EDT 2015

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  7.41% |    4 | 11.00% |    51440 | douglasroyer <at> gmail.com
  7.41% |    4 |  7.20% |    33666 | daedulus <at> btconnect.com
  7.41% |    4 |  4.95% |    23141 | chair <at> ietf.org
  1.85% |    1 |  8.05% |    37633 | ice <at> cisco.com
  5.56% |    3 |  4.18% |    19550 | nico <at> cryptonector.com
  5.56% |    3 |  3.57% |    16694 | iad <at> ietf.org
  1.85% |    1 |  5.34% |    24985 | jaime.jimenez <at> ericsson.com
  3.70% |    2 |  3.24% |    15157 | magnus.westerlund <at> ericsson.com
  3.70% |    2 |  2.92% |    13669 | ynir.ietf <at> gmail.com
  3.70% |    2 |  2.68% |    12530 | morrowc.lists <at> gmail.com
  3.70% |    2 |  2.30% |    10750 | randy <at> psg.com
  1.85% |    1 |  3.04% |    14210 | bebemaster <at> gmail.com
  1.85% |    1 |  2.75% |    12845 | peter <at> akayla.com
  1.85% |    1 |  2.66% |    12437 | ron.even.tlv <at> gmail.com
  1.85% |    1 |  2.17% |    10166 | harald <at> alvestrand.no
  1.85% |    1 |  2.11% |     9878 | pthubert <at> cisco.com
  1.85% |    1 |  2.11% |     9864 | glen <at> amsl.com
  1.85% |    1 |  1.97% |     9231 | rdroms.ietf <at> gmail.com
  1.85% |    1 |  1.96% |     9152 | jari.arkko <at> piuha.net
  1.85% |    1 |  1.72% |     8037 | rjsparks <at> nostrum.com
  1.85% |    1 |  1.69% |     7887 | huubatwork <at> gmail.com
  1.85% |    1 |  1.66% |     7772 | jabley <at> hopcount.ca
  1.85% |    1 |  1.64% |     7682 | ben <at> nostrum.com
  1.85% |    1 |  1.62% |     7589 | narten <at> us.ibm.com
(Continue reading)

Benoit Claise | 22 May 00:09 2015
Picon

Blog: From NetFlow to IPFIX via PSAMP: 13 years of Standardization Explained

Dear all,

http://www.ietf.org/blog/2015/05/from-netflow-to-ipfix-via-psamp-13-years-of-standardization-explained/
Enjoy.

Regards, Benoit

IETF Chair | 18 May 21:45 2015
Picon

e-mail password reminders discontinued

As you know, the IETF uses the Mailman package to manage our
mailing lists. One of the features of Mailman is that it generates a
password reminder once a month and sends it to every email 
address in the system. This email is to advise you that we had to 
discontinue the mailman password reminders.

We have had an earlier discussion about this, and there were a few
people who wanted to see the reminders continue, and at that point
we turned them back on. They were causing operational difficulties,
however, which have led us to disable them again. We also hoped
that we would be able to make the setting a per-subscriber option.
However, this turned out to not be possible in Mailman. I apologize
for any inconvenience that this may cause.

The Mailman passwords are emailed in plain text, which is
generally considered a poor practice from a security standpoint.
In addition, each month when tens of thousands of reminder emails
are distributed, one or more ISPs temporarily block or rate-limit
email traffic coming from the IETF mail servers in response to the
mass mailing of these reminders.  

Users can still receive their passwords from the system on request
by visiting the information page of any subscribed list. Visit 
https://www.ietf.org/mailman/options/<list name>, enter your email
address, and click remind.

Let us know if we can do something to improve your mailing list
experience, be it about password reminders or other things.

Jari Arkko, IETF Chair
(Continue reading)

ronczkaj | 11 May 22:24 2015
Picon
Picon

Protocols for biocommunications management

G'day,

I have an academic interest in  Agronomy based field robotics (Bio-soft robotics). 

As a practitioner (IEE RAS; Biorheology) it would be nice to enable a dialogue for the development of protocols for integration of Biocommunications into the Internet of Things.

Is there any working group interest in such an undertaking (signalling; integration; message handling; etc) already underway?

If not, is it viable to seek any interest?

all the best
John
Michael Richardson | 11 May 17:46 2015
X-Face
Picon

IAOC nominees


Just after posting the query for feedback, Eliot Lear withdrew.
So he is not on the list for feedback online.

> Follwowing the the policy for "Open Disclosure of Willing
> Nominees" described in RFC 5680, the list of candidates is (alpha by first name):
>
> Eliot Lear
> Hago Dafalla
> Joel Halpern
> Jordi Palet
> Leslie Daigle
> Tom Walsh

Picon

Deadline 22 May for Postel Award Nominations

The Internet Society is soliciting nominations of qualified
candidates for the 2015 Jonathan B. Postel Service Award by 22 May
(new date). This annual award is presented to an individual or
organization that has made outstanding contributions in service to
the data communications community.  The award, which includes a
presentation crystal and a USD 20,000 prize, is scheduled to be
presented during the 93rd Internet Engineering Task Force (IETF)
meeting in Prague, Czech Republic, 19-24 July 2015.

The Jonathan B. Postel Service Award was established by the Internet
Society to honor a person who has made outstanding contributions in
service to the data communications community.  The award is focused
on sustained and substantial technical contributions, service to the
community, and leadership.  With respect to leadership, the award
committee places particular emphasis on candidates who have
supported and enabled others in addition to their own specific
actions.

The award is named for Dr. Jonathan B. Postel to recognize and
commemorate the extraordinary stewardship exercised by Jon over the
course of a thirty-year career in networking.  He served as the
editor of the RFC series of notes from its inception in 1969 until
1998.  He also served as the ARPANET *numbers Czar* and Internet
Assigned Numbers Authority over the same period of time. He was a
founding member of the Internet Architecture (nee Activities) Board
and the first individual member of the Internet Society, for which
he also served as a Trustee.

Find out more

*	Learn more about Jon Postel*s life and contributions.
http://www.internetsociety.org/what-we-do/grants-and-awards/awards/
postel-service-award/ten-year-tribute-jon-postel

*	Find the out more on the award, nomination procedures, and
online submission forms.
http://www.internetsociety.org/what-we-do/grants-and-awards/awards/
postel-service-award

*	I'm ready to nominate someone!
http://www.internetsociety.org/what-we-do/grants-and-awards/awards/
postel-service-award/procedures

For any questions, please contact postel at isoc.org

Best Regards,
Ray
IAD

Picon

Clarification: Chairs for IAOC and IETF Trust Elected

The IAOC elected Tobias Gondrom as chair, and the IETF Trust elected
Benson Schliesser as its chair during the meetings of the IAOC and
IETF Trust on 28 April 2015.

Tobias will complete the unexpired term - as IAOC Chair - of Chris
Griffiths, who resigned from the IAOC in April. Benson will complete
the unexpired term - as IETF Trust Chair - of Tobias Gondrom, who
resigned as IETF Trust Chair upon his election as IAOC Chair.  Both
terms expire in March 2016.

Ray
IAD

Picon

Chairs for IAOC and IETF Trust Elected

The IAOC elected Tobias Gondrom as chair, and the IETF Trust elected
Benson Schliesser as its chair during the meetings of the IAOC and
IETF Trust on 28 April 2015.

Tobias will complete the unexpired term of Chris Griffiths who
resigned from the IAOC in April. Benson will complete the unexpired
term of Tobias Gondrom who resigned as IETF Trust Chair upon his
election as IAOC Chair.  Both terms expire in March 2016.

Ray 
IETF Administrative Director

Peter Yee | 16 May 05:16 2015

Gen-ART LC review of draft-ietf-siprec-protocol-16

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

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

Document: draft-ietf-siprec-protocol-16
Reviewer: Peter Yee
Review Date: May-15-2015
IETF LC End Date: May-15-2015
IESG Telechat date: TBD

Summary: This draft is almost ready for publication as a proposed standard
but has open issues, described in the review. [Ready with issues]

The draft specifies entities and a protocol using SIP, SDP, and RTP for
recording communication sessions.  It provides the ability to notify UAs
that they are being recorded and for UAs to notify the recording system of
their recording preference.

The document is well written and has no obvious major technical issues.

Major issues: None

Minor issues:

Page 7, section 5.2, 1st paragraph, 1st sentence: are there any concerns
about the possibility of an SRC forging the metadata?  It seems like the
SRC could generate whatever metadata it wants and supply that in the RS.

Page 21, section 8.1.4, last sentence: what does “appropriately”.  Specify
where is the appropriate interpretation defined or provide it here.

Page 21, section 8.1.5, 2nd paragraph, 1st sentence: by “content” do you
actually mean “context”?  Or do you mean to the content of a SIPREC
recording?

Page 27, section 8.3.1, 2nd paragraph, 1st sentence: is there a
specification for how the SRC is supposed to map each CS CNAME to an RS
CNAME?  If so, give a pointer to that specification.

Page 30, section 9.1, 4th bullet item: unlike the other bullet items, this
one is not a temporary wait before sending the metadata, but is rather a
complete refusal to send certain metadata.  As such, although related to
the others, it would seem to be out of place within the set of bullet
items.

Page 38, section 12, 2nd paragraph, 3rd sentence: perhaps the word
“effective” would be more appropriate than characterizing it as an
“automatic” downgrade?

Page 38, section 12.1, 1st paragraph, 2nd to last sentence: just because
an SRS is compromised does not mean that it cannot be authenticated.  It
may very well be operating “correctly” and be able to authenticate, yet
the compromise allows the attacker to obtain the (decrypted) RS.
Authentication does not imply that the SRS you are talking to is not
compromised.  It only indicates the SRS possesses some form of credential
that appears to identify it correctly.

Page 39, last paragraph: I think this paragraph should mention (like the
previous one) that a comparable level of security is required in this
scenario as well.  It’s not just a different key that’s going to be used,
but it should be one of equivalent strength.

Nits:

NB: Anything below marked with an asterisk before the line is a technical
change; the rest are purely editorial and of lesser importance.

General:

Put a comma after “e.g.” and “i.e.” throughout the document — it’s done
inconsistently as it is.  Maybe s/e\.g\. /e\.\g., / would do the trick and
likewise for “i.e”.

Replace “Recording aware” with “Recording-aware”.

Specific:

Page 4, section 1, 2nd sentence: change “accordance to” to “accordance
with”.

Page 5, last bullet item: insert “a” before “non-SIP”.

Page 7, last paragraph, 2nd sentence: insert “the” before the 2nd “SRS”.

Page 8, Figure 2, step 1: append “1” after “snapshot” for parallel
construction.

Page 10, section 6.1.2, 1st sentence: change “recording indication” to
“recording indications”.  Or, alternatively use “a recording indication”
if there’s only one provided to all participants.

Page 11, section 6.3, 1st sentence: insert “a” before “recording
indication”.

Page 12, 1st partial paragraph, 1st full sentence: delete an extraneous
space before “IVR”.

Page 12, 1st partial paragraph, 2nd full sentence: insert “a” before “user
agent”.

Page 12, section 7.1.1, 2nd paragraph, last sentence: change “contributes”
to “contribute”.

Page 12, section 7.1.1, 3rd paragraph, 1st sentence: insert “an” before
“SRC”.

Page 14, section 7.1.2, 1st paragraph, last sentence: insert “a” before
“CS”.

Page 15, section 7.2, 1st paragraph, 2nd sentence: insert “the” before
“a=inactive”.

Page 15, section 7.2, 1st paragraph, 3rd sentence: insert “the” before
“a=recvonly”.

Page 15, section 7.2, 1st paragraph, 3rd sentence: Would this sentence be
more correct if rewritten for clarity as: "When the SRS is ready to
receive recorded streams, the SRS sends a new SDP offer and sets the
a=recvonly
attribute in the media streams.”?

Page 15, section 7.2, 2nd paragraph, 1st sentence: insert “an” before the
first “SDP” and insert “the” before “SRS”.

Page 16, 2nd paragraph, 1st sentence: insert “the” before the 2nd “SRS”.

Page 16, 2nd paragraph, 2nd sentence: consider changing “with recorded
streams” to “with the streams to be recorded” if that makes more sense.

Page 19, section 8.1.1, 2nd item, 2nd paragraph: change the semicolon to a
comma.

Page 20, section 8.1.2, 1st paragraph, 1st sentence: move the comma before
"[RFC5124]” to after that; do the same for “[RFC4585]”.  Change “non
encrypted” to “non-encrypted”.

Page 20, section 8.1.2, 1st paragraph, 2nd sentence: move the comma before
"[RFC3711]” to after that.  Delete the comma after "RTP Profile for Audio
and Video Conferences with Minimal Control”.  Change “AVP” to "(RTP/AVP)”.

Page 20, section 8.1.2, 1st paragraph, 3rd sentence: insert “RTP/“ before
each of “SAVP” and “AVP”.

Page 20, section 8.1.2, 2nd paragraph, 2nd sentence: change the space
after “AVPF” to a hyphen.

Page 20, section 8.1.3, 1st paragraph, 1st sentence: append a comma after
“[RFC3550]”.

Page 21, section 8.1.4, last sentence: change “sets” to “set”.

*Page 22, section 8.1.7, last sentence: change “AVFP” to “AVPF”.

Page 24, section 8.2, 1st paragraph, 2nd sentence: delete the comma after
“to”.

Page 30, section 9.1, 1st bullet item: insert “a” before the first
“previous”.  Insert “the SRC” before “cannot”.  Insert “the” before the
2nd “previous”.

Page 30, last paragraph, 1st sentence: change “an” to “a” before “200”.

Page 31, 2nd paragraph, 2nd sentence: append “.,” after “e.g”.

Page 32, section 9.2, 2nd paragraph, 2nd sentence: delete “for”.

Page 33, last paragraph, 2nd sentence: Why not state this in the
affirmative: “Any subsequent partial updates will only be dependent on the
metadata sent in this full metadata snapshot and any intervening partial
updates.”

Page 34, section 9.2.1, 1st paragraph: change “augmented” to “Augmented”.
Change “BNF” to “ABNF”.

Page 34, section 9.2.1, definition: change “RFC3261” to “RFC 3261”.

Page 34, section 10, 1st paragraph, 3rd sentence: insert “a” before “new
SDP”.

Page 34, section 10, 2nd paragraph, 3rd sentence: change “solves” to
“solve”.

Page 35, section 11.1.1, description, 1st sentence: insert “that” before
“the SIP”.

Page 35, section 11.1.1, description, 3rd sentence: change “UAS” to “UA”.

Page 35, section 11.1.2, description: change all occurrences of “media
level” and “session level” to “media-level” and “session-level”,
respectively.

Page 35, section 11.2.1, 1st paragraph: change the 2nd “for” to “of a”.

Page 36, section 11.2.2, 1st paragraph: change the 2nd “for” to “of a”.

Page 38, section 12, 1st paragraph, 1st sentence: delete the comma after
“therefore”.

Page 40, section 12.4, last sentence: append a comma after “simple”.

Thomas Narten | 15 May 06:53 2015
Picon

Weekly posting summary for ietf <at> ietf.org

Total of 19 messages in the last 7 days.

script run at: Fri May 15 00:53:02 EDT 2015

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 15.79% |    3 | 24.06% |    51172 | david.black <at> emc.com
 15.79% |    3 | 12.75% |    27130 | jari.arkko <at> piuha.net
  5.26% |    1 | 11.88% |    25280 | magnus.westerlund <at> ericsson.com
  5.26% |    1 |  8.71% |    18536 | alan.b.johnston <at> gmail.com
  5.26% |    1 |  6.01% |    12792 | mirja.kuehlewind <at> tik.ee.ethz.ch
  5.26% |    1 |  5.66% |    12039 | joelja <at> bogus.com
  5.26% |    1 |  5.34% |    11356 | keith.drage <at> alcatel-lucent.com
  5.26% |    1 |  4.45% |     9464 | rjsparks <at> nostrum.com
  5.26% |    1 |  3.61% |     7683 | hartmans-ietf <at> mit.edu
  5.26% |    1 |  3.60% |     7660 | narten <at> us.ibm.com
  5.26% |    1 |  3.00% |     6377 | ietf-secretariat <at> ietf.org
  5.26% |    1 |  2.82% |     5996 | harald <at> alvestrand.no
  5.26% |    1 |  2.73% |     5813 | nomcom-chair-2014 <at> ietf.org
  5.26% |    1 |  2.72% |     5782 | iab-chair <at> iab.org
  5.26% |    1 |  2.65% |     5637 | housley <at> vigilsec.com
--------+------+--------+----------+------------------------
100.00% |   19 |100.00% |   212717 | Total

Black, David | 15 May 01:21 2015

OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written with the intent of improving the operational
aspects of the IETF drafts. Comments that are not addressed in last call
may be included in AD reviews during the IESG review.  Document editors
and WG chairs should treat these comments just like any other last call
comments.

Document: draft-ietf-rtcweb-stun-consent-freshness-13
Reviewer: David Black
Review Date: May 14, 2015
IETF LC End Date: May 15, 2015 (on -11)

Summary: This draft is on the right track, but has open issues
 		described in the review.

This draft describes use of STUN to obtain ongoing consent to send in
a fashion that is secured by the use of cryptographically strong nonces
as STUN transaction IDs.

-- Major issues --

[1] The draft seems to be missing discussion of applicability - what
environments and/or protocols is this mechanism intended for or applicable
to?  Is this generally applicable wherever ICE and STUN are used?  I don't
see any RFCs listed as updated by this draft, so I'm guessing that this
is not intended to promulgate new requirements for all uses of ICE and
STUN, but this should be clarified.  The shepherd writeup implies that
this draft is intended primarily for WebRTC.

[2] The security considerations appear to be incomplete.
There should be an explanation of why cryptographically strong STUN
transaction IDs are required (e.g., there are no cryptographically
strong IDs in the TCP consent mechanism noted on p.4), and there should
be a discussion of how and why replays of previous consent responses
are harmless (will be ignored by the recipient).  The mechanism design
appears to be ok, but this rationale should be provided in terms of
attacks that are of concern and how they are prevented - a primary
intent appears to be to resisting off-path attacks.

-- Minor Issues --

[3] In Section 1, please explain what ICE-lite is.  A suitable reference
should suffice.

[4] In Section 4.1, please explain or provide a reference for what "paced"
means in "paced STUN connectivity checks or responses."

-- Nits/Editorial Comments --

The SRTP paragraph in Section 8 (Security Considerations) feels out of place
- this looks like design rationale material that would be better located in
Section 3.

idnits 2.13.02 found an unused reference:

  == Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on line 320, but
     no explicit reference was found in the text

That reference is likely to be useful to address the absence of discussion of
applicability (major issue [1], above).

--- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---

This mechanism is an incremental modification to the STUN and ICE protocols,
and can be implemented by one party to a communication session; ordinary
response generation behavior (already required) reflects the cryptographically
strong STUN transaction IDs on which the mechanism is based.  As a result, the
mechanism can be deployed at one end of a two-party communication session
without impact on the other party.  This is implied by section 3 of the draft,
but would be useful to state explicitly.  [A.1.1 - deployment]

The mechanism has been defined to limit the amount of added traffic and to
shut down unwanted traffic, plus contains a facility to desynchronize
independent users of this protocol.  Some rationale should be added for
the choice of the 30 second timeout period.  [A.1.5 - network impact]

There is an obvious fault condition, namely that consent is lost or revoked
causing immediate cessation of traffic.  While the details depend on the
environment in which this mechanism is used, it'd be helpful to add a sentence
or two on reporting of the state of STUN consent-based connectivity and how
that reporting should or may relate to reporting of the state of other forms
of connectivity (e.g., TCP, SRTP/SRTCP) that are mentioned in this draft.
[A.1.8 - fault and threshold conditions]

This mechanism is a simple extension to existing protocols, and should fit
into existing configuration and management for those protocols. [A.1.9 -
configuration, A.2 - Management (in general)]

It might be useful to mention the utility of tracking frequency and duration
of loss and re-establishment of consent-based connectivity, as such information
has operational value.  In particular, a discussion of how a server could infer
loss of connectivity with a client that is using this mechanism might be useful
to add, as the operational concerns may be more significant for servers and
related networks than clients. [A.2.2 - management information, A.2.3 - fault
management].

The primary operational impact of this protocol should be reduction in unwanted
traffic, which is a benefit - the consent check traffic added by this protocol
should not have significant impacts.  The writeup indicates that implementers
have reviewed the draft and implementations are in progress. [A.3 - Documentation]

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------


Gmane