Thomas Narten | 23 Jan 06:53 2015
Picon

Weekly posting summary for ietf <at> ietf.org

Total of 78 messages in the last 7 days.

script run at: Fri Jan 23 00:53:02 EST 2015

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  5.13% |    4 |  5.80% |    50055 | martin.thomson <at> gmail.com
  3.85% |    3 |  6.48% |    55900 | david.black <at> emc.com
  3.85% |    3 |  5.96% |    51421 | adrian <at> olddog.co.uk
  5.13% |    4 |  4.06% |    35021 | jari.arkko <at> piuha.net
  2.56% |    2 |  6.29% |    54251 | elwynd <at> dial.pipex.com
  2.56% |    2 |  5.83% |    50305 | chair <at> ietf.org
  1.28% |    1 |  6.62% |    57153 | bclaise <at> cisco.com
  3.85% |    3 |  2.66% |    22949 | masinter <at> adobe.com
  2.56% |    2 |  2.50% |    21555 | bmoeller <at> acm.org
  2.56% |    2 |  2.30% |    19863 | fgont <at> si6networks.com
  2.56% |    2 |  2.29% |    19767 | alexey.melnikov <at> isode.com
  2.56% |    2 |  2.22% |    19167 | phill <at> hallambaker.com
  2.56% |    2 |  2.11% |    18240 | touch <at> isi.edu
  2.56% |    2 |  1.99% |    17206 | mcr+nomcom <at> sandelman.ca
  2.56% |    2 |  1.83% |    15821 | gorry <at> erg.abdn.ac.uk
  2.56% |    2 |  1.80% |    15547 | mrex <at> sap.com
  2.56% |    2 |  1.67% |    14369 | ynir.ietf <at> gmail.com
  2.56% |    2 |  1.66% |    14362 | nomcom-chair-2014 <at> ietf.org
  2.56% |    2 |  1.66% |    14358 | yuhongbao_386 <at> hotmail.com
  2.56% |    2 |  1.45% |    12513 | julian.reschke <at> gmx.de
  1.28% |    1 |  1.77% |    15239 | herve.ruellan <at> crf.canon.fr
  1.28% |    1 |  1.61% |    13874 | mary.h.barnes <at> gmail.com
  1.28% |    1 |  1.61% |    13859 | watsonbladd <at> gmail.com
  1.28% |    1 |  1.57% |    13560 | ron.even.tlv <at> gmail.com
(Continue reading)

Hosnieh Rafiee | 22 Jan 23:28 2015

SDNAuth - Secure SDN authentication and authorization - Interested?

Folks,

We have established a group for discussion on secure authentication and
authorization of SDN components when SDN solution is in use. 

---------------------------------------------------------------
The name of this group is: SDNAuth

This group focuses on the following scope:
-	Authentication and authorization of application to the network
control - SDNAuth only provides the place where a network control can find
policy but applying policy is out of the scope of SDN auth
-	Authentication and authorization of two controllers (exchanging
policy is out of the scope)
-	Optimization of authentication and authorization of network elements
+ user at the same time
-	Authentication and authorization of an app to a security function
service such as a firewall (applying any rules on the firewall is out of
scope but authentication and showing the place of policies are in scope) :
SDN/NFV authentication

You can find more information about this group on the info page.

If you are interested on the scope of this group, please feel free to join
clicking on the following address: 

< https://mail.rozanak.com/mailman/listinfo/sdnauth >

---------------------------------------------------------------

(Continue reading)

Adrian Farrel | 20 Jan 12:47 2015
Picon

Last Call comments draft-ietf-mpls-seamless-mcast-15.txt

As part of my AD review of this document I found a number of small editorial
issues that I am raising now as Last Call comments.

Adrian

===

idnits reveals that the copyright year needs to be 2015. Please update
that if you revise the document.

idnits also points out that you probably don't need the boilerplate for
pre-RFC5378 work. unless you are sure you need it, please take it out.

---

I think that the RFC Editor will need your help expanding some of the
abbreviations that are not listed as "well known" in the list at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
You might kick this off by doing a scrub yourselves.

---

Section 3 line 1
s/suppose/assumed/

---

5.1.2 and 5.2.2 titles

s/re-advertise/re-advertised/                                      
(Continue reading)

Roni Even | 20 Jan 07:51 2015
Picon

Gen-ART LC review of draft-ietf-drinks-spp-protocol-over-soap-07

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-drinks-spp-protocol-over-soap-07

Reviewer: Roni Even

Review Date:2015–1-17

IETF LC End Date: 2015–1-22

IESG Telechat date:

 

Summary: This draft is almost ready for publication as a standard track RFC.

 

 

Major issues:

 

Minor issues:

 

There are two schemas used, the sppf:base and sppf:soap each have a version number. When talking about supported version and about response codes on supported version, is it referring to the base or soap version? There is some text in the minorVer section but it is not clear enough.

 

 

 

 

 

 

 

Nits/editorial comments:

The “complexType name="ResultCodeType” is defined in multiple subsections (7.2.1.2 , 7.2.2.2 , …) but not in all places, should be specified only once or in all. Also the definitions in section 7 are not consistent with the ones in section 9 which is the formal definition.

 

 

NomCom Chair 2014 | 20 Jan 02:14 2015
Picon

IETF NOMCOM 2014 - deadline 2015-01-26 - Call for Nominations: 3rd ROUTING AREA DIRECTOR

The 2014-15 Nominating Committee (NomCom) is seeking nominations
from now until January 26, 2015, 23:59UTC for the position of 3rd Routing
Area Director.  Please see below for this much shorter NomCom schedule.
For background on the request for a third routing area director please see:
     http://www.ietf.org/mail-archive/web/ietf/current/msg91370.html
     http://www.ietf.org/mail-archive/web/ietf/current/msg91030.html
     http://www.ietf.org/mail-archive/web/ietf/current/msg91015.html

 {A note about candidates that have previously been nominated: a number of
  people were nominated to the role of 2nd Routing AD.  The NOMCOM Chair
  will be contacting those candidates to determine if they wish to stand
  for the third position; if they do, they will be listed for feedback.
  Additional feedback is welcome; but no previous comments have been lost.}

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2014 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2014/nominate/

  {Note that nominations made using the web tool require an ietf.org
   datatracker account. You can create a datatracker ietf.org account
   if you don't have one already by visiting the following URL:
      https://datatracker.ietf.org/accounts/create/ }

Nominations may also be made by email to nomcom14 <at> ietf.org.

If you use email, please include the word "Nominate" in the Subject and
indicate in the email who is being nominated, their email address (to
confirm acceptance of the nomination), and the position for which you
are making the nomination. If you wish to nominate more than one
person, please use separate emails to do so.

Self-nominations are welcome!

NomCom 2014-15 will follow the policy for "Open Disclosure of Willing
Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of
nominees willing to be considered for positions under review in the
current Nomcom cycle is not confidential". Willing nominees for each
position will be listed in a publicly accessible way - anyone with a
datatracker account may access the lists.  In all other ways, the
confidentiality requirements of RFC 3777/BCP10 remain in effect.  All
feedback and all Nomcom deliberations will remain confidential and will
not be disclosed.

NOTE THAT NOMINATIONS SHOULD NOT WAIT FOR MANAGEMENT PERMISSION.
Nominees should Accept/Decline as soon as they decide they wish to consider
it, and if they do not have management (or family) support, then they
can withdraw.

SCHEDULE FOR THIRD ROUTING AREA (at 23:59 UTC):
         also see calendar at: http://goo.gl/D3q2CY
	- Tuesday, January 20, 2015  - open nominations
	- Monday, January 26,  2015  - deadline for nominations/open for comments
	- Monday, February 2,  2015  - deadline for questionnaires
	- Monday, February 13, 2015  - deadline for comments on persons, and requirements
	- Target week for interviews Tuesday, February 3, 2016.
        (We are aware of IAB workshop that occurs last week of January)

Some additional details from the IESG request:
     - The IESG is currently proposing to move three working groups from the
     INT area to the RTG area: L2TPEXT, LISP, and TRILL

     - There is a considerable increase in management-related work in the RTG
       area. Specifically, there are a lot of new YANG models being
       written. Although the coordination of YANG across the IETF falls as
       the responsibility of the OPS ADs (specifically the Management AD) it
       is expected that the RTG ADs will need to work on an increasing number
       of YANG documents so familiarity with YANG should be added to the list
       of desirable (but not mandatory) skills.

     - The reasoning behind the addition of a third RTG AD is that the load
       in the RTG area is currently unsustainably high. The placement of a
       third AD will have the effect of spreading that load such that the
       time requirement may now be more consistent with the work loads of ADs
       in other areas.

"B. Bösch" | 16 Jan 18:12 2015
Picon
Picon

Internet Draft: Standardized Parameterization of Intrusion Detection Entities

Dear Community,

Efficiency of Intrusion Detection Systems (IDS) depends on their 
configuration and coverage of services. The coverage depends on used IDS 
with currently vendor-specific configurations. In case of usage of 
multiple systems the operations could become complex. Individual 
Communication between management interface and the IDS entities results 
that current multi-vendor IDS architectures do not interact with each 
other. They are independent coexistent.

The Internet Draft defines data formats and exchange procedures to 
standardize parametrization information exchange into intrusion 
detection and response systems from a Manager to an Analyzer.

The created Intrusion Detection Parametrization Exchange Format (IDPEF) 
is intended to be a standard data format to parametrize IDS. The 
development of this open standardized format and the Intrusion Detection 
Message Exchange Format (IDMEF) will be enable in combination 
interoperability among commercial, open source, and research systems, 
allowing users to mix-and-match the deployment of these systems 
according to their strong and weak points to obtain an optimal IDS 
implementation.

The most obvious place to implement IDPEF is in the data channel between 
a Manager and an Analyzer of an IDS within this data channel where the 
Manager sends the configuration parameters to the Analyzers. But there 
are other places where the IDPEF can be useful:

- Combination of specialized IDS like application-IDS with server-IDS, 
WLAN-IDS and network-IDS to one functional interacting meta-IDS.

- Management of different IDS vendors with one central management interface.

- Interaction of different IDS by using IDPEF and IDMEF.

- Parametrization backups and restore of parametrized IDS entities.

- For a communication between a Manager and a Manager in a multi-stage 
management architecture.

I am happy to invite you to give me feedback, suggestions, notations, 
hints, recommendations, etc. to improve the Internet Draft. The initial 
version of the Internet Draft could be found at:

http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt

Kind regards,

B.-C. Boesch

Michael Richardson | 16 Jan 16:50 2015
X-Face
Picon

NomCom 2014 - announcement of IESG positions


{This is a repost, sorry for any duplication; I omitted the CC to
ietf <at> ietf.org yesterday.}

The 2014-15 IETF NomCom is pleased to announce its selection of the
IESG members whose two year terms start at IETF 92 in March 2015.

The NomCom thanks all the nominees and the community for the
extensive and very valuable feedback.

Please look for subsequent messages on IAOC and IAB, as those get confirmed.

IESG was previously             is now
APP: Pete Resnick               empty as requested
INT: Ted Lemon                  Terry Manderson
OPS: Joel Jaeggli               Joel Jaeggli
RAI: Richard Barnes             Ben Campbell
RTG: Adrian Farrel              Alvaro Retana
SEC: Stephen Farrell            Stephen Farrell
TSV: Spencer Dawkins            Spencer Dawkins
GEN/Chair: Jari Arkko           Jari Arkko

Combined with the existing members, this produces an IESG as follows:

APP: Barry Leiba - Huawei
INT: Terry Manderson - ICANN
     Brian Haberman  - Johns Hopkins University
OPS: Joel Jaeggli - Fastly
     Benoit Claise -  Cisco
RAI: Ben Campbell - Oracle
     Alissa Cooper -  Cisco
RTG: Alvaro Retana - Cisco
     Alia Atlas - Juniper Networks
SEC: Stephen Farrell - Trinity College Dublin
     Kathleen Moriarty - EMC Corporation
TSV: Spencer Dawkins - Huawei
     Martin Stiemerling - NEC & Darmstadt University
GEN/Chair: Jari Arkko - Ericsson

The new IESG will have three members from Cisco.
Should the IESG have to go towards their (alternative) voting process, it is
possible for a document to be blocked by three ADs voting "no". The IESG is in
charge of its informal and formal rules, and could fix this in a variety of
ways if it becomes necessary.

The nomcom did not start its deliberations with any quotas or limits;
rather, the NomCom asked who can best do the job, and went from there.

The NOMCOM believes that the IESG members, new and old, can and will act as
individuals, and will recuse themselves as appropriate. Evidence from past
experience is that this has been true in the past as well.

Michael Richardson
NomCom Chair 2014-15
nomcom-chair-2014 <at> ietf.org, mcr+nomcom <at> sandelman.ca

--
Michael Richardson
mcr+nomcom <at> sandelman.ca
nomcom-chair-2014 <at> ietf.org

IETF Chair | 16 Jan 16:56 2015
Picon

Update on the re-organisation steps


The IESG has discussed the re-organisation proposal and the comments
that we have received. Thank you for providing feedback!

We have decided to move forward with two parts of the original proposal,
continue thinking about the third one, and have identified a fourth item that
needs even more focus:

1. We are asking the Nomcom to seat a third AD for the Routing Area. The 
desired expertise for this position is the same as the one already used for the
position that was open noting an increase in YANG related work in the RTG 
Area, and the three working groups that will move from INT to RTG. The 
position is for two years. This change addresses changes in work that is
coming to IETF, making the management of this work easier, and it is 
anticipated that the work-load for RTG Areas will be normalized as a result.

2. We have been implementing a change in how flexible the assignment of
ADs is to areas. This is necessary in order to ensure that we have sufficient
agility to perform our management tasks, and is demonstrated by our 
re-assignment of some of the OPS Area working groups to non-OPS ADs
as one of the OPS  ADs has taken on broader responsibility for IETF
YANG work.

As we rebalance, this change will affect how WGs are assigned to ADs,
and this will require changes in how the IESG operates as well as changes
to some of the data tracker tools.

Note that this is a change with regards to which AD manages specific working
groups. The assignment of working groups to areas will not change as a result
of this procedural change. An AD can be the most suitable manager for the 
working group, even when the working group itself remains associated with a
different area. An area is not merely about the ADs managing it, it is also 
category of topics on a particular branch of technology, a designation in our 
agendas, usually overseen by one or multiple directorates, and scheduled so
as to avoid too many conflicts within the area. Areas are also loose collections
of people working together, and the assignment of ADs to particular working
groups should not have an effect on any of these other aspects of an area.

This change relates only to agility, and the IESG fully recognises the
observation that a key focus for organizational changes in the IETF should
be in moving work from the IESG to working groups or other entities.

3. We have heard the feedback from the community that there is concern
about creating a "mega-area" formed by combining APP, RAI, and TSV. We 
will think about this proposal further and will come back either with a 
stronger rationale or an alternative plan of more normal-sized areas: any
proposal for structural change will reflect the feedback you have given us.

4. With respect to ensuring that AD workload is suitable for a broad of class
contributors willing to take on the task, the IESG clearly needs to take
additional steps. Agility and right area structure helps spread the workload
better across ADs, but other changes are needed. But this is a continuous
process. Our desire to push document approval Comment and Discuss
resolution more to the working groups and e-mail has significantly reduced
the length of our tele chats in recent years, for instance, and we are starting
a project to eliminate errata processing as an AD task. We will return to this
topic with further proposals later as well.

Jari Arkko for the IESG

Thomas Narten | 16 Jan 06:53 2015
Picon

Weekly posting summary for ietf <at> ietf.org

Total of 139 messages in the last 7 days.

script run at: Fri Jan 16 00:53:01 EST 2015

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  6.47% |    9 |  5.66% |    79836 | john-ietf <at> jck.com
  6.47% |    9 |  4.88% |    68868 | mcr+ietf <at> sandelman.ca
  6.47% |    9 |  4.59% |    64826 | nico <at> cryptonector.com
  5.76% |    8 |  4.55% |    64163 | mstjohns <at> comcast.net
  5.04% |    7 |  4.06% |    57266 | jan.pechanec <at> oracle.com
  1.44% |    2 |  5.81% |    81973 | rajiva <at> cisco.com
  3.60% |    5 |  3.37% |    47588 | jari.arkko <at> piuha.net
  2.88% |    4 |  3.21% |    45331 | allison.mankin <at> gmail.com
  1.44% |    2 |  4.63% |    65307 | ted.ietf <at> gmail.com
  2.88% |    4 |  2.74% |    38722 | brian.e.carpenter <at> gmail.com
  2.16% |    3 |  3.27% |    46201 | mustapha.aissaoui <at> alcatel-lucent.com
  2.88% |    4 |  2.19% |    30861 | stephen.farrell <at> cs.tcd.ie
  1.44% |    2 |  3.50% |    49354 | serrhini <at> mail.ru
  2.88% |    4 |  1.98% |    27950 | mcr <at> sandelman.ca
  2.16% |    3 |  2.20% |    31067 | phill <at> hallambaker.com
  1.44% |    2 |  2.50% |    35340 | wilton <at> isoc.org
  2.16% |    3 |  1.49% |    21045 | dhc <at> dcrocker.net
  2.16% |    3 |  1.45% |    20438 | nmav <at> redhat.com
  2.16% |    3 |  1.42% |    20011 | rsalz <at> akamai.com
  1.44% |    2 |  1.76% |    24787 | julian.reschke <at> greenbytes.de
  0.72% |    1 |  2.24% |    31692 | mary.h.barnes <at> gmail.com
  1.44% |    2 |  1.40% |    19767 | cnst <at> netbsd.org
  1.44% |    2 |  1.31% |    18560 | avri <at> acm.org
  1.44% |    2 |  1.16% |    16415 | ben <at> nostrum.com
  0.72% |    1 |  1.83% |    25871 | apisanty <at> gmail.com
  1.44% |    2 |  1.04% |    14679 | housley <at> vigilsec.com
  1.44% |    2 |  1.02% |    14459 | loa <at> pi.nu
  1.44% |    2 |  0.93% |    13073 | stbryant <at> cisco.com
  1.44% |    2 |  0.78% |    10975 | randy <at> psg.com
  0.72% |    1 |  1.10% |    15573 | david.black <at> emc.com
  0.72% |    1 |  1.09% |    15354 | bclaise <at> cisco.com
  0.72% |    1 |  1.07% |    15158 | rjsparks <at> nostrum.com
  0.72% |    1 |  1.04% |    14617 | ietf <at> trammell.ch
  0.72% |    1 |  1.01% |    14238 | eburger <at> cs.georgetown.edu
  0.72% |    1 |  0.88% |    12370 | alissa <at> cooperw.in
  0.72% |    1 |  0.87% |    12216 | chris <at> maei.ca
  0.72% |    1 |  0.84% |    11852 | matthew <at> kerwin.net.au
  0.72% |    1 |  0.79% |    11098 | spencerdawkins.ietf <at> gmail.com
  0.72% |    1 |  0.78% |    10975 | squid3 <at> treenet.co.nz
  0.72% |    1 |  0.75% |    10610 | jordi.palet <at> consulintel.es
  0.72% |    1 |  0.73% |    10280 | dromasca <at> avaya.com
  0.72% |    1 |  0.72% |    10231 | gregory.mirsky <at> ericsson.com
  0.72% |    1 |  0.70% |     9901 | narten <at> us.ibm.com
  0.72% |    1 |  0.66% |     9374 | jhw <at> nestlabs.com
  0.72% |    1 |  0.65% |     9122 | bmoeller <at> acm.org
  0.72% |    1 |  0.64% |     9041 | lear <at> cisco.com
  0.72% |    1 |  0.60% |     8485 | daedulus <at> btconnect.com
  0.72% |    1 |  0.59% |     8350 | acmorton <at> att.com
  0.72% |    1 |  0.56% |     7836 | ietf-secretariat <at> ietf.org
  0.72% |    1 |  0.52% |     7380 | lars <at> netapp.com
  0.72% |    1 |  0.52% |     7299 | pgut001 <at> cs.auckland.ac.nz
  0.72% |    1 |  0.51% |     7135 | presnick <at> qti.qualcomm.com
  0.72% |    1 |  0.50% |     6989 | joelja <at> bogus.com
  0.72% |    1 |  0.49% |     6910 | cory <at> lukasa.co.uk
  0.72% |    1 |  0.49% |     6856 | masinter <at> gmail.com
  0.72% |    1 |  0.48% |     6804 | nmav <at> gnutls.org
  0.72% |    1 |  0.48% |     6766 | cdel <at> firsthand.net
  0.72% |    1 |  0.45% |     6386 | daniel <at> haxx.se
  0.72% |    1 |  0.44% |     6260 | w <at> 1wt.eu
  0.72% |    1 |  0.44% |     6198 | martin.thomson <at> gmail.com
  0.72% |    1 |  0.43% |     6117 | d3e3e3 <at> gmail.com
  0.72% |    1 |  0.43% |     6000 | julian.reschke <at> gmx.de
  0.72% |    1 |  0.42% |     5930 | carsten <at> schiefner.de
  0.72% |    1 |  0.39% |     5570 | iad <at> ietf.org
--------+------+--------+----------+------------------------
100.00% |  139 |100.00% |  1411706 | Total

Nico Williams | 16 Jan 04:14 2015

Re: Updating BCP 10 -- NomCom ELEGIBILITY

On Wed, Jan 14, 2015 at 07:29:08PM -0500, Michael StJohns wrote:
> At 02:47 PM 1/14/2015, Nico Williams wrote:
> >In what way does scribing help someone be an appropriate choice to be
> >on the NOMCOM?
> 
> Unlike some ID submissions, the scriber is performing a service of
> benefit to the IETF as a whole.  :-)   And anyone who can't give up a
> couple of hours to scribe is unlikely to be a great participant in the
> Nomcom.
> 
> Seriously,  what I would hope would happen is that person who is
> interested (participating, writing, throwing stones) in WG A, but only
> peripherally interested in WG B volunteer to scribe WG B rather than
> (as you point out) get distracted in WG A.  Thus allowing the WG B
> interested people to write/throw stones/hum without needing to come up
> with a scribe.
>
> [...]

OK, scribing is evidence that the participant is willing to volunteer.
And if the volunteer does as you say, then they make a great candidate.

Nico
--

-- 

James Woodyatt | 16 Jan 00:46 2015

I-D.farrresnickel-harassment

Everyone—

Having reviewed I-D.farrresnickel-harassment, I have a comment, but first I want to express my vigorous support for this effort to establish anti-harassment procedures in IETF.

It occurs to me that the Lead Ombudsperson has a variety of functions related to the application of remedies, and the draft doesn't clearly indicate what happens when the term of service ends for a Lead Ombudsperson with unresolved cases.

It seems obvious that the draft intends to leave this policy for the Ombudsteam to set, and I suppose that's adequate, but I think the draft would be improved if Section 3.7 were to make explicit note of that. You know, so as to remind the Ombudsteam that they really need to plan for that, because it's a thing that will happen.

I can also imagine one scenario where the procedures in the draft might become troubled.

Consider the case where a Reporter informs the Lead Ombudsperson they believe another Ombudsperson should recuse themselves, then later, before the case is resolved, that Lead Ombudsperson is removed from the Ombudsteam. If that scenario happened to me, then I'd very much want to be consulted in the selection of a replacement for the Lead Ombudsperson for my case.

Perhaps Section 3.7 should say something to the effect that the Ombudsteam shall in each case select a replacement for the Lead Ombudsperson from among its members with the agreement of the Reporter.


--
james woodyatt <jhw <at> nestlabs.com>
Nest Labs, Communications Engineering

Gmane