headers
Yoshifumi Atarashi | 2 Mar 2007 03:24

data model I-Ds

We wrote 3 I-Ds.

First one is diffserv data model for homework of previous data model
meeting.
Second one is VLAN data model which will be standard document in JAPAN.
Last one, we're considering possibility NETCONF systems and coordination
with another systems.

	Title		: A NETCONF Datamodel for Diff-Serv QoS Control Configuration
	Author(s)	: H. Okita, et al.
	Filename	: draft-okita-ngo-diffservdatamodel-00.txt
	Pages		: 22
	Date		: 2007-2-27

	Title		: VLAN data model for NETCONF
	Author(s)	: T. Iijima, et al.
	Filename	: draft-iijima-ngo-vlandatamodel-00.txt
	Pages		: 17
	Date		: 2007-2-27

	Title		: Consideration of NETCONF Architecture
	Author(s)	: R. Atarashi, et al.
	Filename	: draft-atarashi-ngo-consider-architecture-00.txt
	Pages		: 32
	Date		: 2007-2-27

-------
   Yoshifumi Atarashi

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 2 Mar 2007 09:56
Favicon

FW: Documents on IESG Telechat Agenda for March 8, 2007


Please see below the documents on the agenda for next IESG telechat.
Please note that there are several MIB documents on the agenda this
time. I would appreciate if you can send me your reviews and comments by
Wednesday, March 7, 2007 COB. 

Thanks and Regards,

Dan

2. Protocol Actions
	Reviews should focus on these questions: "Is this document a
	reasonable basis on which to build the salient part of the
Internet
	infrastructure? If not, what changes would make it so?"

2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-ccamp-crankback-06.txt
    Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE (Proposed 
    Standard) - 1 of 12 
    Token: Ross Callon
  o draft-ietf-hubmib-efm-mib-06.txt
    Definitions and Managed Objects for OAM Functions on Ethernet Like 
    Interfaces (Proposed Standard) - 2 of 12 
    Note: Bert Wijnen is the PROTO shepherd 
    Token: Dan Romascanu
  o draft-ietf-idr-avoid-transition-04.txt
    Avoid BGP Best Path Transitions from One External to Another
(Proposed
(Continue reading)

Permalink | Reply | 1 comment |
headers
Romascanu, Dan (Dan | 9 Mar 2007 09:25
Favicon

Updated Agenda for the OPS AREA meetings in Prague


Following a number a comments I have updated the agenda for the OPS Area
meeting in Prague. Comments are still welcome. 

Dan

Meeting : IETF68, Monday March 19, 2007 and Wednesday March 21, 2007 

Location: Congress II, Monday March 19, 2007 15:20 to 17:20 and Congress
I, Wednesday March 21, 2007 13:00 to 16:10 

Chairs : David Kessens (david.kessens <at> nokia.com), Dan Romascanu
(dromasca <at> avaya.com), Ron Bonica (bonica <at> juniper.net) 

Jabber : ops <at> jabber.ietf.org URL : http://www.ops.ietf.org/ Agenda :
version 0.1 (draft)
============================================================== 

Meeting 1 - Monday March 19, 2007 15:20 to 17:20 

1. Meeting Administrivia ADs (total: 5 min) 

Mailing list and URL 
Minutes Scribe 
Jabber Scribe 
Blue Sheets 

2. Introduction of new Area Director - Ron Bonica (5 min) 

3. Mini-BOF A: - Manageability and Operational Guidelines - David
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tomoyuki Iijima | 9 Mar 2007 11:19
Picon

Re: [NGO] Updated Agenda for the OPS AREA meetings in Prague

Dear Dan,

> 7. Late Submission - requirements to tunneling protocols OAM - KIKUCHI
> Yutaka (total: 15 min) 
> 
> This draft describes requirements to measure end-to-end qualities of
> tunnels passively and to monitor them via SNMP. This feature is
> necessary for Service Providers, especially, who provide transports to
> users using tunnels. In addition, the draft shows an example to measure
> Generic Routing Encapsulation (GRE) tunnels. 
> 
> I-D:
> http://www.ietf.org/internet-drafts/draft-iijima-ngo-vlandatamodel-00.tx
> t 

This draft does not correspond to the presentation above.

Best regards,

--

-- 
Tomoyuki Iijima
Hitachi, Ltd. Central Research Laboratory
TEL:+81-42-323-1111 ext.3579
FAX:+81-42-327-7868
E-mail:tomoyuki.iijima.fg <at> hitachi.com

_______________________________________________
OPS-NM mailing list
OPS-NM <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ops-nm
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 9 Mar 2007 11:32
Favicon

RE: [NGO] Updated Agenda for the OPS AREA meetings in Prague

Sorry for the confusion. Is there a draft to support the presentation
that you will be making in Prague? 

Dan

> -----Original Message-----
> From: Tomoyuki Iijima [mailto:tomoyuki.iijima.fg <at> hitachi.com] 
> Sent: Friday, March 09, 2007 12:20 PM
> To: Romascanu, Dan (Dan)
> Cc: OPS Area; ngo <at> ietf.org; ops-nm <at> ietf.org; 
> aaa-doctors <at> ietf.org; MIB Doctors (E-mail); IETF MIBs; 
> ops-dir <at> ops.ietf.org; nmrg <at> ibr.cs.tu-bs.de
> Subject: Re: [NGO] Updated Agenda for the OPS AREA meetings in Prague
> 
> Dear Dan,
> 
> > 7. Late Submission - requirements to tunneling protocols 
> OAM - KIKUCHI 
> > Yutaka (total: 15 min)
> > 
> > This draft describes requirements to measure end-to-end 
> qualities of 
> > tunnels passively and to monitor them via SNMP. This feature is 
> > necessary for Service Providers, especially, who provide 
> transports to 
> > users using tunnels. In addition, the draft shows an example to 
> > measure Generic Routing Encapsulation (GRE) tunnels.
> > 
> > I-D:
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 12 Mar 2007 16:48
Favicon

http://www.ietf.org/internet-drafts/draft-harrington-operations-and-management-00.txt


I would suggest to as many folks as possible to red and provide comments
on
http://www.ietf.org/internet-drafts/draft-harrington-operations-and-mana
gement-00.txt prior to the meeting in Prague. This is an important
document for the OPS area, that could impact the work in other area of
the IETF in the future. 

Here are a few of my observations: 

1. Section 1

o  "new protocol" includes new protocols, protocol extensions, data
      models, or other functionality being designed.

I would include in this definition also 'the entities and functional
components implementing the protocol'

2. Section 2 - I believe that instead of 'Protocol designers typically
do not like to look at the management aspects of their new protocol.' we
should rather say 'Protocol designers typically do not take into
considerations the operational and management aspects of their new
protocol at the time of the protocol definition'

3. Section 2 - s/aspects of a protocol design that is unfamiliar to
them/aspects of a protocol design that are unfamiliar to them

4. Section 2 -   'This document is not about requiring all
internet-drafts to include a new "Operations and Management
Considerations" section.' I would add '... although it does not preclude
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 13 Mar 2007 01:48
Favicon

Question about draft-xu-cops-push-00.txt

I have a question related to
http://www.ietf.org/internet-drafts/draft-xu-cops-push-00.txt, which
will be the subject of a mini-BOF in the OPS Area meeting in Prague. The
document describes an optimization of COPS so that it can be used in a
push mode at a degree of efficiency that is similar to the one of the
pull mode for which the protocol was originally designed. What are the
use cases and application or applications that require using COPS in a
push mode? And if push mode is required, than why COPS? 

Thanks and Regards,

Dan

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ops-area
Permalink | Reply | 0 comments |
headers
Tom-PT Taylor | 13 Mar 2007 21:02
Favicon

Re: Question about draft-xu-cops-push-00.txt

The other individuals copied on this response are probably better qualified to 
answer, but I'll have a go.

The architecture, using ITU-T terminology, is as follows: the Policy Decision 
Function (PDF) sets policy. The Transport Enforcement function (TEF) enforces 
the policy. The interface between them is variously designated Rw (in the 
ITU-T), Ia (in TISPAN), Go/Gx (in 3GPP), or TC-1 (in the MultiService Forum). 
The particular role of the Rw interface is to carry admission decisions and 
related material such as NAT configuration requests and responses.

To broaden the picture, the Policy Decision Function gets requests from the 
P-CSCF (more abstractly, the Service Control Function, SCF). That interface is 
designated Rs in the ITU-T, Gq' in TISPAN, Gq in 3GPP, and TC-0 in the 
MultiService Forum. Everyone agrees that the protocol across that interface is 
Diameter, but there is variation in the AVPs that have to be supported.

The SCF, PDF, and TEF interact on a per-session basis. Whether push or pull mode 
is used depends on signalling capabilities at the user terminal and the access 
technology in use. That can vary from session to session.

To take the push mode example: suppose the terminal is unable to signal at the 
transport level (e.g. using RSVP or NSIS). Then the network has to act on its 
behalf. The terminal sends a SIP INVITE with SDP to the P-CSCF. The P-CSCF 
analyzes the SDP to determine the implied QoS requirements and the external 
transport addresses associated with the flow and passes an admission request on 
to the PDF. The PDF checks its sources of policy information to decide whether 
the flows can be admitted; if so, it sends a request down to the TEF to admit 
the flow and set up NATing (if applicable). The TEF returns the NAT address 
assignments, which the PDF passes back to the SCF in its response to the 
original request.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 14 Mar 2007 22:29
Favicon

comments on draft-natale-snmp-mibs-to-ontology-00


I have a few comments related to the proposals in
draft-natale-snmp-mibs-to-ontology-00. While I appreciate the problem
space and recognize its importance, it is far from clear to me how this
work could be structured in a future Working Group in the OPS Area. In
order to help the discussions in Prague I would make the following
observations: 

1. The document relates to SOA-based/Web services management. These
concepts are quite broad, and it would be useful for the seek of the
discussions in Prague if Bob could provide a reference (or more but not
many) that points to what he had in mind when using this terms in the
document

2. The term ontology that is being used here to describe the results of
the conversion process is broad, and defined by a few examples in the
text. We should probably discuss rather sooner which of the output
formats that would be dealt with by a future IETF activity

3. Defining data conversion tools and validation tools is something that
has not been done yet in the IETF, to the best of my knowledge. They are
however defined as 'primary outputs' for this effort. As I am not sure
that I understand how the future IETF documents would look like, I would
suggest that we make some more concrete proposals, maybe examples that
other have issued in this space. 

Dan

_______________________________________________
OPS-AREA mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juergen Schoenwaelder | 15 Mar 2007 08:24
Picon

Re: [nmrg] Re: Question about draft-xu-cops-push-00.txt

On Tue, Mar 13, 2007 at 04:02:57PM -0400, Tom-PT Taylor wrote:

> My co-authors can better explain the choice of COPS.

So can one of your co-authors please speak up and address Dan's
question in technical terms?

In particular, I like to know what you consider the essential
technical features making COPS-PR more desirable than other protocols
to push configuration information (like NETCONF) that seem to have
gained more community support during the last few years (at least in
the IETF).

/js

--

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ops-area
Permalink | Reply | 0 comments |

Gmane