From opsawg-bounces@ietf.org Wed Aug 01 13:30:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGI1J-0001QZ-Ta; Wed, 01 Aug 2007 13:30:01 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IGHyk-00009P-Sc for opsawg-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 13:27:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHyk-000091-Ie; Wed, 01 Aug 2007 13:27:22 -0400 Received: from mail1.acecape.com ([66.114.74.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGHyj-0004W3-Cr; Wed, 01 Aug 2007 13:27:22 -0400 Received: from pit.databus.com ([71.167.133.225]) (authenticated bits=0) by mail1.acecape.com (8.13.8/8.13.8) with ESMTP id l71HRKAs002212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Aug 2007 13:27:20 -0400 Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.14.1/8.14.1) with ESMTP id l71HRKro033497; Wed, 1 Aug 2007 13:27:20 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.14.1/8.14.1/Submit) id l71HRKud033496; Wed, 1 Aug 2007 13:27:20 -0400 (EDT) (envelope-from barney) Date: Wed, 1 Aug 2007 13:27:20 -0400 From: Barney Wolff Message-ID: <20070801172720.GA17072@pit.databus.com> References: <19EBBEC503C3B5469070E0A6674A533A59D74D@daebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A59D74D@daebe104.NOE.Nokia.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Spam-Score: 1.6 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Wed, 01 Aug 2007 13:30:00 -0400 Cc: opsawg@ietf.org, dime@ietf.org, radiusext@ops.ietf.org Subject: [OPSAWG] Re: FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org In the 1970s, Western Union's Infomaster message switch attached a "Suspected Duplicate" tag to every retransmitted message. I wonder if this tidbit was known to the examiners as relevant prior art. -- Barney Wolff I never met a computer I didn't like. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Wed Aug 01 13:30:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGI1J-0001QT-P7; Wed, 01 Aug 2007 13:30:01 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IGHnE-0007sS-Ia for opsawg-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 13:15:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHnA-0007qS-Lv; Wed, 01 Aug 2007 13:15:24 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGHn8-0005Ib-Ba; Wed, 01 Aug 2007 13:15:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l71HF26X013853; Wed, 1 Aug 2007 20:15:17 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 20:15:16 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 12:15:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Aug 2007 12:15:02 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A59D74D@daebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Thread-Index: AcfUTlY2JnIgGVJeSrmDIKoz0szKWwAENHjA From: To: , , X-OriginalArrivalTime: 01 Aug 2007 17:15:06.0937 (UTC) FILETIME=[81E18290:01C7D45F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b83962958e2d910ed948e2f9e138d171 X-Mailman-Approved-At: Wed, 01 Aug 2007 13:30:00 -0400 Cc: Subject: [OPSAWG] FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2015555730==" Errors-To: opsawg-bounces@ietf.org This is a multi-part message in MIME format. --===============2015555730== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D45F.8194DEFE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D45F.8194DEFE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I was asked to forward this to the DiME, RADext and OPSA WG mailing = lists. =20 =20 Thanks, John Dear Stefan, I asked John to forward this message as I'm not a regular on the DIME = list. I'm responsible for handling IETF related IPR cases in Nokia. As you suggested, Nokia believes EP1147635, and other members of the = same patent family, are essential to practice RFC3588. However, I do suggest that you, and other folks interested, contact = your respective legal folks regarding the implication of the existence = of the patent, in conjunction with our patent declaration. I do not = believe that Stefan's claim is correct: Every implementation of the =20 Diameter base protocol will use the patented technology and=20 needs to either license it or will violate it.=20 In order to help the group to understand our declaration, please allow = me to provide a simplistic explanation. As for the binding legal = language, please see the declaration itself (cited correctly by Stefan = in his original email): Nokia agrees not to assert those claims in Nokia above =20 mentioned patents that apply to the RFC3588 and are=20 technically necessary to implement this IETF standard=20 specification against any other party in respect of its=20 implementation of the specification, provided that the party=20 relying on this commitment does not assert its patents against Nokia. Our licensing declaration is what is commonly known as a "non-assert" = statement. What it says is that if you don't come after Nokia with your = patents, Nokia will not use its patents against your RFC 3588 = implementation. =20 Non-assert statements like this are widely used in the IETF, as they = are believed to provide sufficient defensive protection for the owner, = while still allowing implementers and users to exercise the protected = technology without a license and for free, as long as they behave = similarly nice (i.e. not going after Nokia with their patents). In = that, non-asserts are believed to be compatible with most open source = licenses. =09 =09 Feel free to contact me in private if you have more questions. =20 Best regards, Stephan Wenger Stephan.Wenger@nokia.com =20 -----Original Message----- From: ext Stefan Winter [mailto:stefan.winter@restena.lu]=20 Sent: 01 August, 2007 15:28 To: radiusext@ops.ietf.org; dime@ietf.org Subject: [Dime] First results on Diameter vs. RadSec patent=20 research:EP1147635 Hello all, (sorry for cross-posting, this may also be of interest for dime) when presenting the RadSec draft in IETF69 Chicago, I=20 mentioned the patent claims of Nokia concerning Diameter. As a=20 reaction, some participants claimed that RadSec itself=20 implements a subset of the Diameter features and may very well=20 itself be subject to these patents. So I started an=20 investigation in this respect. I started the research myself by grabbing a copy of patent=20 EP1147635 by Nokia, which is claiming to affect Diameter. My=20 focus of the patent's examination was whether this patent=20 might also affect RadSec. The content of this patent is, in short, that packets on a=20 network get tagged as "possible duplicate" on retransmission=20 in order to make the endpoint aware that the received content=20 may be a duplicate of a previous packet. It also provides a=20 mechanism to correlate the multiple copies even when the=20 packets took different paths through the network. Diameter does exactly that, described in section 5.5.4=20 "Failover and Failback Procedures" of RFC3588: a bit in the=20 Diameter header, the "T" bit, is set whenever a Diameter=20 packet needed to be retransmitted. Also, Diameter packets=20 carry an end-to-end identifier that makes it possible to=20 identify duplicates. This means that at least from my point of view, Nokia's claim=20 concerning Diameter is true. Every implementation of the=20 Diameter base protocol will use the patented technology and=20 needs to either license it or will violate it.=20 (Note: I am not a lawyer. This is just my interpretation;=20 consider my knowledge being "Slashdot-level"). From the wording in this section 5.5.4 and the explanation of=20 the T bit in chapter 3, it seems that setting the T bit is=20 mandatory on retransmissions, so adhering to the protocol=20 specification leaves no room for circumventing the content of=20 the patent (e.g., by keeping it 0 at all times). Luckily, RadSec does not implement such a sophisticated=20 duplicate packet detection algorithm. So, this particular=20 patent appears not to be of any concern for implementors of RadSec. I will continue investigating the bunch of other patents and=20 patent applications relating to Diameter as soon as I get=20 copies of them. For reference, here is Nokia's claim statement=20 concerning Diameter (as submitted to the IETF IPR tracker): ---------- Title: Nokia's Statement About IPR Claimed in RFC 3588 Received: January 6, 2004 From: harri.t.honkasalo@nokia.com This is to advise the IETF that Nokia believes the Nokia patents: EP1147635 and AU757984, and the related patent applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102, JP2000-595452 and US09/903863 may be relevant to Diameter Base=20 Protocol RFC3588. Nokia agrees not to assert those claims in Nokia above=20 mentioned patents that apply to the RFC3588 and are=20 technically necessary to implement this IETF standard=20 specification against any other party in respect of its=20 implementation of the specification, provided that the party=20 relying on this commitment does not assert its patents against Nokia. Regards, Harri Honkasalo Director of IPR, Standard Technology Nokia Corporation ---------- Greetings, Stefan Winter -- Stefan WINTER RESTENA Foundation - R=E9seau T=E9l=E9informatique de l'Education=20 Nationale et de la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu Tel.: +352 424409-1=20 http://www.restena.lu Fax: +352 422473 =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C7D45F.8194DEFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I was asked to forward this to the DiME, = RADext=20 and OPSA WG mailing lists.  
 
Thanks,
John

Dear Stefan,

I asked John to forward this message as I'm not a regular on the = DIME=20 list.  I'm responsible for handling IETF related IPR cases in=20 Nokia.

As you suggested, Nokia believes EP1147635, and other members of = the same=20 patent family, are essential to practice RFC3588.

However, I do suggest that you, and other folks interested, = contact your=20 respective legal folks regarding the implication of the existence of = the=20 patent, in conjunction with our patent declaration.  I do not = believe=20 that Stefan's claim is correct:
Every=20 implementation of the 
Diameter base protocol will use the patented = technology=20 and 
needs to either license it or will violate=20 it. 

In order to help the group to understand our declaration, please = allow me=20 to provide a simplistic explanation.  As for the binding legal = language,=20 please see the declaration itself (cited correctly by Stefan in his = original=20 email):

Nokia agrees not to assert those claims in = Nokia=20 above 
mentioned patents that apply to the = RFC3588 and=20 are 
technically necessary to implement this = IETF=20 standard 
specification against any other party = in respect=20 of its 
implementation of the specification, = provided=20 that the party 
relying on this commitment does not = assert its=20 patents against Nokia.

Our licensing declaration is what is commonly known as a = "non-assert"=20 statement.  What it says is that if you don't come after Nokia = with your=20 patents, Nokia will not use its patents against your RFC 3588=20 implementation.
  
Non-assert statements like this are widely used in the IETF, as = they are=20 believed to provide sufficient defensive protection for the owner, = while still=20 allowing implementers and users to exercise the protected technology = without a=20 license and for free, as long as they behave similarly nice (i.e. not = going=20 after Nokia with their patents).  In that, non-asserts are = believed to be=20 compatible with most open source licenses.
Feel free to contact me in private if you have more = questions.
 
Best regards,
Stephan Wenger
Stephan.Wenger@nokia.com
 
 -----Original=20 Message-----
From: ext Stefan Winter [mailto:stefan.winter@restena.lu<= /A>] 
Sent: 01 August, 2007 15:28
To: radiusext@ops.ietf.org; = dime@ietf.org
Subject: [Dime] First results on = Diameter vs.=20 RadSec patent 
research:EP1147635

Hello all,

(sorry for cross-posting, this may also = be of=20 interest for dime)

when presenting the RadSec draft in = IETF69=20 Chicago, I 
mentioned the patent claims of Nokia = concerning=20 Diameter. As a 
reaction, some participants claimed = that RadSec=20 itself 
implements a subset of the Diameter = features and=20 may very well 
itself be subject to these patents. So = I started=20 an 
investigation in this respect.

I started the research myself by = grabbing a copy=20 of patent 
EP1147635 by Nokia, which is claiming = to affect=20 Diameter. My 
focus of the patent's examination was = whether=20 this patent 
might also affect RadSec.

The content of this patent is, in = short, that=20 packets on a 
network get tagged as "possible = duplicate" on=20 retransmission 
in order to make the endpoint aware = that the=20 received content 
may be a duplicate of a previous = packet. It also=20 provides a 
mechanism to correlate the multiple = copies even=20 when the 
packets took different paths through = the=20 network.

Diameter does exactly that, described = in section=20 5.5.4 
"Failover and Failback Procedures" of = RFC3588: a=20 bit in the 
Diameter header, the "T" bit, is set = whenever a=20 Diameter 
packet needed to be retransmitted. = Also, Diameter=20 packets 
carry an end-to-end identifier that = makes it=20 possible to 
identify duplicates.

This means that at least from my point = of view,=20 Nokia's claim 
concerning Diameter is true. Every = implementation=20 of the 
Diameter base protocol will use the = patented=20 technology and 
needs to either license it or will = violate=20 it. 
(Note: I am not a lawyer. This is just = my=20 interpretation; 
consider my knowledge being=20 "Slashdot-level").
From the wording in this section 5.5.4 = and the=20 explanation of 
the T bit in chapter 3, it seems that = setting the=20 T bit is 
mandatory on retransmissions, so = adhering to the=20 protocol 
specification leaves no room for = circumventing=20 the content of 
the patent (e.g., by keeping it 0 at = all=20 times).

Luckily, RadSec does not implement such = a=20 sophisticated 
duplicate packet detection algorithm. = So, this=20 particular 
patent appears not to be of any concern = for=20 implementors of RadSec.

I will continue investigating the bunch = of other=20 patents and 
patent applications relating to = Diameter as soon=20 as I get 
copies of them. For reference, here is = Nokia's=20 claim statement 
concerning Diameter (as submitted to = the IETF IPR=20 tracker):

----------

Title: Nokia's Statement About IPR = Claimed in RFC=20 3588
Received: January 6, 2004
From: harri.t.honkasalo@nokia.com

This is to advise the IETF that Nokia = believes=20 the Nokia
patents: EP1147635 and AU757984, and = the related=20 patent
applications: BRPI0007603-1, CA2360093, = CN00804050.8, FI990102,
JP2000-595452 and US09/903863 may be = relevant to=20 Diameter Base 
Protocol RFC3588.

Nokia agrees not to assert those claims = in Nokia=20 above 
mentioned patents that apply to the = RFC3588 and=20 are 
technically necessary to implement this = IETF=20 standard 
specification against any other party = in respect=20 of its 
implementation of the specification, = provided=20 that the party 
relying on this commitment does not = assert its=20 patents against Nokia.

Regards,

Harri Honkasalo

Director of IPR, Standard = Technology

Nokia Corporation

----------


Greetings,

Stefan Winter

--
Stefan WINTER

RESTENA Foundation - R=E9seau = T=E9l=E9informatique de=20 l'Education 
Nationale et de la Recherche R&D=20 Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: stefan.winter@restena.lu =  =20   Tel.:     +352 424409-1 
http://www.restena.lu   =  =20           Fax:      +352=20 422473

<signature.asc>
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.or= g/mailman/listinfo/dime

------_=_NextPart_001_01C7D45F.8194DEFE-- --===============2015555730== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg --===============2015555730==-- From opsawg-bounces@ietf.org Thu Aug 02 08:04:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGZPN-00072i-6d; Thu, 02 Aug 2007 08:04:01 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IGJQf-0003Gy-7x for opsawg-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 15:00:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJQe-0003Gq-Sa; Wed, 01 Aug 2007 15:00:16 -0400 Received: from bay0-omc2-s17.bay0.hotmail.com ([65.54.246.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGJQd-00081l-Uz; Wed, 01 Aug 2007 15:00:16 -0400 Received: from hotmail.com ([207.46.8.96]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 1 Aug 2007 12:00:15 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 1 Aug 2007 12:00:14 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 01 Aug 2007 19:00:10 GMT X-Originating-IP: [131.107.0.74] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A59D74D@daebe104.NOE.Nokia.com> From: "Bernard Aboba" To: opsawg@ietf.org, dime@ietf.org, radiusext@ops.ietf.org Bcc: Date: Wed, 01 Aug 2007 12:00:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 01 Aug 2007 19:00:14.0812 (UTC) FILETIME=[31AAD9C0:01C7D46E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e X-Mailman-Approved-At: Thu, 02 Aug 2007 08:04:00 -0400 Cc: Subject: [OPSAWG] RE: FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Please note that the publication date of RFC 3588 (which included a Nokia author) was September 2003, and that this Nokia IPR claim was submitted to the IETF on January 6, 2004, several months after the Diameter RFC was published. As co-chair of the AAA WG, I would not have allowed RFC 3588 to be submitted to the IESG for publication without WG discussion of the IPR claim, had the IPR claim been submitted prior to publication of the Diameter RFC. >From: >To: , , >Subject: FW: Nokia Patent discussion FW: [Dime] First results on Diameter >vs. RadSec patent research:EP1147635 >Date: Wed, 1 Aug 2007 12:15:02 -0500 > >Hi all, > >I was asked to forward this to the DiME, RADext and OPSA WG mailing lists. > >Thanks, >John > > > Dear Stefan, > > I asked John to forward this message as I'm not a regular on the DIME >list. I'm responsible for handling IETF related IPR cases in Nokia. > > As you suggested, Nokia believes EP1147635, and other members of the same >patent family, are essential to practice RFC3588. > > However, I do suggest that you, and other folks interested, contact your >respective legal folks regarding the implication of the existence of the >patent, in conjunction with our patent declaration. I do not believe that >Stefan's claim is correct: > > Every implementation of the > Diameter base protocol will use the patented technology and > needs to either license it or will violate it. > > > In order to help the group to understand our declaration, please allow me >to provide a simplistic explanation. As for the binding legal language, >please see the declaration itself (cited correctly by Stefan in his >original email): > > > Nokia agrees not to assert those claims in Nokia above > mentioned patents that apply to the RFC3588 and are > technically necessary to implement this IETF standard > specification against any other party in respect of its > implementation of the specification, provided that the party > relying on this commitment does not assert its patents against Nokia. > > > Our licensing declaration is what is commonly known as a "non-assert" >statement. What it says is that if you don't come after Nokia with your >patents, Nokia will not use its patents against your RFC 3588 >implementation. > > Non-assert statements like this are widely used in the IETF, as they are >believed to provide sufficient defensive protection for the owner, while >still allowing implementers and users to exercise the protected technology >without a license and for free, as long as they behave similarly nice (i.e. >not going after Nokia with their patents). In that, non-asserts are >believed to be compatible with most open source licenses. > > > Feel free to contact me in private if you have more questions. > > Best regards, > Stephan Wenger > Stephan.Wenger@nokia.com > > -----Original Message----- > > From: ext Stefan Winter [mailto:stefan.winter@restena.lu] > Sent: 01 August, 2007 15:28 > To: radiusext@ops.ietf.org; dime@ietf.org > Subject: [Dime] First results on Diameter vs. RadSec patent > research:EP1147635 > > Hello all, > > (sorry for cross-posting, this may also be of interest for dime) > > when presenting the RadSec draft in IETF69 Chicago, I > mentioned the patent claims of Nokia concerning Diameter. As a > reaction, some participants claimed that RadSec itself > implements a subset of the Diameter features and may very well > itself be subject to these patents. So I started an > investigation in this respect. > > I started the research myself by grabbing a copy of patent > EP1147635 by Nokia, which is claiming to affect Diameter. My > focus of the patent's examination was whether this patent > might also affect RadSec. > > The content of this patent is, in short, that packets on a > network get tagged as "possible duplicate" on retransmission > in order to make the endpoint aware that the received content > may be a duplicate of a previous packet. It also provides a > mechanism to correlate the multiple copies even when the > packets took different paths through the network. > > Diameter does exactly that, described in section 5.5.4 > "Failover and Failback Procedures" of RFC3588: a bit in the > Diameter header, the "T" bit, is set whenever a Diameter > packet needed to be retransmitted. Also, Diameter packets > carry an end-to-end identifier that makes it possible to > identify duplicates. > > This means that at least from my point of view, Nokia's claim > concerning Diameter is true. Every implementation of the > Diameter base protocol will use the patented technology and > needs to either license it or will violate it. > (Note: I am not a lawyer. This is just my interpretation; > consider my knowledge being "Slashdot-level"). > From the wording in this section 5.5.4 and the explanation of > the T bit in chapter 3, it seems that setting the T bit is > mandatory on retransmissions, so adhering to the protocol > specification leaves no room for circumventing the content of > the patent (e.g., by keeping it 0 at all times). > > Luckily, RadSec does not implement such a sophisticated > duplicate packet detection algorithm. So, this particular > patent appears not to be of any concern for implementors of RadSec. > > I will continue investigating the bunch of other patents and > patent applications relating to Diameter as soon as I get > copies of them. For reference, here is Nokia's claim statement > concerning Diameter (as submitted to the IETF IPR tracker): > > ---------- > > Title: Nokia's Statement About IPR Claimed in RFC 3588 > Received: January 6, 2004 > From: harri.t.honkasalo@nokia.com > > This is to advise the IETF that Nokia believes the Nokia > patents: EP1147635 and AU757984, and the related patent > applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102, > JP2000-595452 and US09/903863 may be relevant to Diameter Base > Protocol RFC3588. > > Nokia agrees not to assert those claims in Nokia above > mentioned patents that apply to the RFC3588 and are > technically necessary to implement this IETF standard > specification against any other party in respect of its > implementation of the specification, provided that the party > relying on this commitment does not assert its patents against Nokia. > > Regards, > > Harri Honkasalo > > Director of IPR, Standard Technology > > Nokia Corporation > > ---------- > > > Greetings, > > Stefan Winter > > -- > Stefan WINTER > > RESTENA Foundation - Réseau Téléinformatique de l'Education > Nationale et de la Recherche R&D Engineer > > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > email: stefan.winter@restena.lu Tel.: +352 424409-1 > http://www.restena.lu Fax: +352 422473 > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Thu Aug 09 04:01:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2xy-0006gt-AA; Thu, 09 Aug 2007 04:01:58 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IJ2xx-0006gc-0z for opsawg-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 04:01:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2xt-0006XF-76 for opsawg@ietf.org; Thu, 09 Aug 2007 04:01:53 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ2xs-0004bK-KJ for opsawg@ietf.org; Thu, 09 Aug 2007 04:01:53 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Aug 2007 04:01:51 -0400 X-IronPort-AV: i="4.19,239,1183348800"; d="scan'208"; a="45981342:sNHT9061056" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPSAWG] SMI-to-XSD mapping work Date: Thu, 9 Aug 2007 10:01:10 +0200 Message-ID: In-Reply-To: <002101c7d2cd$0cd4cdb0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] SMI-to-XSD mapping work Thread-Index: AcfSa+BP1e0nn+TSTmO7K7Zi6fM1KwAWpoowAeUdk/A= References: <01fc01c7d069$d0f2b920$79aa1cac@china.huawei.com><20070729083730.GA6607@elstar.local><000401c7d1f0$ef700280$0600a8c0@china.huawei.com><20070730053831.GA6941@elstar.local> <002101c7d2cd$0cd4cdb0$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: opsawg@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Speaking as a contributor, I support doing this work. I believe it is high priority for the reasons pointed by David, and the OPSAWG could be the appropriate home. I do not see a problem in running parallel data modeling efforts, provided that they are distinct in scope and in time span. The architecture that we have put in place for management protocols (actually not limited to management only) allows for the combinations of protocols and data modeling languages to work together.=20 Dan =20 =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Monday, July 30, 2007 8:14 PM > To: j.schoenwaelder@jacobs-university.de > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] SMI-to-XSD mapping work >=20 > Hi Juergen, > =20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > I do not question any of the motivation. My concern, however, > remains > > that the existence of the translated XSD output will cause future > data > > modeling languages to be "consistent" with the XSD output=20 > coming out=20 > > of the translation. For me, a NETCONF data modeling language and > SMIv2 > > translations should go hand in hand and not be separate efforts. > >=20 >=20 > I think the efforts should be coordinated, but can be different.=20 >=20 > To my knowledge there are three "teams" working on NETCONF=20 > data modeling - pure-XSD, and two unpublished specs (NCX and=20 > Yang). I have discussed the SMI-to-XSD work with leaders of=20 > each of these teams, and all agree that a common XSD for MIB=20 > access makes sense. I do not think they feel constrained by=20 > such an effort. >=20 > You didn't attend the XSDMI BOF. The XSDMI BOF was filled=20 > primarily with people who are active in NETCONF, including=20 > the leaders of the three teams, and the consensus was 13 for=20 > doing this work, and zero against. >=20 > One reason I view the separation of this work to be=20 > acceptable is that the SMI-to-XSD effort is fairly simple=20 > translation work from one modeling langauge to another; it=20 > can be done by engineers with a reasonable amount of skill in=20 > SMI and XSD - a junior programmer could do most of the work=20 > in this effort, with technical reviews done by more=20 > experienced SMI and XSD engineers. We have three editors=20 > willing to document the translations, and thirteen willing=20 > reviewers, including the leaders of the three NETCONF teams. >=20 > The work being done in the NCX and Yang efforts is to develop=20 > a completely new modeling language; this (and the work with=20 > pure-XSD) requires the expertise of people with years of=20 > experience with SMI and XML, a profound understanding of the=20 > limitations of the SMI and the limitations of XML/XSD, and=20 > years of experience developing language tools. This requires=20 > senior programmer/architect skills. >=20 > I will point out that many of the current NETCONF leaders=20 > could not reach consensus on a new data modeling langauge in=20 > the failed SMING WG. I do not believe that all IETF protocols=20 > should be denied XML-based access to MIB data just because=20 > the NETCONF community cannot achieve consensus on a new data=20 > modeling language.=20 >=20 > There is work that can be done now to allow access to MIB=20 > data by XML-based protocols, that will not constrain the=20 > "star" developers in their efforts, and will allow the whole=20 > IETF to better utilize the standard MIB objects have=20 > developed over the past twenty years. >=20 > This work should NOT be gated on NETCONF data modeling consensus. >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www1.ietf.org/mailman/listinfo/opsawg >=20 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Fri Aug 10 12:56:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJXmx-0005VT-9z; Fri, 10 Aug 2007 12:56:39 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IJXmw-0005Ux-FK for opsawg-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 12:56:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJXmv-0005Uc-Rx; Fri, 10 Aug 2007 12:56:37 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJXmu-0001rA-L8; Fri, 10 Aug 2007 12:56:37 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007081016563601500pgi2ae>; Fri, 10 Aug 2007 16:56:36 +0000 From: "David Harrington" To: , , , , Date: Fri, 10 Aug 2007 12:56:32 -0400 Message-ID: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfbb2b9suLKNKJQT1+oNHHgTQiURA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [OPSAWG] XSDMI work X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi, The XSDMI BOF proposed the creation of a WG to develop 1) the XSD equivalents of datatypes and textual conventions from SMIv2, and 2) algorithms to translate MIB module specifications into XSD equivalents. The BOF demonstrated community support for these two work items. People in the BOF volunteered to commit to being editors (3) and reviewers (14) for these work items. Starting documents and implementations already exist. The work is expected to take less than 12 months. At Dan's suggestion, rather than starting a new WG for this work, we have proposed that the SMI-to-XSD translation work be done in the OPSAWG. The OPSAWG chairs need to determine whether the OPSAWG WG should accept this work. Please send email to opsawg@ietf.org with comments about your support/lack of support for having the OPSAWG do this work. (If you do not subscribe to opsawg, you might want to do so, in order to follow the discussions.) David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Aug 12 04:35:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK8vM-0000Za-Ck; Sun, 12 Aug 2007 04:35:48 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IJYGY-0003eF-Jb for opsawg-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 13:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYGY-0003e7-8G for opsawg@ietf.org; Fri, 10 Aug 2007 13:27:14 -0400 Received: from smtp113.sbc.mail.re2.yahoo.com ([68.142.229.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IJYGX-0002x9-3O for opsawg@ietf.org; Fri, 10 Aug 2007 13:27:14 -0400 Received: (qmail 19580 invoked from network); 10 Aug 2007 17:20:33 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp113.sbc.mail.re2.yahoo.com with SMTP; 10 Aug 2007 17:20:33 -0000 X-YMail-OSG: 5YbGH1kVM1laI9JAbitXA1RfgJFCfe0m7.8titlRT4MQm.iePsMevKglmdqwDDyzDoaLJOkkNdss1XKuHfPes14ufoEbZFSpdq33f_XXaOapaOfj5DuZ.Q-- Message-ID: <46BC9E07.3030502@andybierman.com> Date: Fri, 10 Aug 2007 10:19:03 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David Harrington References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> In-Reply-To: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Sun, 12 Aug 2007 04:35:47 -0400 Cc: ngo@ietf.org, mib2rdml@ietf.org, opsawg@ietf.org, ops-nm@ietf.org Subject: [OPSAWG] Re: [NGO] XSDMI work X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org David Harrington wrote: > Hi, > > The XSDMI BOF proposed the creation of a WG to develop 1) the XSD > equivalents of datatypes and textual conventions from SMIv2, and 2) > algorithms to translate MIB module specifications into XSD > equivalents. The BOF demonstrated community support for these two work > items. > > People in the BOF volunteered to commit to being editors (3) and > reviewers (14) for these work items. Starting documents and > implementations already exist. The work is expected to take less than > 12 months. > > At Dan's suggestion, rather than starting a new WG for this work, we > have proposed that the SMI-to-XSD translation work be done in the > OPSAWG. > I have an objection to this "translation" work. You will make all kinds of assumptions about data organization and data naming, and I'm not sure what people are supposed to do with the XSDs. The term "XSD translation" is misleading. The XML on the wire is what is at stake here. The smidump translation of a MIB has SNMP operations built into it. Is this work supposed to produce a standard way to send an SNMP PDU over any protocol designed to encode SNMP PDUs in XML? Why do we need this? Is the charter going to state that the XSD translation will be suitable for use for any particular protocol? NETCONF needs to standardize XML data organization, namespace usage, and Xpath-based data naming. Is this translation going to be compatible with that standard when it eventually comes out? I would like the charter to be clear on the purpose of this work item, and what 'protocols' are signed up to use it. > The OPSAWG chairs need to determine whether the OPSAWG WG should > accept this work. Please send email to opsawg@ietf.org with comments > about your support/lack of support for having the OPSAWG do this work. > (If you do not subscribe to opsawg, you might want to do so, in order > to follow the discussions.) > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > Andy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Aug 13 10:32:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKayT-0005TY-T8; Mon, 13 Aug 2007 10:32:53 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IKayS-0005T2-Ne for opsawg-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 10:32:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKayO-0005Qh-50; Mon, 13 Aug 2007 10:32:48 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKayM-0006j6-Tl; Mon, 13 Aug 2007 10:32:48 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 13 Aug 2007 07:32:45 -0700 Received: from [172.23.1.110] ([172.23.1.110] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:32:44 -0400 Message-ID: <46C06B7B.6080709@juniper.net> Date: Mon, 13 Aug 2007 10:32:27 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Bierman Subject: Re: [OPSAWG] Re: [NGO] XSDMI work References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> <46BC9E07.3030502@andybierman.com> In-Reply-To: <46BC9E07.3030502@andybierman.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 14:32:44.0721 (UTC) FILETIME=[D0065210:01C7DDB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ngo@ietf.org, mib2rdml@ietf.org, opsawg@ietf.org, ops-nm@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Andy, David, Permit me to ask a few dumb questions so that I can understand a) what David is proposing and b) why Andy is objecting. AFAIKS, David is proposing the following: - a mapping from SMIv2 TCs to XSD types - a mechanism to translate SNMP MIBS to XSD. The XSD is an XML schema that is independent of the protocol that is used to shuffle the data back and forth. In one respect, it is a bit like Esperanto. It strength is that it omits the details that make it inappropriate for one protocol or the other. But at the same time, it's weakness is that it lacks the detail that would be required by any protocol. David, Andy, do I have this right? If so, could you guys point out what some of those omitted/lacking details are? /speaking as individual contributor /and by no means a data modeling expert Ron Andy Bierman wrote: > David Harrington wrote: > >> Hi, >> >> The XSDMI BOF proposed the creation of a WG to develop 1) the XSD >> equivalents of datatypes and textual conventions from SMIv2, and 2) >> algorithms to translate MIB module specifications into XSD >> equivalents. The BOF demonstrated community support for these two work >> items. >> People in the BOF volunteered to commit to being editors (3) and >> reviewers (14) for these work items. Starting documents and >> implementations already exist. The work is expected to take less than >> 12 months. >> >> At Dan's suggestion, rather than starting a new WG for this work, we >> have proposed that the SMI-to-XSD translation work be done in the >> OPSAWG. >> > > I have an objection to this "translation" work. > You will make all kinds of assumptions about data organization > and data naming, and I'm not sure what people are supposed > to do with the XSDs. > > The term "XSD translation" is misleading. > The XML on the wire is what is at stake here. > The smidump translation of a MIB has SNMP operations > built into it. Is this work supposed to produce > a standard way to send an SNMP PDU over any protocol > designed to encode SNMP PDUs in XML? Why do we need this? > > Is the charter going to state that the XSD translation will > be suitable for use for any particular protocol? > NETCONF needs to standardize XML data organization, > namespace usage, and Xpath-based data naming. > Is this translation going to be compatible with that standard > when it eventually comes out? > > I would like the charter to be clear on the purpose of this work item, > and what 'protocols' are signed up to use it. > > >> The OPSAWG chairs need to determine whether the OPSAWG WG should >> accept this work. Please send email to opsawg@ietf.org with comments >> about your support/lack of support for having the OPSAWG do this work. >> (If you do not subscribe to opsawg, you might want to do so, in order >> to follow the discussions.) >> >> David Harrington >> dbharrington@comcast.net >> ietfdbh@comcast.net >> >> > > > Andy > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www1.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Aug 13 12:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKd06-0008WF-Pz; Mon, 13 Aug 2007 12:42:42 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IKcFf-00070H-Rh for opsawg-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 11:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKcFf-000700-Hj for opsawg@ietf.org; Mon, 13 Aug 2007 11:54:43 -0400 Received: from smtp118.sbc.mail.sp1.yahoo.com ([69.147.64.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IKcFe-0000nC-2O for opsawg@ietf.org; Mon, 13 Aug 2007 11:54:43 -0400 Received: (qmail 73280 invoked from network); 13 Aug 2007 15:54:41 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2007 15:54:41 -0000 X-YMail-OSG: 33OB0RMVM1k2J_X9YvyJwjayZywHJDWiBWyNIWNoW.8N4GwRP3M1sUke.cADMTOSCDB9fnPQ_qjo52D_N2wKonOr Message-ID: <46C07E65.8080503@andybierman.com> Date: Mon, 13 Aug 2007 08:53:09 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [OPSAWG] Re: [NGO] XSDMI work References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> <46BC9E07.3030502@andybierman.com> <46C06B7B.6080709@juniper.net> In-Reply-To: <46C06B7B.6080709@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 X-Mailman-Approved-At: Mon, 13 Aug 2007 12:42:42 -0400 Cc: ngo@ietf.org, mib2rdml@ietf.org, opsawg@ietf.org, ops-nm@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Ron Bonica wrote: > Andy, David, > > Permit me to ask a few dumb questions so that I can understand a) what > David is proposing and b) why Andy is objecting. > > AFAIKS, David is proposing the following: > > - a mapping from SMIv2 TCs to XSD types > - a mechanism to translate SNMP MIBS to XSD. > > The XSD is an XML schema that is independent of the protocol that is > used to shuffle the data back and forth. In one respect, it is a bit > like Esperanto. It strength is that it omits the details that make it > inappropriate for one protocol or the other. But at the same time, it's > weakness is that it lacks the detail that would be required by any protocol. > That's the pretty picture from 10000 feet > David, Andy, do I have this right? If so, could you guys point out what > some of those omitted/lacking details are? The XSD is going to contain clauses that specify how data naming works for the multiple conceptual instances of the 'table row' (i.e., some ancestor node of all index nodes). In order to be useful for a particular protocol, this naming scheme must be compatible with that protocol. The conceptual data structures are going to use data types that must be supported in that protocol, which impacts DM design. In order to be useful for any protocol, another document would be needed that maps every detail in the SMI-to-XSD algorithm to every detail of the operations (verbs) for that protocol. This is 90% of the work. This generic SMI-to-XSD mapping is the other 10%. IMO, this just complicates things. I would rather the 90% document be 100%, and map SMIv2 directly to the protocol, rather than mapping from SMIv2 to an XSD info model, and then to the protocol. The current proposal contains lots of SNMP-specific details, like engine-IDs, contexts, and max-repetitions. This suggests that the mapping is for SNMP, not SMIv2. IMO, seamless integration of MIB-based data into the NETCONF protocol is an interesting problem to solve. Using a NETCONF session to send SNMP PDUs in XML to the NETCONF agent, who will forward it to the SNMP agent, is not an interesting problem to solve. Andy > > /speaking as individual contributor > /and by no means a data modeling expert > Ron > > > Andy Bierman wrote: >> David Harrington wrote: >> >>> Hi, >>> >>> The XSDMI BOF proposed the creation of a WG to develop 1) the XSD >>> equivalents of datatypes and textual conventions from SMIv2, and 2) >>> algorithms to translate MIB module specifications into XSD >>> equivalents. The BOF demonstrated community support for these two work >>> items. >>> People in the BOF volunteered to commit to being editors (3) and >>> reviewers (14) for these work items. Starting documents and >>> implementations already exist. The work is expected to take less than >>> 12 months. >>> >>> At Dan's suggestion, rather than starting a new WG for this work, we >>> have proposed that the SMI-to-XSD translation work be done in the >>> OPSAWG. >>> >> I have an objection to this "translation" work. >> You will make all kinds of assumptions about data organization >> and data naming, and I'm not sure what people are supposed >> to do with the XSDs. >> >> The term "XSD translation" is misleading. >> The XML on the wire is what is at stake here. >> The smidump translation of a MIB has SNMP operations >> built into it. Is this work supposed to produce >> a standard way to send an SNMP PDU over any protocol >> designed to encode SNMP PDUs in XML? Why do we need this? >> >> Is the charter going to state that the XSD translation will >> be suitable for use for any particular protocol? >> NETCONF needs to standardize XML data organization, >> namespace usage, and Xpath-based data naming. >> Is this translation going to be compatible with that standard >> when it eventually comes out? >> >> I would like the charter to be clear on the purpose of this work item, >> and what 'protocols' are signed up to use it. >> >> >>> The OPSAWG chairs need to determine whether the OPSAWG WG should >>> accept this work. Please send email to opsawg@ietf.org with comments >>> about your support/lack of support for having the OPSAWG do this work. >>> (If you do not subscribe to opsawg, you might want to do so, in order >>> to follow the discussions.) >>> >>> David Harrington >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >>> >>> >> >> Andy >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www1.ietf.org/mailman/listinfo/opsawg >> > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Aug 13 12:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKd06-0008WM-TL; Mon, 13 Aug 2007 12:42:42 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IKcTw-0000Ny-Sy for opsawg-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 12:09:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKcTu-0000N8-Id for opsawg@ietf.org; Mon, 13 Aug 2007 12:09:28 -0400 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKcTt-0002ax-VE for opsawg@ietf.org; Mon, 13 Aug 2007 12:09:26 -0400 Received: (qmail 37129 invoked from network); 13 Aug 2007 16:09:01 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2007 16:09:00 -0000 X-YMail-OSG: xUK49esVM1mY_mO7bi6Zy31EK0OGOOHC0KJqbqLKSKHGY2C9 Message-ID: <46C081C1.6000307@andybierman.com> Date: Mon, 13 Aug 2007 09:07:29 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [OPSAWG] Re: [NGO] XSDMI work References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> <46BC9E07.3030502@andybierman.com> <46C06B7B.6080709@juniper.net> In-Reply-To: <46C06B7B.6080709@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Mon, 13 Aug 2007 12:42:42 -0400 Cc: ngo@ietf.org, mib2rdml@ietf.org, opsawg@ietf.org, ops-nm@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi Ron, BTW, there is a simple algorithm for data organization that works even without namespaces. We know that descriptors are not required to be unique across modules, but module names are required to be globally unique. This simple Xpath expression works for any MIB object: /MODULE-NAME/TableName/TableEntry[index components]/tableColumn /IF-MIB/ifTable/ifEntry[ifIndex=17]/ifName /FOO-MIB/fooTable/fooEntry[x=1][y=2][name='fred']/fooColumn Andy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Aug 13 12:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKd06-0008WF-Pz; Mon, 13 Aug 2007 12:42:42 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IKcFf-00070H-Rh for opsawg-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 11:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKcFf-000700-Hj for opsawg@ietf.org; Mon, 13 Aug 2007 11:54:43 -0400 Received: from smtp118.sbc.mail.sp1.yahoo.com ([69.147.64.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IKcFe-0000nC-2O for opsawg@ietf.org; Mon, 13 Aug 2007 11:54:43 -0400 Received: (qmail 73280 invoked from network); 13 Aug 2007 15:54:41 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2007 15:54:41 -0000 X-YMail-OSG: 33OB0RMVM1k2J_X9YvyJwjayZywHJDWiBWyNIWNoW.8N4GwRP3M1sUke.cADMTOSCDB9fnPQ_qjo52D_N2wKonOr Message-ID: <46C07E65.8080503@andybierman.com> Date: Mon, 13 Aug 2007 08:53:09 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [OPSAWG] Re: [NGO] XSDMI work References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> <46BC9E07.3030502@andybierman.com> <46C06B7B.6080709@juniper.net> In-Reply-To: <46C06B7B.6080709@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 X-Mailman-Approved-At: Mon, 13 Aug 2007 12:42:42 -0400 Cc: ngo@ietf.org, mib2rdml@ietf.org, opsawg@ietf.org, ops-nm@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Ron Bonica wrote: > Andy, David, > > Permit me to ask a few dumb questions so that I can understand a) what > David is proposing and b) why Andy is objecting. > > AFAIKS, David is proposing the following: > > - a mapping from SMIv2 TCs to XSD types > - a mechanism to translate SNMP MIBS to XSD. > > The XSD is an XML schema that is independent of the protocol that is > used to shuffle the data back and forth. In one respect, it is a bit > like Esperanto. It strength is that it omits the details that make it > inappropriate for one protocol or the other. But at the same time, it's > weakness is that it lacks the detail that would be required by any protocol. > That's the pretty picture from 10000 feet > David, Andy, do I have this right? If so, could you guys point out what > some of those omitted/lacking details are? The XSD is going to contain clauses that specify how data naming works for the multiple conceptual instances of the 'table row' (i.e., some ancestor node of all index nodes). In order to be useful for a particular protocol, this naming scheme must be compatible with that protocol. The conceptual data structures are going to use data types that must be supported in that protocol, which impacts DM design. In order to be useful for any protocol, another document would be needed that maps every detail in the SMI-to-XSD algorithm to every detail of the operations (verbs) for that protocol. This is 90% of the work. This generic SMI-to-XSD mapping is the other 10%. IMO, this just complicates things. I would rather the 90% document be 100%, and map SMIv2 directly to the protocol, rather than mapping from SMIv2 to an XSD info model, and then to the protocol. The current proposal contains lots of SNMP-specific details, like engine-IDs, contexts, and max-repetitions. This suggests that the mapping is for SNMP, not SMIv2. IMO, seamless integration of MIB-based data into the NETCONF protocol is an interesting problem to solve. Using a NETCONF session to send SNMP PDUs in XML to the NETCONF agent, who will forward it to the SNMP agent, is not an interesting problem to solve. Andy > > /speaking as individual contributor > /and by no means a data modeling expert > Ron > > > Andy Bierman wrote: >> David Harrington wrote: >> >>> Hi, >>> >>> The XSDMI BOF proposed the creation of a WG to develop 1) the XSD >>> equivalents of datatypes and textual conventions from SMIv2, and 2) >>> algorithms to translate MIB module specifications into XSD >>> equivalents. The BOF demonstrated community support for these two work >>> items. >>> People in the BOF volunteered to commit to being editors (3) and >>> reviewers (14) for these work items. Starting documents and >>> implementations already exist. The work is expected to take less than >>> 12 months. >>> >>> At Dan's suggestion, rather than starting a new WG for this work, we >>> have proposed that the SMI-to-XSD translation work be done in the >>> OPSAWG. >>> >> I have an objection to this "translation" work. >> You will make all kinds of assumptions about data organization >> and data naming, and I'm not sure what people are supposed >> to do with the XSDs. >> >> The term "XSD translation" is misleading. >> The XML on the wire is what is at stake here. >> The smidump translation of a MIB has SNMP operations >> built into it. Is this work supposed to produce >> a standard way to send an SNMP PDU over any protocol >> designed to encode SNMP PDUs in XML? Why do we need this? >> >> Is the charter going to state that the XSD translation will >> be suitable for use for any particular protocol? >> NETCONF needs to standardize XML data organization, >> namespace usage, and Xpath-based data naming. >> Is this translation going to be compatible with that standard >> when it eventually comes out? >> >> I would like the charter to be clear on the purpose of this work item, >> and what 'protocols' are signed up to use it. >> >> >>> The OPSAWG chairs need to determine whether the OPSAWG WG should >>> accept this work. Please send email to opsawg@ietf.org with comments >>> about your support/lack of support for having the OPSAWG do this work. >>> (If you do not subscribe to opsawg, you might want to do so, in order >>> to follow the discussions.) >>> >>> David Harrington >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >>> >>> >> >> Andy >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www1.ietf.org/mailman/listinfo/opsawg >> > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Aug 13 12:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKd06-0008WM-TL; Mon, 13 Aug 2007 12:42:42 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IKcTw-0000Ny-Sy for opsawg-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 12:09:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKcTu-0000N8-Id for opsawg@ietf.org; Mon, 13 Aug 2007 12:09:28 -0400 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKcTt-0002ax-VE for opsawg@ietf.org; Mon, 13 Aug 2007 12:09:26 -0400 Received: (qmail 37129 invoked from network); 13 Aug 2007 16:09:01 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2007 16:09:00 -0000 X-YMail-OSG: xUK49esVM1mY_mO7bi6Zy31EK0OGOOHC0KJqbqLKSKHGY2C9 Message-ID: <46C081C1.6000307@andybierman.com> Date: Mon, 13 Aug 2007 09:07:29 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [OPSAWG] Re: [NGO] XSDMI work References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> <46BC9E07.3030502@andybierman.com> <46C06B7B.6080709@juniper.net> In-Reply-To: <46C06B7B.6080709@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Mon, 13 Aug 2007 12:42:42 -0400 Cc: ngo@ietf.org, mib2rdml@ietf.org, opsawg@ietf.org, ops-nm@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi Ron, BTW, there is a simple algorithm for data organization that works even without namespaces. We know that descriptors are not required to be unique across modules, but module names are required to be globally unique. This simple Xpath expression works for any MIB object: /MODULE-NAME/TableName/TableEntry[index components]/tableColumn /IF-MIB/ifTable/ifEntry[ifIndex=17]/ifName /FOO-MIB/fooTable/fooEntry[x=1][y=2][name='fred']/fooColumn Andy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Aug 13 13:25:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdfI-0004kF-OO; Mon, 13 Aug 2007 13:25:16 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IKdfH-0004kA-BJ for opsawg-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdfH-0004k1-1i for opsawg@ietf.org; Mon, 13 Aug 2007 13:25:15 -0400 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKdfF-0005tC-PR for opsawg@ietf.org; Mon, 13 Aug 2007 13:25:15 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc15) with SMTP id <20070813172512b1500a59kpe>; Mon, 13 Aug 2007 17:25:13 +0000 From: "David Harrington" To: References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> <46BC9E07.3030502@andybierman.com> Date: Mon, 13 Aug 2007 13:25:08 -0400 Message-ID: <000501c7ddce$e6351b30$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46BC9E07.3030502@andybierman.com> Thread-Index: AcfbcsHyxsLiDwcEROyjY8bR/3FMIwABxWdA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: 'Andy Bierman' Subject: [OPSAWG] RE: [NGO] XSDMI work X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi, (Andy raised some points on the NGO list. I am responding on the OPSAWG list, since the question is about accepting this work into the OPSAWG WG.) It is not just the XML on the wire that is at stake here. The proposed work is almost solely about translating from SMI data model to XSD models, independent of any protocols that might use it. The SMIDUMP utility translations are documented in draft-li-mib-convert-00. This was done to give us something concrete to discuss. The SMIDUMP utility does mix some protocol-dependent information into its XSD. We should try to make sure the SMI-to-XSD translations are as protocol-independent as we can make it. A few years ago, other SDOs decided they needed mappings from their layer 2 protocols to IP, and decided to ask the IETF to do that work. The IETF decided it would make more sense to define an IETF-standard interface to IP that was independent of any specific layer 2 protocol, and then the engineers who wanted specific layer 2 protocols to work with IP could determine how to map from their protocol to the protocol-independent interface. That is what I am proposing here - creating a protocol-independent interface to MIB data. Then other protocols can write to that interface if they choose. I am not trying to require that other protocols utilize the resulting XSD, however. If the designers of protocols have a better approach for accessing MIB data for their purpose, have at it! MIB modules are used in multiple ways. 1) they are used as specifications for implementations on agents, where the format of the data in a data model must be known so that, for example, a Counter64 is allocated a 64-bit variable for counting, and a SIZE 255 OCTET STRING can be allocated 255 bytes to storage, and an object of a TEXTUAL-CONVENTION like SnmpAdminString can be properly formatted using the rules associated with that TC, such as using UTF-8 encoding and no control codes. An SMI-to-XSD translation of datatypes is meant to make SMI-compatible datatypes available for protocols that use XSD to define datatypes. This will allow new data models to reuse existing datatypes (such as Counter64) and Textual Conventions in their designs, if they choose. This would be especially useful so a data point in an SMI-compatible data model could be compared to a data point in an XSD-compatible data model. Other protocols, such as XCAP, IDMEF, and ATOM use XML-based data models and define XML Schemas for validating the data models. Some of those schemas contain datatypes roughly similar to those defined in the SMI datatypes and textual conventions. For example, XCAP uses a display-name type; IDMEF specifies addresses in its XML. The SnmpAdmninsTring type and the InetAddressType/Address/Port textual conventions define rules about how to format addresses, and identify address types. The SnmpAdminString and InetAddress* restrictions could also be useful in an XML Schema to validate the data for an XML-based data model. These examples only show that complex types constructs used in the MIB (textual conventions and application-specific datatypes) could also be useful in other data models, if converted to XSD. By making the datatypes from SMI available to other data models in XSD, the values used could be more consistent across data models. 2) the datatypes are used to identify the format of information being passed on-the-wire using a protocol, such as SNMP. In a TLV entity like an SNMP varbind, the datatype is used to identify the type of the value. In XML, the datatype is not passed on the wire in the XML element. Rather an external schema document, in XML Schema, or a DTD, or RelaxNG is used to validate the XML. The IETF has spent twenty years developing the MIB, and there is a lot of information about networking protocols embedded in its information model, and modular data models, based on the skills and experience of protocol developers, administrators, and equipment vendors. If an XML-based protocol like Netconf chooses to leverage that information by accessing a managed object in the MIB, the receiving application (the Netconf client or the manager application using Netconf to gather data) should know the schema of the datatype of the values being accessed so the data can be validated. If the Netconf client or the manager, however, do not already support SNMP and the SMI, it would be more convenient for the Netconf client (the manager) to be able to perform validation of the data using XSD that is compatible with the corresponding SMI definition. An SMI-to-XSD translation of datatypes is meant to make SMI-compatible validation available for protocols that carry SMI-style MIB objects in an XML format. 3) MIB module specifications are "imported" by SNMP managers to develop corresponding database records reflecting the structures of the tables, the allowed value ranges, and so on; The MIB module specifies restrictions, such as ranges. that allows the manager application to validate information received over the wire, such as in an SNMP varbind. Many databases now have XML interfaces, and can import XSD directly to generate internal database record formats, and then the database can validate XML data going into those records. For a developer that wants a new manager application to be able to validate MIB information retrieved using an XML-based protocol, who uses a database with an XML interface, and who doesn't want to have to support an SMI-specific import facility, being able to import the XSD equivalent of a MIB module specification would be useful. A MIB-to-XSD translation would be helpful. One goal is to provide a standard for translating MIB specification elements other than datatypes and textual conventions for this "import" purpose, a purpose which is possible using the SMI. 4) MIB modules identify how to "address" a specific managed object, so a manager can ask an agent for a specific object. The OID format used for this is widely hated, but if a protocol needs to identify an object in the MIB to access, there needs to be a way to translate the OID addressing into an XML-compatible equivalent. One way to aproach this is define a whole new data model using a non-SMI data modeling language, such as XSD or the new data modeling languages being worked on in netconf (NCX and YANG), and these new languages would need to define how to address the undwelriny instruentation directly without going through the SMI-style interface. There is always the possibility that doing this will result in slightly different semantics or modeling, which would be undesirable. It would also be indesirable to ignore all the existing MIB data models and define all new data models to access the same information already being made available on device implementations. Translating the OID addressing to an XML equivalent addressing should be a relatively straight-forward algorithmic translation of the hierarchical OID registration values to a corresponding XML hierarchical naming scheme using the SMI object descriptor names. That would be one way to do it; other ways to address the same information might be possible depending on the protocol. The XSDMI effort would probably need to define one algorithmic approach, but that does not mean protocls could not use a different approach if that was justified. 5) MIB modules are frequerntly used to provide information to NMS users as help screens. The SMI if displayed, so NMS users can read what the purpose and restrictions are for the data. Part of the purpose of moving toward XML and the XML family of protocols is that CS students are being trained in these protocols, but not in SMI. Assuming administrators will begin to have a better understanding of XSD, NMS developers might display thew XSD related to a data model definition. So if Netconf defines a data model in XSD, unrelated to the MIB, but also accesses data from the MIB, it would be unfortunate if the help screen for one managed object was in XSD, with th eother was in SMI; it would seem better to make it possible for NMS developers to be able to display the XSD equivalent of the SMI, if desired. The XSDMI work should define one translation from SMI to XSD. Other efforts, such as Netconf's YANG or NCX proposals may have their own protocol-specific translations as well. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Friday, August 10, 2007 1:19 PM > To: David Harrington > Cc: ngo@ietf.org; opsawg@ietf.org; mib2rdml@ietf.org; ops-nm@ietf.org > Subject: Re: [NGO] XSDMI work > > David Harrington wrote: > > Hi, > > > > The XSDMI BOF proposed the creation of a WG to develop 1) the XSD > > equivalents of datatypes and textual conventions from SMIv2, and 2) > > algorithms to translate MIB module specifications into XSD > > equivalents. The BOF demonstrated community support for > these two work > > items. > > > > People in the BOF volunteered to commit to being editors (3) and > > reviewers (14) for these work items. Starting documents and > > implementations already exist. The work is expected to take > less than > > 12 months. > > > > At Dan's suggestion, rather than starting a new WG for this work, we > > have proposed that the SMI-to-XSD translation work be done in the > > OPSAWG. > > > > I have an objection to this "translation" work. > You will make all kinds of assumptions about data organization > and data naming, and I'm not sure what people are supposed > to do with the XSDs. > > The term "XSD translation" is misleading. > The XML on the wire is what is at stake here. > The smidump translation of a MIB has SNMP operations > built into it. Is this work supposed to produce > a standard way to send an SNMP PDU over any protocol > designed to encode SNMP PDUs in XML? Why do we need this? > > Is the charter going to state that the XSD translation will > be suitable for use for any particular protocol? > NETCONF needs to standardize XML data organization, > namespace usage, and Xpath-based data naming. > Is this translation going to be compatible with that standard > when it eventually comes out? > > I would like the charter to be clear on the purpose of this work item, > and what 'protocols' are signed up to use it. > > > > The OPSAWG chairs need to determine whether the OPSAWG WG should > > accept this work. Please send email to opsawg@ietf.org with comments > > about your support/lack of support for having the OPSAWG do > this work. > > (If you do not subscribe to opsawg, you might want to do > so, in order > > to follow the discussions.) > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > > Andy > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Aug 13 15:21:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKfTW-0005YU-R9; Mon, 13 Aug 2007 15:21:14 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IKfTV-0005YD-L4 for opsawg-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 15:21:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKfTV-0005Y5-98 for opsawg@ietf.org; Mon, 13 Aug 2007 15:21:13 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKfTT-0002Xx-EQ for opsawg@ietf.org; Mon, 13 Aug 2007 15:21:13 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070813192110b1200doj8se>; Mon, 13 Aug 2007 19:21:10 +0000 From: "David Harrington" To: "'Andy Bierman'" References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> <46BC9E07.3030502@andybierman.com> <000501c7ddce$e6351b30$6702a8c0@china.huawei.com> <46C0A224.5080507@andybierman.com> Date: Mon, 13 Aug 2007 15:21:08 -0400 Message-ID: <004701c7dddf$1ae6fe60$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46C0A224.5080507@andybierman.com> Thread-Index: Acfd1+7zuLoSq+WFTziEuJ2JuS+GIAAAY1wg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 Cc: opsawg@ietf.org Subject: [OPSAWG] RE: [NGO] XSDMI work X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi, I will respond inline > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Monday, August 13, 2007 2:26 PM > To: David Harrington > Cc: opsawg@ietf.org; 'Ron Bonica' > Subject: Re: [NGO] XSDMI work > > David Harrington wrote: > > Hi, > > > > I don't really want to respond inline, so > I'll just point out some NETCONF details: > > - NETCONF configuration is an extension of proprietary CLI, > not SNMP. The SNMP protocol, architecture, transport, security > and access control model are not factors in the network > configuration problem. But there is some MIB-based > monitoring data > that has become part of the operational framework of many > networks. Agreed, and the translationof SMI datatypes to XSD datatypes, and the translation of MIB documents into XSD Schemas has nothing to do with the SNMP architecture, SNMP transports, SNMP security, or SNMP access control. A MIB module defines an SMI-based interface to the underlying instrumentation, and an XML-based data model can used XML Schema to do the same. For the same instrumentation, it would be a good thing if the XSD was the equivalent of the SMI interface, if the underlying data is the same. Over twenty years, we have standardized a wide range of knobs and vernodrs have provided hooks in their implementations to provide the information for those knobs. Vendorsd would like to be able to reuse those some of those same hooks rather than starting the twenty year's worth of data modeling all over again. > > - NETCONF data modeling has been a real challenge > because there is no pre-existing agreement on the CLI, > so standard config, whether encoded in XML or Morse code, > requires a lot of agreement on the standard knobs first. Agreed. and hopefully the Netconf community will be able to drive consensus on those standard knobs for configuration, which the IETF has been totally unable to do so far. On the other hand, over the course of twenty years we have reached consensus on a wide variety of knobs useful for performance and fault monitoring and useful for notifications, and it would be a share to ignore all that work we have alreadty reached consensus on just because no consensus was reached on configuration knobs. It is often quite adequate to monitor a certain subset of the instrumentation, but to do configuration requires knowing all the relevant knobs. I am in the camp that believes non-standard configuration knobs will never go away because that is how vendors differentiate their products, and only reaching conensus on a **subset** of configuration knobs will probably not be sufficient, as was shown in the case of MIB data modeling; that's one major reason why SNMP is not good for doing configuration. I cannot configure a VLAN using the identical configuration commands on a Cisco device and an Enterasys device, because they require slightly different parameters, but I can certainly monitor how many VLANs have been created and which IDs they have been assigned, and what protocols they support, even if I cannot configure them using a standard data model. > > - There is a big difference between reusing SNMP, reusing SMIv2, > reusing conceptual MIB data, and reusing agent SNMP > instrumentation. > Depending on your goal, you will see the solution space > differently. And the goal is to define how to reuse the MIB data, by defining a standardized interface to that MIB data that would be useful for XML-based protocols. > > - There is a use case for NETCONF reading MIB data > occasionally within the > the context of provisioning new services, verifying configuration > changes, etc. And if Netconf wants to use the XSDMI translations, that might be beneficial to Netconf. or not. > > - There is some usefulness in a standard way to convert a > DESCRIPTION clause to a element, etc., > just as the romascanu-datatypes RFC will specify how to > convert an OCTET STRING data type to an xs:string, or > BITS to xs:list, etc. That's what we're shooting for ... > > - It is not clear how much SNMP this new WG is trying to add to > other protocols, or how much SMIv2 it is trying to > turn into something protocol-neutral, or how a real protocol > utilizes the output XSDs. I am just asking for clarification > on these issues in the charter, that's all. Personally, I am shooting for no SNMP-centric stuff; I am also shooting for no Netconf-specific stuuf; I am shooting for protocol-independent. Most MIB data models (except of course the ones for managing SNMP) are independent of SNMP, and as a MIB Doctor I have worked to keep them that way. MIB data models are defined using SMI, and XML-based applications and protocols could benefit from using the existing data models for purposes of monitoring and notifications and other things. We need to understand how to translate the SMI to XSD in order to fully understand a MIB data model and make it easier to work with in an XML-based environment. For those XML-based applications that want to validate the XML data they get, it would be useful to have the XSD equivalent of MIB data model datatypes and textual conventions and table specifications and notification specifications and so on. That said, a MIB data model is just an interface to the underlying instrumentation, and there may be ways to ignore the MIB interface to access the same underlying data directly. Operators and application designers should choose the best combination of protocols and data models to meet their needs. SCSI is a standardized interface to an underlying storage device. While some applications benefit from direct access, most find it easier to use a standardized interface; others may prefer to use different standard interfaces for storage device access. The XSDMI effort is about providing **a** standard interface that can be used by those who would prefer not having to design their own low-layer access routines to utilize MIB data. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > > > Andy > > > > (Andy raised some points on the NGO list. I am responding on the > > OPSAWG list, since the question is about accepting this > work into the > > OPSAWG WG.) > > > > It is not just the XML on the wire that is at stake here. > The proposed > > work is almost solely about translating from SMI data model to XSD > > models, independent of any protocols that might use it. > > > > The SMIDUMP utility translations are documented in > > draft-li-mib-convert-00. This was done to give us something concrete > > to discuss. The SMIDUMP utility does mix some protocol-dependent > > information into its XSD. We should try to make sure the SMI-to-XSD > > translations are as protocol-independent as we can make it. > > > > A few years ago, other SDOs decided they needed mappings from their > > layer 2 protocols to IP, and decided to ask the IETF to do > that work. > > The IETF decided it would make more sense to define an IETF-standard > > interface to IP that was independent of any specific layer > 2 protocol, > > and then the engineers who wanted specific layer 2 protocols to work > > with IP could determine how to map from their protocol to the > > protocol-independent interface. That is what I am proposing here - > > creating a protocol-independent interface to MIB data. Then other > > protocols can write to that interface if they choose. I am > not trying > > to require that other protocols utilize the resulting XSD, > however. If > > the designers of protocols have a better approach for accessing MIB > > data for their purpose, have at it! > > > > MIB modules are used in multiple ways. > > > > 1) they are used as specifications for implementations on agents, > > where the format of the data in a data model must be known so that, > > for example, a Counter64 is allocated a 64-bit variable for > counting, > > and a SIZE 255 OCTET STRING can be allocated 255 bytes to > storage, and > > an object of a TEXTUAL-CONVENTION like SnmpAdminString can > be properly > > formatted using the rules associated with that TC, such as > using UTF-8 > > encoding and no control codes. > > An SMI-to-XSD translation of datatypes is meant to make > > SMI-compatible datatypes available for protocols that use XSD to > > define datatypes. This will allow new data models to reuse existing > > datatypes (such as Counter64) and Textual Conventions in their > > designs, if they choose. This would be especially useful so a data > > point in an SMI-compatible data model could be compared to a data > > point in an XSD-compatible data model. > > Other protocols, such as XCAP, IDMEF, and ATOM use XML-based > > data models and define XML Schemas for validating the data models. > > Some of those schemas contain datatypes roughly similar to those > > defined in the SMI datatypes and textual conventions. For example, > > XCAP uses a display-name type; IDMEF specifies addresses in its XML. > > The SnmpAdmninsTring type and the > InetAddressType/Address/Port textual > > conventions define rules about how to format addresses, and identify > > address types. The SnmpAdminString and InetAddress* > restrictions could > > also be useful in an XML Schema to validate the data for an > XML-based > > data model. > > These examples only show that complex types constructs used > > in the MIB (textual conventions and application-specific datatypes) > > could also be useful in other data models, if converted to XSD. By > > making the datatypes from SMI available to other data models in XSD, > > the values used could be more consistent across data models. > > > > 2) the datatypes are used to identify the format of > information being > > passed on-the-wire using a protocol, such as SNMP. In a TLV entity > > like an SNMP varbind, the datatype is used to identify the > type of the > > value. > > In XML, the datatype is not passed on the wire in the XML > > element. Rather an external schema document, in XML Schema, > or a DTD, > > or RelaxNG is used to validate the XML. > > The IETF has spent twenty years developing the MIB, and there > > is a lot of information about networking protocols embedded in its > > information model, and modular data models, based on the skills and > > experience of protocol developers, administrators, and equipment > > vendors. > > If an XML-based protocol like Netconf chooses to leverage that > > information by accessing a managed object in the MIB, the receiving > > application (the Netconf client or the manager application using > > Netconf to gather data) should know the schema of the > datatype of the > > values being accessed so the data can be validated. > > If the Netconf client or the manager, however, do not already > > support SNMP and the SMI, it would be more convenient for > the Netconf > > client (the manager) to be able to perform validation of the data > > using XSD that is compatible with the corresponding SMI definition. > > An SMI-to-XSD translation of datatypes is meant to make > > SMI-compatible validation available for protocols that > carry SMI-style > > MIB objects in an XML format. > > > > 3) MIB module specifications are "imported" by SNMP managers to > > develop corresponding database records reflecting the structures of > > the tables, the allowed value ranges, and so on; The MIB module > > specifies restrictions, such as ranges. that allows the manager > > application to validate information received over the wire, > such as in > > an SNMP varbind. > > Many databases now have XML interfaces, and can import XSD > > directly to generate internal database record formats, and then the > > database can validate XML data going into those records. > > For a developer that wants a new manager application to be > > able to validate MIB information retrieved using an XML-based > > protocol, who uses a database with an XML interface, and who doesn't > > want to have to support an SMI-specific import facility, > being able to > > import the XSD equivalent of a MIB module specification would be > > useful. > > A MIB-to-XSD translation would be helpful. One goal is to > > provide a standard for translating MIB specification elements other > > than datatypes and textual conventions for this "import" purpose, a > > purpose which is possible using the SMI. > > > > 4) MIB modules identify how to "address" a specific managed > object, so > > a manager can ask an agent for a specific object. The OID > format used > > for this is widely hated, but if a protocol needs to identify an > > object in the MIB to access, there needs to be a way to > translate the > > OID addressing into an XML-compatible equivalent. > > One way to aproach this is define a whole new data model using > > a non-SMI data modeling language, such as XSD or the new > data modeling > > languages being worked on in netconf (NCX and YANG), and these new > > languages would need to define how to address the undwelriny > > instruentation directly without going through the SMI-style > interface. > > There is always the possibility that doing this will result in > > slightly different semantics or modeling, which would be > undesirable. > > It would also be indesirable to ignore all the existing MIB data > > models and define all new data models to access the same information > > already being made available on device implementations. > > Translating the OID addressing to an XML equivalent addressing > > should be a relatively straight-forward algorithmic > translation of the > > hierarchical OID registration values to a corresponding XML > > hierarchical naming scheme using the SMI object descriptor > names. That > > would be one way to do it; other ways to address the same > information > > might be possible depending on the protocol. The XSDMI effort would > > probably need to define one algorithmic approach, but that does not > > mean protocls could not use a different approach if that was > > justified. > > > > 5) MIB modules are frequerntly used to provide information to NMS > > users as help screens. The SMI if displayed, so NMS users can read > > what the purpose and restrictions are for the data. Part of the > > purpose of moving toward XML and the XML family of protocols is that > > CS students are being trained in these protocols, but not in SMI. > > Assuming administrators will begin to have a better understanding of > > XSD, NMS developers might display thew XSD related to a data model > > definition. So if Netconf defines a data model in XSD, unrelated to > > the MIB, but also accesses data from the MIB, it would be > unfortunate > > if the help screen for one managed object was in XSD, with th eother > > was in SMI; it would seem better to make it possible for NMS > > developers to be able to display the XSD equivalent of the SMI, if > > desired. > > The XSDMI work should define one translation from SMI to XSD. > > Other efforts, such as Netconf's YANG or NCX proposals may > have their > > own protocol-specific translations as well. > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > >> -----Original Message----- > >> From: Andy Bierman [mailto:ietf@andybierman.com] > >> Sent: Friday, August 10, 2007 1:19 PM > >> To: David Harrington > >> Cc: ngo@ietf.org; opsawg@ietf.org; mib2rdml@ietf.org; > > ops-nm@ietf.org > >> Subject: Re: [NGO] XSDMI work > >> > >> David Harrington wrote: > >>> Hi, > >>> > >>> The XSDMI BOF proposed the creation of a WG to develop 1) the XSD > >>> equivalents of datatypes and textual conventions from SMIv2, and > > 2) > >>> algorithms to translate MIB module specifications into XSD > >>> equivalents. The BOF demonstrated community support for > >> these two work > >>> items. > >>> > >>> People in the BOF volunteered to commit to being editors (3) and > >>> reviewers (14) for these work items. Starting documents and > >>> implementations already exist. The work is expected to take > >> less than > >>> 12 months. > >>> > >>> At Dan's suggestion, rather than starting a new WG for this work, > > we > >>> have proposed that the SMI-to-XSD translation work be done in the > >>> OPSAWG. > >>> > >> I have an objection to this "translation" work. > >> You will make all kinds of assumptions about data organization > >> and data naming, and I'm not sure what people are supposed > >> to do with the XSDs. > >> > >> The term "XSD translation" is misleading. > >> The XML on the wire is what is at stake here. > >> The smidump translation of a MIB has SNMP operations > >> built into it. Is this work supposed to produce > >> a standard way to send an SNMP PDU over any protocol > >> designed to encode SNMP PDUs in XML? Why do we need this? > >> > >> Is the charter going to state that the XSD translation will > >> be suitable for use for any particular protocol? > >> NETCONF needs to standardize XML data organization, > >> namespace usage, and Xpath-based data naming. > >> Is this translation going to be compatible with that standard > >> when it eventually comes out? > >> > >> I would like the charter to be clear on the purpose of this work > > item, > >> and what 'protocols' are signed up to use it. > >> > >> > >>> The OPSAWG chairs need to determine whether the OPSAWG WG should > >>> accept this work. Please send email to opsawg@ietf.org with > > comments > >>> about your support/lack of support for having the OPSAWG do > >> this work. > >>> (If you do not subscribe to opsawg, you might want to do > >> so, in order > >>> to follow the discussions.) > >>> > >>> David Harrington > >>> dbharrington@comcast.net > >>> ietfdbh@comcast.net > >>> > >>> > >> > >> Andy > >> > > > > > > > > > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Aug 14 01:18:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKonu-0001JA-T6; Tue, 14 Aug 2007 01:18:54 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IKefr-0006wV-CP for opsawg-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 14:29:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKefq-0006vv-VV for opsawg@ietf.org; Mon, 13 Aug 2007 14:29:55 -0400 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKefp-0000Ck-BP for opsawg@ietf.org; Mon, 13 Aug 2007 14:29:54 -0400 Received: (qmail 49178 invoked from network); 13 Aug 2007 18:27:12 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2007 18:27:11 -0000 X-YMail-OSG: C9KVIDcVM1kn0m0QMiXSx7kQLQ_PdF6rHXBOVHwvI3fGjJ3z Message-ID: <46C0A224.5080507@andybierman.com> Date: Mon, 13 Aug 2007 11:25:40 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David Harrington References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> <46BC9E07.3030502@andybierman.com> <000501c7ddce$e6351b30$6702a8c0@china.huawei.com> In-Reply-To: <000501c7ddce$e6351b30$6702a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 X-Mailman-Approved-At: Tue, 14 Aug 2007 01:18:50 -0400 Cc: opsawg@ietf.org Subject: [OPSAWG] Re: [NGO] XSDMI work X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org David Harrington wrote: > Hi, > I don't really want to respond inline, so I'll just point out some NETCONF details: - NETCONF configuration is an extension of proprietary CLI, not SNMP. The SNMP protocol, architecture, transport, security and access control model are not factors in the network configuration problem. But there is some MIB-based monitoring data that has become part of the operational framework of many networks. - NETCONF data modeling has been a real challenge because there is no pre-existing agreement on the CLI, so standard config, whether encoded in XML or Morse code, requires a lot of agreement on the standard knobs first. - There is a big difference between reusing SNMP, reusing SMIv2, reusing conceptual MIB data, and reusing agent SNMP instrumentation. Depending on your goal, you will see the solution space differently. - There is a use case for NETCONF reading MIB data occasionally within the the context of provisioning new services, verifying configuration changes, etc. - There is some usefulness in a standard way to convert a DESCRIPTION clause to a element, etc., just as the romascanu-datatypes RFC will specify how to convert an OCTET STRING data type to an xs:string, or BITS to xs:list, etc. - It is not clear how much SNMP this new WG is trying to add to other protocols, or how much SMIv2 it is trying to turn into something protocol-neutral, or how a real protocol utilizes the output XSDs. I am just asking for clarification on these issues in the charter, that's all. Andy > (Andy raised some points on the NGO list. I am responding on the > OPSAWG list, since the question is about accepting this work into the > OPSAWG WG.) > > It is not just the XML on the wire that is at stake here. The proposed > work is almost solely about translating from SMI data model to XSD > models, independent of any protocols that might use it. > > The SMIDUMP utility translations are documented in > draft-li-mib-convert-00. This was done to give us something concrete > to discuss. The SMIDUMP utility does mix some protocol-dependent > information into its XSD. We should try to make sure the SMI-to-XSD > translations are as protocol-independent as we can make it. > > A few years ago, other SDOs decided they needed mappings from their > layer 2 protocols to IP, and decided to ask the IETF to do that work. > The IETF decided it would make more sense to define an IETF-standard > interface to IP that was independent of any specific layer 2 protocol, > and then the engineers who wanted specific layer 2 protocols to work > with IP could determine how to map from their protocol to the > protocol-independent interface. That is what I am proposing here - > creating a protocol-independent interface to MIB data. Then other > protocols can write to that interface if they choose. I am not trying > to require that other protocols utilize the resulting XSD, however. If > the designers of protocols have a better approach for accessing MIB > data for their purpose, have at it! > > MIB modules are used in multiple ways. > > 1) they are used as specifications for implementations on agents, > where the format of the data in a data model must be known so that, > for example, a Counter64 is allocated a 64-bit variable for counting, > and a SIZE 255 OCTET STRING can be allocated 255 bytes to storage, and > an object of a TEXTUAL-CONVENTION like SnmpAdminString can be properly > formatted using the rules associated with that TC, such as using UTF-8 > encoding and no control codes. > An SMI-to-XSD translation of datatypes is meant to make > SMI-compatible datatypes available for protocols that use XSD to > define datatypes. This will allow new data models to reuse existing > datatypes (such as Counter64) and Textual Conventions in their > designs, if they choose. This would be especially useful so a data > point in an SMI-compatible data model could be compared to a data > point in an XSD-compatible data model. > Other protocols, such as XCAP, IDMEF, and ATOM use XML-based > data models and define XML Schemas for validating the data models. > Some of those schemas contain datatypes roughly similar to those > defined in the SMI datatypes and textual conventions. For example, > XCAP uses a display-name type; IDMEF specifies addresses in its XML. > The SnmpAdmninsTring type and the InetAddressType/Address/Port textual > conventions define rules about how to format addresses, and identify > address types. The SnmpAdminString and InetAddress* restrictions could > also be useful in an XML Schema to validate the data for an XML-based > data model. > These examples only show that complex types constructs used > in the MIB (textual conventions and application-specific datatypes) > could also be useful in other data models, if converted to XSD. By > making the datatypes from SMI available to other data models in XSD, > the values used could be more consistent across data models. > > 2) the datatypes are used to identify the format of information being > passed on-the-wire using a protocol, such as SNMP. In a TLV entity > like an SNMP varbind, the datatype is used to identify the type of the > value. > In XML, the datatype is not passed on the wire in the XML > element. Rather an external schema document, in XML Schema, or a DTD, > or RelaxNG is used to validate the XML. > The IETF has spent twenty years developing the MIB, and there > is a lot of information about networking protocols embedded in its > information model, and modular data models, based on the skills and > experience of protocol developers, administrators, and equipment > vendors. > If an XML-based protocol like Netconf chooses to leverage that > information by accessing a managed object in the MIB, the receiving > application (the Netconf client or the manager application using > Netconf to gather data) should know the schema of the datatype of the > values being accessed so the data can be validated. > If the Netconf client or the manager, however, do not already > support SNMP and the SMI, it would be more convenient for the Netconf > client (the manager) to be able to perform validation of the data > using XSD that is compatible with the corresponding SMI definition. > An SMI-to-XSD translation of datatypes is meant to make > SMI-compatible validation available for protocols that carry SMI-style > MIB objects in an XML format. > > 3) MIB module specifications are "imported" by SNMP managers to > develop corresponding database records reflecting the structures of > the tables, the allowed value ranges, and so on; The MIB module > specifies restrictions, such as ranges. that allows the manager > application to validate information received over the wire, such as in > an SNMP varbind. > Many databases now have XML interfaces, and can import XSD > directly to generate internal database record formats, and then the > database can validate XML data going into those records. > For a developer that wants a new manager application to be > able to validate MIB information retrieved using an XML-based > protocol, who uses a database with an XML interface, and who doesn't > want to have to support an SMI-specific import facility, being able to > import the XSD equivalent of a MIB module specification would be > useful. > A MIB-to-XSD translation would be helpful. One goal is to > provide a standard for translating MIB specification elements other > than datatypes and textual conventions for this "import" purpose, a > purpose which is possible using the SMI. > > 4) MIB modules identify how to "address" a specific managed object, so > a manager can ask an agent for a specific object. The OID format used > for this is widely hated, but if a protocol needs to identify an > object in the MIB to access, there needs to be a way to translate the > OID addressing into an XML-compatible equivalent. > One way to aproach this is define a whole new data model using > a non-SMI data modeling language, such as XSD or the new data modeling > languages being worked on in netconf (NCX and YANG), and these new > languages would need to define how to address the undwelriny > instruentation directly without going through the SMI-style interface. > There is always the possibility that doing this will result in > slightly different semantics or modeling, which would be undesirable. > It would also be indesirable to ignore all the existing MIB data > models and define all new data models to access the same information > already being made available on device implementations. > Translating the OID addressing to an XML equivalent addressing > should be a relatively straight-forward algorithmic translation of the > hierarchical OID registration values to a corresponding XML > hierarchical naming scheme using the SMI object descriptor names. That > would be one way to do it; other ways to address the same information > might be possible depending on the protocol. The XSDMI effort would > probably need to define one algorithmic approach, but that does not > mean protocls could not use a different approach if that was > justified. > > 5) MIB modules are frequerntly used to provide information to NMS > users as help screens. The SMI if displayed, so NMS users can read > what the purpose and restrictions are for the data. Part of the > purpose of moving toward XML and the XML family of protocols is that > CS students are being trained in these protocols, but not in SMI. > Assuming administrators will begin to have a better understanding of > XSD, NMS developers might display thew XSD related to a data model > definition. So if Netconf defines a data model in XSD, unrelated to > the MIB, but also accesses data from the MIB, it would be unfortunate > if the help screen for one managed object was in XSD, with th eother > was in SMI; it would seem better to make it possible for NMS > developers to be able to display the XSD equivalent of the SMI, if > desired. > The XSDMI work should define one translation from SMI to XSD. > Other efforts, such as Netconf's YANG or NCX proposals may have their > own protocol-specific translations as well. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] >> Sent: Friday, August 10, 2007 1:19 PM >> To: David Harrington >> Cc: ngo@ietf.org; opsawg@ietf.org; mib2rdml@ietf.org; > ops-nm@ietf.org >> Subject: Re: [NGO] XSDMI work >> >> David Harrington wrote: >>> Hi, >>> >>> The XSDMI BOF proposed the creation of a WG to develop 1) the XSD >>> equivalents of datatypes and textual conventions from SMIv2, and > 2) >>> algorithms to translate MIB module specifications into XSD >>> equivalents. The BOF demonstrated community support for >> these two work >>> items. >>> >>> People in the BOF volunteered to commit to being editors (3) and >>> reviewers (14) for these work items. Starting documents and >>> implementations already exist. The work is expected to take >> less than >>> 12 months. >>> >>> At Dan's suggestion, rather than starting a new WG for this work, > we >>> have proposed that the SMI-to-XSD translation work be done in the >>> OPSAWG. >>> >> I have an objection to this "translation" work. >> You will make all kinds of assumptions about data organization >> and data naming, and I'm not sure what people are supposed >> to do with the XSDs. >> >> The term "XSD translation" is misleading. >> The XML on the wire is what is at stake here. >> The smidump translation of a MIB has SNMP operations >> built into it. Is this work supposed to produce >> a standard way to send an SNMP PDU over any protocol >> designed to encode SNMP PDUs in XML? Why do we need this? >> >> Is the charter going to state that the XSD translation will >> be suitable for use for any particular protocol? >> NETCONF needs to standardize XML data organization, >> namespace usage, and Xpath-based data naming. >> Is this translation going to be compatible with that standard >> when it eventually comes out? >> >> I would like the charter to be clear on the purpose of this work > item, >> and what 'protocols' are signed up to use it. >> >> >>> The OPSAWG chairs need to determine whether the OPSAWG WG should >>> accept this work. Please send email to opsawg@ietf.org with > comments >>> about your support/lack of support for having the OPSAWG do >> this work. >>> (If you do not subscribe to opsawg, you might want to do >> so, in order >>> to follow the discussions.) >>> >>> David Harrington >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >>> >>> >> >> Andy >> > > > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Aug 19 03:31:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMfGH-0007l5-IU; Sun, 19 Aug 2007 03:31:49 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IMfGG-0007kV-3V for opsawg-confirm+ok@megatron.ietf.org; Sun, 19 Aug 2007 03:31:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMfGC-0007ah-1c for opsawg@ietf.org; Sun, 19 Aug 2007 03:31:44 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMfGA-00057c-Vx for opsawg@ietf.org; Sun, 19 Aug 2007 03:31:43 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 819FE57CEC; Sun, 19 Aug 2007 09:31:41 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02004-02; Sun, 19 Aug 2007 09:31:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BDBF56064; Sun, 19 Aug 2007 09:31:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 855FF302560; Sun, 19 Aug 2007 09:31:35 +0200 (CEST) Date: Sun, 19 Aug 2007 09:31:35 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [OPSAWG] XSDMI work Message-ID: <20070819073135.GB3849@elstar.local> Mail-Followup-To: David Harrington , opsawg@ietf.org References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019701c7db6f$674c3990$6702a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: opsawg@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org On Fri, Aug 10, 2007 at 12:56:32PM -0400, David Harrington wrote: > The OPSAWG chairs need to determine whether the OPSAWG WG should > accept this work. Please send email to opsawg@ietf.org with comments > about your support/lack of support for having the OPSAWG do this work. I do not support this work much as I do not support the work to define XSD standard data types at this point in time, regardless of where this is hosted in the IETF. I believe both work items conflicts with NETCONF data modeling work and in particular with naming issues (how to identifiy XML elements that serve as keys) and data organizational issues (although XML namespaces somewhat help here to deal with potentially different approaches). To be clear: I do support work in this space as it is of high practical relevance; I do not want to be seen as negative. I just feel that some more core NETCONF SMI issues have to be sorted out before we are ready to work on _standards_ for doing translations or _standard_ reusable data types. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Aug 20 08:37:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN6VO-00079Z-7P; Mon, 20 Aug 2007 08:37:14 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IN6VM-00079U-HD for opsawg-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 08:37:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN6VI-00079H-PE for opsawg@ietf.org; Mon, 20 Aug 2007 08:37:08 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN6VI-0005tn-BK for opsawg@ietf.org; Mon, 20 Aug 2007 08:37:08 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7KCb5X18283 for ; Mon, 20 Aug 2007 12:37:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Aug 2007 08:37:06 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41066751D@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Syslog Alarm Draft thread-index: AcfjJtEq7TeB/I13RUmd9KkO6MzpGQ== From: "Sharon Chisholm" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [OPSAWG] Updated Syslog Alarm Draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi We have updated the Syslog Alarm work with the changes I discussed in the Chicago meeting.=20 =09 http://www.ietf.org/internet-drafts/draft-gerhards-chisholm-syslog-alarm -01.txt I'm requesting that this work be added to this working group as a standards track document. Thanks, Sharon Chisholm Nortel=20 Ottawa, Ontario Canada _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Wed Aug 29 11:48:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPmI-0005fi-0r; Wed, 29 Aug 2007 11:48:22 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IQPmF-0005fX-GI for opsawg-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 11:48:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPmF-0005fL-6C for opsawg@ietf.org; Wed, 29 Aug 2007 11:48:19 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQPmE-0006DJ-ST for opsawg@ietf.org; Wed, 29 Aug 2007 11:48:19 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 29 Aug 2007 08:48:17 -0700 Received: from [172.23.1.9] ([172.23.1.9] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 11:48:17 -0400 Message-ID: <46D5953B.9040607@juniper.net> Date: Wed, 29 Aug 2007 11:48:11 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: opsawg@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 15:48:17.0589 (UTC) FILETIME=[046F1650:01C7EA54] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [OPSAWG] XSDMI BoF X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Folks, Dan and I have received light but mixed reaction to the XSDMI BoF. A few participants have supported XSDMI becoming a working group while a smaller number have objected. The people objecting have stated that XSDMI might interfere with other work aimed at creating an SMI designed specifically for NETCONF. So, Dan and I are deferring our decision wrt to XSDMI for at least one IETF. We would like to give the folks proposing an NETCONF specific SMI some time to arrange a BoF session. After having seen that BoF, the community will decide whether one, the other or both groups should become working groups. Ron _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Wed Aug 29 14:39:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSRT-0003es-Uc; Wed, 29 Aug 2007 14:39:03 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IQSRT-0003dP-CE for opsawg-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 14:39:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSRR-0003ba-4R for opsawg@ietf.org; Wed, 29 Aug 2007 14:39:02 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQSRQ-0003pS-AM for opsawg@ietf.org; Wed, 29 Aug 2007 14:39:00 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc12) with SMTP id <20070829183858m1200dgfqqe>; Wed, 29 Aug 2007 18:38:59 +0000 From: "David Harrington" To: "'Ron Bonica'" , References: <46D5953B.9040607@juniper.net> Subject: RE: [OPSAWG] XSDMI BoF Date: Wed, 29 Aug 2007 14:38:53 -0400 Message-ID: <011f01c7ea6b$dc03df30$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46D5953B.9040607@juniper.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcfqVAjZKdORRnjxRA2qE6kISPDAhQABk+uQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi, I don't now if all the feedback you have received has been public or not. Obviously I have been watching the public response to XSDMI. XSDMI is explicitly a protocol-independent translstion of SMIv2 to XSD. SMIv2 is supposed to be protocol-independent, so it can be used with multiple protocols. (The SNMP community unfortunately gets mixed reviews for keeping MIBs protocol-neutral.) During the BOF, the response was 13 for and 0 against doing work on the datatypes. During the BOF, the response was 9 for and 0 against doing mib module translation. At the request of the ADs, we asked the OPSAWG whether we could work on these twp items in this WG to save the difficulty of finding new chairs and so on. One person, and only one person, Juergen Schoenwaelder, has raised objections to this work going forward: 'the existence of the translated XSD output will cause future data modeling languages to be "consistent" with the XSD output coming out of the translation.' Obviouly, this person who is part of a design team developing a data modeling approach for Netconf believes the XSDMI work is being done specifically for Netconf. I disagree with his assessment. One person, Andy Bierman, raised questions about the intent of this work. I believe I answered his questions. It has been oft repeated in the Netconf WG that any valid XML qualifies as content for Netconf. There has been no agreement that XSD must be developed to specify a mechanism to validate the XML content. The YANG proposal (draft-yang-pre-00.txt yet to be made public) actually does not use XSD as its SMI; it uses a newly-developed C-like modeling language. The NCX proposal (draft-bierman-ncx-smi-00) accepts any base data types defined in XSD and in SMIv2, and holds that higher level "data type definitions are considered to be abstract constructs that cannot be accessed by any protocol mechanism." So there is no conflict with these two emerging Netconf proposals. The XSDMI effort is designed to produce **one** XSD specification to guide translating MIB data into **a** valid XML format useable with any protocol. The XSDMI XSD could also be used to perform validation of the data. The XSDMI XSD should not in any way constrain other approaches to developing valid XML for use with Netconf, whether those approaches utilize XSD or other protocols for specification and validation purposes. I agree the XSDMI effort should not constrain the Netconf efforts, but I also believe the Netconf efforts should not constrain the XSDMI effort. We have waited years for the Netconf protocol developers to reach consensus to even start developing a data modeling language that can be used to specify valid XML useable with Netconf. The Netconf community includes vendors and operators and not just protocol designers. The Netconf **community** is obviously one potential customer for the XSDMI XSD. There has been significant demand from vendors for standardized data models to go with the Netconf protocol; so far they are constrained to providing proprietary data models for use with the Netconf protocol. The XSDMI XSD would allow vendors who are implementing the Netconf protocol and their customers who are deploying the Netconf protocol to use the XSDMI XSD to at least monitor their existing standardized MIB instrumentation. Vendors can provide their customers with a partially-useful and partially-interoperable Netconf protocol implementation, while waiting for the Netconf protocol designers to reach consensus on a complete configuration-oriented data modeling language and to start developing Netconf-specific data models for interoperable configuration. It seems unreasonable for the Netconf protocol developers to deliberately deny the rest of the Netconf community the option of an intermediate solution. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Ron Bonica [mailto:rbonica@juniper.net] > Sent: Wednesday, August 29, 2007 11:48 AM > To: opsawg@ietf.org > Subject: [OPSAWG] XSDMI BoF > > Folks, > > Dan and I have received light but mixed reaction to the XSDMI > BoF. A few > participants have supported XSDMI becoming a working group while a > smaller number have objected. The people objecting have stated that > XSDMI might interfere with other work aimed at creating an > SMI designed > specifically for NETCONF. > > So, Dan and I are deferring our decision wrt to XSDMI for at least one > IETF. We would like to give the folks proposing an NETCONF > specific SMI > some time to arrange a BoF session. After having seen that BoF, the > community will decide whether one, the other or both groups should > become working groups. > > Ron > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www1.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Wed Aug 29 15:19:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQT48-0005JY-5b; Wed, 29 Aug 2007 15:19:00 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IQT44-0005I9-Fm for opsawg-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 15:18:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQT43-0005Ff-FV for opsawg@ietf.org; Wed, 29 Aug 2007 15:18:55 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQT42-00066n-Vt for opsawg@ietf.org; Wed, 29 Aug 2007 15:18:55 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=D7be7zzigM+02KJNVaCf079npRRqZu77BUrVjZPgvEcgIGV+6tKBsfzib7dJEsg9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.101] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQT42-0002uO-7q for opsawg@ietf.org; Wed, 29 Aug 2007 15:18:54 -0400 Message-ID: <000401c7ea71$c97d8900$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <46D5953B.9040607@juniper.net> <011f01c7ea6b$dc03df30$6702a8c0@china.huawei.com> Subject: Re: [OPSAWG] XSDMI BoF Date: Wed, 29 Aug 2007 12:21:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356329610f99eba6d8d26d4612dbdfbc5ef350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.101 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi - > From: "David Harrington" > To: "'Ron Bonica'" ; > Sent: Wednesday, August 29, 2007 11:38 AM > Subject: RE: [OPSAWG] XSDMI BoF ... > It seems unreasonable for the Netconf protocol developers to > deliberately deny the rest of the Netconf community the option of an > intermediate solution. ... As a no longer terribly interested observer... While I'm loathe to ascribe intent to the netconf protocol developers, it's been clear from the beginning that one of the consequences of making the protocol largely payload agnostic, and of deferring any work on anything resembling a data model or architecture, would be that by the time any standardization work began on such a model or architecture, it would be too late for it to displace the proprietary ones that provided the motivation for the netconf work in the first place. What's been delivered is exactly what the operators at the IAB workshop told us they did not want, and the direction the remaining work is taking does little to address their concerns. But that's also no surprise, and was evident from the early days of netconf. It should not be surprising that those who already have significant investment in particular approaches to the representation of data models might harbor some opposition to any kind of standardization effort. Even with all kinds of assurances that it's just another approach, there's always the possibilty, even the likelihood, that a WG would produce something superior to somebody's proprietary hack. At the same time, there may also be a "once-burned, twice-shy" feeling among those involved in the SMIng effort. But take heart. Good ideas appear to engender particularly fierce opposition in the IETF. The trouble is that the existence of opposition doesn't guarantee that the idea is good. :-) Randy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Wed Aug 29 15:30:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTF0-00016W-7J; Wed, 29 Aug 2007 15:30:14 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IQTEq-00012S-It for opsawg-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 15:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTEp-00012G-Kd for opsawg@ietf.org; Wed, 29 Aug 2007 15:30:04 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQTEo-0004QM-8f for opsawg@ietf.org; Wed, 29 Aug 2007 15:30:03 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 29 Aug 2007 12:30:01 -0700 Received: from [172.23.1.9] ([172.23.1.9] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 15:30:00 -0400 Message-ID: <46D5C934.4080906@juniper.net> Date: Wed, 29 Aug 2007 15:29:56 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Harrington Subject: Re: [OPSAWG] XSDMI BoF References: <46D5953B.9040607@juniper.net> <011f01c7ea6b$dc03df30$6702a8c0@china.huawei.com> In-Reply-To: <011f01c7ea6b$dc03df30$6702a8c0@china.huawei.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 19:30:00.0707 (UTC) FILETIME=[FDB5CD30:01C7EA72] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: opsawg@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org David, Please note that we have not rejected the XSDMI proposal. We are merely deferring a decision until we see the YANG BoF. Ron David Harrington wrote: > Hi, > > I don't now if all the feedback you have received has been public or > not. > Obviously I have been watching the public response to XSDMI. > > XSDMI is explicitly a protocol-independent translstion of SMIv2 to > XSD. SMIv2 is supposed to be protocol-independent, so it can be used > with multiple protocols. (The SNMP community unfortunately gets mixed > reviews for keeping MIBs protocol-neutral.) > > During the BOF, the response was 13 for and 0 against doing work on > the datatypes. > During the BOF, the response was 9 for and 0 against doing mib module > translation. > > At the request of the ADs, we asked the OPSAWG whether we could work > on these twp items in this WG to save the difficulty of finding new > chairs and so on. > > One person, and only one person, Juergen Schoenwaelder, has raised > objections to this work going forward: > 'the existence of the translated XSD output will cause future data > modeling languages to be "consistent" with the XSD output coming out > of the translation.' > > Obviouly, this person who is part of a design team developing a data > modeling approach for Netconf believes the XSDMI work is being done > specifically for Netconf. I disagree with his assessment. > > One person, Andy Bierman, raised questions about the intent of this > work. I believe I answered his questions. > > It has been oft repeated in the Netconf WG that any valid XML > qualifies as content for Netconf. There has been no agreement that XSD > must be developed to specify a mechanism to validate the XML content. > The YANG proposal (draft-yang-pre-00.txt yet to be made public) > actually does not use XSD as its SMI; it uses a newly-developed C-like > modeling language. The NCX proposal (draft-bierman-ncx-smi-00) accepts > any base data types defined in XSD and in SMIv2, and holds that higher > level "data type definitions are considered to be abstract constructs > that cannot be accessed by any protocol mechanism." So there is no > conflict with these two emerging Netconf proposals. > > The XSDMI effort is designed to produce **one** XSD specification to > guide translating MIB data into **a** valid XML format useable with > any protocol. The XSDMI XSD could also be used to perform validation > of the data. The XSDMI XSD should not in any way constrain other > approaches to developing valid XML for use with Netconf, whether those > approaches utilize XSD or other protocols for specification and > validation purposes. > > I agree the XSDMI effort should not constrain the Netconf efforts, but > I also believe the Netconf efforts should not constrain the XSDMI > effort. > > We have waited years for the Netconf protocol developers to reach > consensus to even start developing a data modeling language that can > be used to specify valid XML useable with Netconf. The Netconf > community includes vendors and operators and not just protocol > designers. The Netconf **community** is obviously one potential > customer for the XSDMI XSD. There has been significant demand from > vendors for standardized data models to go with the Netconf protocol; > so far they are constrained to providing proprietary data models for > use with the Netconf protocol. > > The XSDMI XSD would allow vendors who are implementing the Netconf > protocol and their customers who are deploying the Netconf protocol to > use the XSDMI XSD to at least monitor their existing standardized MIB > instrumentation. Vendors can provide their customers with a > partially-useful and partially-interoperable Netconf protocol > implementation, while waiting for the Netconf protocol designers to > reach consensus on a complete configuration-oriented data modeling > language and to start developing Netconf-specific data models for > interoperable configuration. > > It seems unreasonable for the Netconf protocol developers to > deliberately deny the rest of the Netconf community the option of an > intermediate solution. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > > >>-----Original Message----- >>From: Ron Bonica [mailto:rbonica@juniper.net] >>Sent: Wednesday, August 29, 2007 11:48 AM >>To: opsawg@ietf.org >>Subject: [OPSAWG] XSDMI BoF >> >>Folks, >> >>Dan and I have received light but mixed reaction to the XSDMI >>BoF. A few >>participants have supported XSDMI becoming a working group while a >>smaller number have objected. The people objecting have stated that >>XSDMI might interfere with other work aimed at creating an >>SMI designed >>specifically for NETCONF. >> >>So, Dan and I are deferring our decision wrt to XSDMI for at least > > one > >>IETF. We would like to give the folks proposing an NETCONF >>specific SMI >>some time to arrange a BoF session. After having seen that BoF, the >>community will decide whether one, the other or both groups should >>become working groups. >> >> Ron >> >> >> >>_______________________________________________ >>OPSAWG mailing list >>OPSAWG@ietf.org >>https://www1.ietf.org/mailman/listinfo/opsawg >> > > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Thu Aug 30 01:22:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQcU6-0005RC-05; Thu, 30 Aug 2007 01:22:26 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IQcU3-0005QQ-2F for opsawg-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 01:22:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQcU2-0005QI-LS for opsawg@ietf.org; Thu, 30 Aug 2007 01:22:22 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQcU1-0006is-Ag for opsawg@ietf.org; Thu, 30 Aug 2007 01:22:22 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 30 Aug 2007 01:22:18 -0400 X-IronPort-AV: i="4.19,323,1183348800"; d="scan'208"; a="59274401:sNHT10957008" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPSAWG] XSDMI BoF Date: Thu, 30 Aug 2007 07:21:38 +0200 Message-ID: In-Reply-To: <46D5C934.4080906@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] XSDMI BoF Thread-Index: AcfqcxsQJttJM3giS1aHPAGdrr+mhAAUHaPw References: <46D5953B.9040607@juniper.net><011f01c7ea6b$dc03df30$6702a8c0@china.huawei.com> <46D5C934.4080906@juniper.net> From: "Romascanu, Dan (Dan)" To: "Ron Bonica" , "David Harrington" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: opsawg@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org As I already said, speaking as a contributor, I support doing this work. I believe it is high priority and that the OPSAWG could be the appropriate home. I do not see a problem in running parallel data modeling efforts, provided that they are distinct in scope and in time span. That is why I believe that we want to continue the work on the XSDMI Internet-Drafts using OPSAWG list for discussions and decide by Vancouver about adoption as a chartered item and where. =20 Dan =20 =20 > -----Original Message----- > From: Ron Bonica [mailto:rbonica@juniper.net]=20 > Sent: Wednesday, August 29, 2007 10:30 PM > To: David Harrington > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] XSDMI BoF >=20 > David, >=20 > Please note that we have not rejected the XSDMI proposal. We=20 > are merely deferring a decision until we see the YANG BoF. >=20 > Ron >=20 > David Harrington wrote: > > Hi, > >=20 > > I don't now if all the feedback you have received has been=20 > public or=20 > > not. > > Obviously I have been watching the public response to XSDMI. > >=20 > > XSDMI is explicitly a protocol-independent translstion of SMIv2 to=20 > > XSD. SMIv2 is supposed to be protocol-independent, so it=20 > can be used=20 > > with multiple protocols. (The SNMP community unfortunately=20 > gets mixed=20 > > reviews for keeping MIBs protocol-neutral.) > >=20 > > During the BOF, the response was 13 for and 0 against doing work on=20 > > the datatypes. > > During the BOF, the response was 9 for and 0 against doing=20 > mib module=20 > > translation. > >=20 > > At the request of the ADs, we asked the OPSAWG whether we=20 > could work=20 > > on these twp items in this WG to save the difficulty of finding new=20 > > chairs and so on. > >=20 > > One person, and only one person, Juergen Schoenwaelder, has raised=20 > > objections to this work going forward: > > 'the existence of the translated XSD output will cause future data=20 > > modeling languages to be "consistent" with the XSD output=20 > coming out=20 > > of the translation.' > >=20 > > Obviouly, this person who is part of a design team=20 > developing a data=20 > > modeling approach for Netconf believes the XSDMI work is being done=20 > > specifically for Netconf. I disagree with his assessment. > >=20 > > One person, Andy Bierman, raised questions about the intent of this=20 > > work. I believe I answered his questions. > >=20 > > It has been oft repeated in the Netconf WG that any valid XML=20 > > qualifies as content for Netconf. There has been no=20 > agreement that XSD=20 > > must be developed to specify a mechanism to validate the=20 > XML content. > > The YANG proposal (draft-yang-pre-00.txt yet to be made public)=20 > > actually does not use XSD as its SMI; it uses a=20 > newly-developed C-like=20 > > modeling language. The NCX proposal=20 > (draft-bierman-ncx-smi-00) accepts=20 > > any base data types defined in XSD and in SMIv2, and holds=20 > that higher=20 > > level "data type definitions are considered to be abstract=20 > constructs=20 > > that cannot be accessed by any protocol mechanism." So there is no=20 > > conflict with these two emerging Netconf proposals. > >=20 > > The XSDMI effort is designed to produce **one** XSD=20 > specification to=20 > > guide translating MIB data into **a** valid XML format useable with=20 > > any protocol. The XSDMI XSD could also be used to perform=20 > validation=20 > > of the data. The XSDMI XSD should not in any way constrain other=20 > > approaches to developing valid XML for use with Netconf,=20 > whether those=20 > > approaches utilize XSD or other protocols for specification and=20 > > validation purposes. > >=20 > > I agree the XSDMI effort should not constrain the Netconf=20 > efforts, but=20 > > I also believe the Netconf efforts should not constrain the XSDMI=20 > > effort. > >=20 > > We have waited years for the Netconf protocol developers to reach=20 > > consensus to even start developing a data modeling language=20 > that can=20 > > be used to specify valid XML useable with Netconf. The Netconf=20 > > community includes vendors and operators and not just protocol=20 > > designers. The Netconf **community** is obviously one potential=20 > > customer for the XSDMI XSD. There has been significant demand from=20 > > vendors for standardized data models to go with the Netconf=20 > protocol;=20 > > so far they are constrained to providing proprietary data=20 > models for=20 > > use with the Netconf protocol. > >=20 > > The XSDMI XSD would allow vendors who are implementing the Netconf=20 > > protocol and their customers who are deploying the Netconf=20 > protocol to=20 > > use the XSDMI XSD to at least monitor their existing=20 > standardized MIB=20 > > instrumentation. Vendors can provide their customers with a=20 > > partially-useful and partially-interoperable Netconf protocol=20 > > implementation, while waiting for the Netconf protocol designers to=20 > > reach consensus on a complete configuration-oriented data modeling=20 > > language and to start developing Netconf-specific data models for=20 > > interoperable configuration. > >=20 > > It seems unreasonable for the Netconf protocol developers to=20 > > deliberately deny the rest of the Netconf community the=20 > option of an=20 > > intermediate solution. > >=20 > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Ron Bonica [mailto:rbonica@juniper.net] > >>Sent: Wednesday, August 29, 2007 11:48 AM > >>To: opsawg@ietf.org > >>Subject: [OPSAWG] XSDMI BoF > >> > >>Folks, > >> > >>Dan and I have received light but mixed reaction to the=20 > XSDMI BoF. A=20 > >>few participants have supported XSDMI becoming a working=20 > group while a=20 > >>smaller number have objected. The people objecting have stated that=20 > >>XSDMI might interfere with other work aimed at creating an SMI=20 > >>designed specifically for NETCONF. > >> > >>So, Dan and I are deferring our decision wrt to XSDMI for at least > >=20 > > one > >=20 > >>IETF. We would like to give the folks proposing an NETCONF specific=20 > >>SMI some time to arrange a BoF session. After having seen that BoF,=20 > >>the community will decide whether one, the other or both=20 > groups should=20 > >>become working groups. > >> > >> Ron > >> > >> > >> > >>_______________________________________________ > >>OPSAWG mailing list > >>OPSAWG@ietf.org > >>https://www1.ietf.org/mailman/listinfo/opsawg > >> > >=20 > >=20 > >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www1.ietf.org/mailman/listinfo/opsawg >=20 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg