Stefan Winter | 4 Mar 17:38 2014
Picon

eduroam architecture draft (includes UDP vs. TLS considerations)

Hi,

this is our draft on the eduroam architecture, as teased in the opsarea
meeting.

https://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam/

We are still looking for a home / sponsor for it :-)

As a sidenote: contrary to many commercial operators, we are publicly
funded and all our documentation is open for everybody. If you have any
hands-on questions beyond the draft's content, don't hesitate to ask.
I'll merrily tell you everything except the shared secrets ;-)

Greetings,

Stefan
Attachment (0x8A39DC66.asc): application/pgp-keys, 3294 bytes
_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Thomas D Nadeau | 3 Mar 17:57 2014

Re: [eX-bulk] : Re: configuration: writable MIB modules versus NETCONF/YANG modules - part 2

I'm not sure about the implementations, but models (yang) are definitely the right direction of you ask me. 
translation from a common model is easier than one from every specific management protocol as
(automated) code generation is a viable solution (see the direction odp is going).

Tom 

> On Mar 3, 2014, at 16:19, "Christopher LILJENSTOLPE" <cdl_forward <at> cdl.asgaard.org> wrote:
> 
>> On 3 Mar 2014, at 13:37, Thomas Nadeau wrote:
>> 
>>    Sorry for not replying to this thread - been traveling and busy all weekend...  One comment inline below:
>> 
>> 
>>> Dear all,
>>> 
>>> [I bcc'ed some people, with whom I discussed this issue privately. I want to make sure they're in the
opsarea loop. Sorry, if you receive this email twice]
>>> 
>>> I discussed the following statement with the IESG. I ideally wanted to have this statement approved as
an IESG statement before the beginning of the week, but I realize that it might need some more discussion
among the OPS community...
>>> The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are
therefore encouraged to use the NETCONF/YANG standards for configuration, especially in new charters.
SNMP MIB modules creating and modifying persistent configuration state should only be produced by
working groups in cases of clear utility and consensus to use SNMP write operations for configuration.
>>> Btw, one IESG member insisted on having "creating and modifying" instead of "modifying".
>>> 
>>> Let me focus on a more important issue.
>>> First let me make sure that we agree on one terminology. The NETCONF/YANG terminology is in RFC 6244:
>>> o  Configuration data is the set of writable data that is required to
(Continue reading)

Benoit Claise | 28 Feb 13:06 2014
Picon

configuration: writable MIB modules versus NETCONF/YANG modules - part 2

Dear all,

[I bcc'ed some people, with whom I discussed this issue privately. I want to make sure they're in the opsarea loop. Sorry, if you receive this email twice]

I discussed the following statement with the IESG. I ideally wanted to have this statement approved as an IESG statement before the beginning of the week, but I realize that it might need some more discussion among the OPS community...
The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, especially in new charters. SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration.
Btw, one IESG member insisted on having "creating and modifying" instead of "modifying".

Let me focus on a more important issue.
First let me make sure that we agree on one terminology. The NETCONF/YANG terminology is in RFC 6244:
o Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state [RFC4741]. o Operational state data is a set of data that has been obtained by the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data, operational state is transient and modified by interactions with internal components or other systems via specialized protocols. o Statistical data is the set of read-only data created by a system itself. It describes the performance of the system and its components. Operational state data is sometimes called ephemeral (or non-persistent configuration data), as opposed to the "configuration data" that is persistent.
See RFC 6244 section 4.3.2.x for some useful examples.

The statement has been carefully crafted to cover the 4 different cases:

                                                                             SNMP                                                         NETCONF/YANG
                                              +-----------------------------------------------------------------+--------------------------------------------------+
            Configuration data  | SHOULD NOT specify writable MIB modules    |  SHOULD use NETCONF/YANG          |
                                              |-----------------------------------------------------------------+--------------------------------------------------|
     Operational State data  | Not clear guidelines at time point in time  (*)   |   SHOULD use NETCONF/YANG         |
                                              +---------------------------------------------------------------------------------------------------------------------+                                             

Let me focus on (*).
Some of you are telling: SNMPset is not enabled in networks, period. Don't specify new writable MIB modules, even for operational state data, it doesn't make sense.
Some others are telling: Note that this statement limits the discussion to configuration data. Note also that there is no standard way to modify operational state via NETCONF at this point in time (so it would be strange to discourage SNMP if there is no standardized alternative).

I believe we need some more discussion on this specific point.  Please share your point of view:
- Should we keep the statement as it is, but better explain it? (which might require more background, so maybe a draft instead of a brief statement)
- Should we extend the statement and remove "persistent" from this sentence: SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration?
- Something else?

Regards, Benoit




_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Benoit Claise | 26 Feb 12:41 2014
Picon

Updated OPS area agenda

Dear all,

https://datatracker.ietf.org/meeting/89/agenda/opsawg/
Reminder: the OPSAREA meeting will be combined with OPSAWG

Regards, Benoit
Benoit Claise | 25 Feb 16:58 2014
Picon

Re: call for agenda items for the OPSAREA open meeting at IETF-89

Hi Cathy,

Can you please let me know where those drafts have been 
socialized/discussed?

Regards, Benoit
> Dear Chairs,
> We'd like to request a 10min slot for open IPv6. The related documents links are as below:
> http://tools.ietf.org/html/draft-sun-openv6-problem-statement-01
> http://tools.ietf.org/html/draft-liu-openv6-architecture-01
> We had a side meeting in IETF 88, Vancouver, and people agreed that we should present this idea in opsarea to
get more reviews and comments.
> The presenter will be Chongfeng Xie from China Telecom.
>
> Best Regards,
> Cathy
>
>
>> -----Original Message-----
>> From: OPS-AREA [mailto:ops-area-bounces <at> ietf.org] On Behalf Of Benoit
>> Claise
>> Sent: Friday, February 14, 2014 12:48 PM
>> To: ops-area <at> ietf.org
>> Subject: [OPS-AREA] call for agenda items for the OPSAREA open meeting at
>> IETF-89
>>
>> Dear all,
>>
>> We are planning again for a joint OPSAWG and OPSAREA open meeting, with
>> the OPSAWG work items driving most of the agenda. The more general
>> cross-area items or those related to the relation between work in the area and
>> work out of the IETF should be part of the OPSAREA section.
>>
>> Please send us your requests for presentation and discussion slots.
>>
>> Thanks and Regards,
>>
>> Regards, Joel and Benoit
>>
>> _______________________________________________
>> OPS-AREA mailing list
>> OPS-AREA <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ops-area
> .
>
Benoit Claise | 19 Feb 17:37 2014
Picon

OPS open hours office

Dear all,

When: Wed 15:20 to 16:30
Where: TBD

Please come to talk to us on any WG or area items, about new proposals, 
or about any other IETF-related business.

An advanced notification would be appreciated.

Regards, Joel and Benoit
Fan, Peng | 19 Feb 17:12 2014

FW: New Version Notification for draft-fan-deep-performance-visualization-00.txt

Dear all,

We have posted a document discussing visualizing network performance, and would like to get your
attention and feedback. The proposal aims to provide views of network performance for
applications/systems/protocols that desire this information to work better. Performance status can
be accessed through a unified interface, and comprehensive performance data can be achieved by covering
and processing metric values from different areas/perspectives of network.

The document is at
http://www.ietf.org/internet-drafts/draft-fan-deep-performance-visualization-00.txt. Any
comments are welcome.

Best regards,
Peng

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Friday, February 14, 2014 10:49 PM
To: Peng Fan; Peng Fan; Zhen Cao; Zhen Cao
Subject: New Version Notification for draft-fan-deep-performance-visualization-00.txt

A new version of I-D, draft-fan-deep-performance-visualization-00.txt
has been successfully submitted by Peng Fan and posted to the IETF repository.

Name:		draft-fan-deep-performance-visualization
Revision:	00
Title:		Deep Performance Visualization: Use Cases, Requirements and Framework
Document date:	2014-02-14
Group:		Individual Submission
Pages:		7
URL:            http://www.ietf.org/internet-drafts/draft-fan-deep-performance-visualization-00.txt
Status:         https://datatracker.ietf.org/doc/draft-fan-deep-performance-visualization/
Htmlized:       http://tools.ietf.org/html/draft-fan-deep-performance-visualization-00

Abstract:
   Providing deep performance information by the networks is expected in
   many use cases.  This document intends to discuss a unified
   presentation of performance, by investigating use cases that benefit
   from performance information, describing relevant requirements, and
   proposing a framework of how the components work together to enable
   deep performance visualization.

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

The IETF Secretariat
Benoit Claise | 14 Feb 01:39 2014
Picon

configuration: writable MIB modules versus NETCONF/YANG modules

Dear all,

We occasionally see read-write MIB module proposals within the IETF.
However, the write capabilities of those MIB modules are rarely implemented.

While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write MIB modules unless we have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purposes.

Here is the statement we came up with:
The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility
and consensus to use SNMP write operations for configuration.
Ideally, this should become an IESG statement.
Your feedback is most welcome.

Regards, the MIB doctors & Benoit

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Stefan Winter | 11 Feb 12:05 2014
Picon

EAP configuration metadata draft

Hello (adding ops-area <at> ),

I would like to draw your attention to my submission of
draft-winter-opsawg-eap-metadata-00 (
http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ ).

I would like to ask the community how they feel about this work - is it
needed, are we on the right track, etc.

As a teaser for why our group thinks this piece of work is important and
useful, please see the beginning of the Problem Statement section,
pasted here for your convenience:

"The IETF has produced the Extensible Authentication Protocol (EAP,
   [RFC3748] and numerous EAP methods (for example EAP-TTLS [RFC5281],
   EAP-TLS [RFC5216] and [RFC5931]); the methods have many properties
   which need to be setup on the EAP server and matched as configuration
   items on the EAP peer for a secure EAP deployment.

   Setting up these configuration items is comparatively easy if the
   end-user devices which implement the EAP peer functionality are under
   central administrative control, e.g. in closed enterprise
   environments.  Group policies or device provisioning by the IT
   department can push the settings to user devices.

   In other environments, for example "BYOD" scenarios where users bring
   their own devices which are not under enterprise control, or in EAP-
   based WISP environments (see e.g. [HS20] and
   [I-D.wierenga-ietf-eduroam]) where it is not desired neither for the
   ISP nor for his user that the device control is in the ISPs hands,
   configuration of EAP is significantly harder as it has to be done by
   potentially very non-technical end users."

There's plenty of proprietary approaches, they all vary in richness of
expressability, most don't have complete public schemas or are even in
binary with no explanations on how to construct them as an outsider.

We find the lack of a public specification disturbing.

It leads to duplication of efforts in numerous organisations,
incompatiblities between the produced formats, and sometimes simply
leads to bad quality specs.

BTW, I have teased the list earlier (see my posting on 18 Dec 2013), and
already got an on-list response (as well as offline).

I believe this warrants allocation of slot time in London, and I would
at this point ask the chairs if it's possible to get 5 mins (more if you
have plenty :-) ) to discuss the problem itself and the solution we've
put together in this first draft.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

Attachment (0x8A39DC66.asc): application/pgp-keys, 3251 bytes
Attachment (0x8A39DC66.asc): application/pgp-keys, 3249 bytes
_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Stefan Winter | 11 Feb 12:05 2014
Picon

New Version Notification for draft-winter-opsawg-eap-metadata-00.txt (fwd)


A new version of I-D, draft-winter-opsawg-eap-metadata-00.txt
has been successfully submitted by Stefan Winter and posted to the
IETF repository.

Name:		draft-winter-opsawg-eap-metadata
Revision:	00
Title:		A Configuration File Format for Extensible Authentication
Protocol (EAP) Deployments
Document date:	2014-02-10
Group:		Individual Submission
Pages:		17
URL:
http://www.ietf.org/internet-drafts/draft-winter-opsawg-eap-metadata-00.txt
Status:
https://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/
Htmlized:
http://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-00

Abstract:
   This document specifies a file format for transfering configuration
   information of deployments of the Extensible Authentication Protocol
   (EAP).  Such configuration files are meant to be discovered, consumed
   and used by EAP supplicant software to achieve secure and automatic
   EAP configuration on the consuming device.

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

The IETF Secretariat

Attachment (0x8A39DC66.asc): application/pgp-keys, 3251 bytes
Attachment (0x8A39DC66.asc): application/pgp-keys, 3249 bytes
_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Benoit Claise | 12 Nov 23:17 2013
Picon

IETF Working Group 88 High Level Summary

Dear all,

If you want high level summaries of what happened in the OPS WGs at this 
IETF.
http://trac.tools.ietf.org/area/ops/trac/wiki/IETF88summary
For the details, review the meeting minutes.

Regards, Benoit

Gmane