Benoit Claise | 29 Oct 22:12 2014
Picon

IETF 91 OPS open hours office

Dear all,

When: Monday Nov 10th, 1300-1500
Where: Rainbow Suite 1&2 in the Rainbow Tower (IESG meeting room)

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, so that we can schedule 
the different slots.

Regards, Joel and Benoit
Benoit Claise | 27 Oct 21:14 2014
Picon

call for agenda items for the OPSAREA open meeting at IETF-91

Dear all,

We are planning again for a joint OPSAWG and OPSAREA open meeting.
Please send us your requests for presentation and discussion slots.

Regards, Benoit
Benoit Claise | 30 Jul 16:49 2014
Picon

Fwd: cops-pr and sppi to historic

Dear OPS-AREA members,

Does anyone oppose to reclassify COPS-PR and SPPI to Historic?

Regards, Benoit


-------- Original Message -------- Subject: Date: From: Reply-To: To:
cops-pr and sppi to historic
Wed, 23 Jul 2014 06:32:06 +0200
Juergen Schoenwaelder <j.schoenwaelder <at> jacobs-university.de>
Juergen Schoenwaelder <j.schoenwaelder <at> jacobs-university.de>
Benoit Claise <bclaise <at> cisco.com>


Benoit, I have posted draft-schoenw-opsawg-copspr-historic-02 [1] and I like to request that you start the process described in [2] item 2. /js [1] https://datatracker.ietf.org/doc/draft-schoenw-opsawg-copspr-historic/ [2] http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html -- -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/>

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Benoit Claise | 2 Jul 18:14 2014
Picon

OPS open hours office

Dear all,

When: Monday 1520-1650 EDT
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
Benoit Claise | 25 Jun 19:33 2014
Picon

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.
So far, the agenda contains:
     1. github as tool for the IETF
     2. Transport Independent OAM in Multi-Layer network Entity (TIME)
     3. Network Function Virtualisation Configuration (NFVCon)

Thanks and Regards,

Joel and Benoit
Picon

New Liaison Statement, "LS on new work item on Generic Information Model for management of transport NE"

Title: LS on new work item on Generic Information Model for management of transport NE
Submission Date: 2014-04-23
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1320/

From: ITU-T SG 15  (Greg Jones <greg.jones <at> itu.int>)
To: Operations and Management Area (Benoit Claise <bclaise <at> cisco.com>, Joel Jaeggli <joelja <at> bogus.com>)
Cc: The IETF Chair <chair <at> ietf.org>,John Drake <jdrake <at> juniper.net>,Scott Mansfield <Scott.Mansfield <at> Ericsson.com>,ops-area <at> ietf.org
Response Contact: Kam.Lam <at> alcatel-lucent.com, scott.mansfield <at> ericsson.com
Technical Contact: 
Purpose: For information

Body: 
Attachments:

    LS on new work item on Generic Information Model for management of transport NE
    https://datatracker.ietf.org/documents/LIAISON/liaison-2014-04-23-itu-t-sg-15-ops-ls-on-new-work-item-on-generic-information-model-for-management-of-transport-ne-attachment-1.pdf
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
>>>   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?
>> 
>>    This is precisely what is the question: is the SET operation enabled in networks or not ?  I think the
overwhelming answer is "no". The discussions that are rabbit holing into questions like "what is
configuration?, "is it persistent, etc...?" are completely missing the point. The simple issue at hand
is the fact that boxes in networks are programmed to reject ANY SNMP SET operations.  This is what Randy was
channeling from operators the other day as well. We really need to listen to the operational feedback on
this one.
> 
> I agree Tom.  The larger question, at the end of the day, is how many models do we want to continue support.  Do
we want to define MIBs for statistics, and NETCONF for configuration, going forward, or do we want to, over
time, standardize on a single data model infrastructure (YANG?), that can then generate NETCONF, and
possibly MIBs, if MIBs are still desired for operational data collection?  I'm in favor of a common data
model definition, that can then be rendered into whatever protocols are deemed appropriate by the implementer.
> 
> Christopher
> 
>> 
>>    --Tom
>> 
>> 
>>> 
>>> Regards, Benoit
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OPS-AREA mailing list
>>> OPS-AREA <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/ops-area
>> 
>> _______________________________________________
>> OPS-AREA mailing list
>> OPS-AREA <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ops-area
> 
> 
> --
> 李柯睿
> Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc
> Current vCard here: http://www.asgaard.org/cdl/cdl.vcf
> 

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
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
> .
>

Gmane