From mailman-bounces@core3.amsl.com Fri Feb 1 06:25:17 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BFE2939FF for ; Fri, 1 Feb 2008 06:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40svScC4yQDn for ; Fri, 1 Feb 2008 06:25:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3731A2A38CE for ; Fri, 1 Feb 2008 06:01:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ops-area-archive@optimus.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:07:38 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/ops-area/ops-area-archive%40optimus.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:25:28 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6733A2945AE for ; Fri, 1 Feb 2008 06:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhIGcv9zKIie for ; Fri, 1 Feb 2008 06:25:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D2929673F for ; Fri, 1 Feb 2008 06:00:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ops-area-archive@optimus.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:07:36 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/ops-area/ops-area-archive%40optimus.ietf.org From ops-area-bounces@ietf.org Wed Feb 6 02:29:43 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1863A6C67; Wed, 6 Feb 2008 02:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIl2BN5tX+m7; Wed, 6 Feb 2008 02:29:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2974A3A6C4E; Wed, 6 Feb 2008 02:29:42 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FBB43A6BF6; Wed, 6 Feb 2008 02:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38JGsHW0HUr5; Wed, 6 Feb 2008 02:29:39 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (unknown [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 1E30C3A6A88; Wed, 6 Feb 2008 02:29:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,312,1199682000"; d="scan'208";a="97937026" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 06 Feb 2008 05:31:10 -0500 X-IronPort-AV: E=Sophos;i="4.25,312,1199682000"; d="scan'208";a="151614006" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 06 Feb 2008 05:31:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 11:30:50 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] potenntial charter for PEPPERMINT Thread-Index: AchnnEUEgG2zYim4ThiA9K48R5nVLQBDvhmA From: "Romascanu, Dan (Dan)" To: , , Subject: [OPS-AREA] FW: [PEPPERMINT] potenntial charter for PEPPERMINT X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Comments are welcome. Dan -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, February 06, 2008 2:06 AM To: PEPPERMINT@ietf.org Subject: [PEPPERMINT] potenntial charter for PEPPERMINT Folks ..we had a successful BOF in Vancouver in order to progress the work towards a full charter by the IETF it is necessary to reach consensus on a charter. I have a proposal for a charter here below. I welcome comments public private etc. PROPOSED CHARTER FOR PEPPERMINT The IETF has been working on various aspects of Multi-Media Interconnection among administrative domains. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across administrative boundaries. These forms of interconnection will require various forms of data to be exchanged among administrative domains outside the normal scope of establishing various SIP sessions. The IETF has, in the past done, significant work on data exchanges among various network elements. PROVREG and NETCFG being the most prominent recent examples. Data exchanges to facilitate Multi-Media Interconnection are typically between various Client User Agents and Registries containing mappings of phone numbers to URI's, policies surrounding admission to points of network interconnection and various types of trunking data. In addition there is a specific need for redistribution of Registry data to various types of network databases. The proposed PEPPERMINT working group will build upon the knowledge and expertise of the PROVREG, ENUM and SPEERMINT working groups. The goal of the WG is to find a provisioning solution for interconnection to be ultimately used by SPEERMINT. The working group may also reuse elements of RFC 4114 if possible. The final work product(s) from this working group will be based upon XML. Additionally, bias will be given to using, HTTP/REST, HTTP/XML-RPC, or HTTP/SOAP. The working group will draw upon expert advice and ongoing consultation from the ENUM, SPEERMINT and PROVREG working groups. PROPOSED GOALS AND MILESTONES Requirements for Interconnection data exchanges. July 08 Provisioning of Interconnection data registries. Sep 08 Provisioning of Interconnection data caches. Dec 08 Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org http://www.ietf.org/mailman/listinfo/peppermint _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org http://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Feb 6 08:13:31 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC4C3A6F21; Wed, 6 Feb 2008 08:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, HTML_MESSAGE=1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7I4+1QQgnL5; Wed, 6 Feb 2008 08:13:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D3C3A6E10; Wed, 6 Feb 2008 08:13:29 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856033A6ECD for ; Wed, 6 Feb 2008 08:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAIBltHhmd8K for ; Wed, 6 Feb 2008 08:13:27 -0800 (PST) Received: from web27810.mail.ukl.yahoo.com (web27810.mail.ukl.yahoo.com [217.146.182.15]) by core3.amsl.com (Postfix) with SMTP id 447D03A6F17 for ; Wed, 6 Feb 2008 08:13:27 -0800 (PST) Received: (qmail 62843 invoked by uid 60001); 6 Feb 2008 16:14:58 -0000 Received: from [217.115.75.229] by web27810.mail.ukl.yahoo.com via HTTP; Wed, 06 Feb 2008 16:14:57 GMT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Wed, 6 Feb 2008 16:14:57 +0000 (GMT) From: Mehmet Ersue To: ops-dir@ietf.org, ops-area@ietf.org, peppermint@ietf.org MIME-Version: 1.0 Message-ID: <174616.62822.qm@web27810.mail.ukl.yahoo.com> Cc: NETCONF Subject: Re: [OPS-AREA] [PEPPERMINT] potenntial charter for PEPPERMINT X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0097267162==" Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org --===============0097267162== Content-Type: multipart/alternative; boundary="0-196080041-1202314497=:62822" --0-196080041-1202314497=:62822 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0AHi All,=0A=0AI fully agree with Margaret that the choice of the technolo= gy needs =0Ato be a group consensus.=0A=0ASince IETF and IESG are always in= terested to use already existing =0Aprotocols if they are suitable to do th= e job I'm pretty much interested to =0Ahear the concrete arguments why the = gateway configuration cannot be =0Adone with NETCONF over SOAP.=0A=0ANETCON= F is a suitable protocol for network element configuration and =0Aconfigura= tion data exchange. NETCONF is also reliable and supports =0Anotification a= nd transaction mechanisms. BTW: NETCONF over SOAP =0Ais not heavy-weight.= =0A=0A=0ANETCONF is already available as a standard and has been implemente= d =0Amany times. Already different companies are using it in their products= .=0A=0AYou don't get all these functionalities for free. It takes usually m= any years =0Aof hard work to develop the standard documents and get them st= able based =0Aon implementations.=0A=0AThis is the reason why IESG is usual= ly keen of using already existing IETF =0Atechnologies instead of starting = another overlapping work which takes years=0Ato finalize.=0A=0ASo, please t= ell me, what are the hard-reasons for not using an existing =0Atechnology?= =0A=0ACheers, =0AMehmet Ersue=0A =0A=0A> -----Original Message-----=0A> Fro= m: owner-netconf@ops.ietf.org =0A> [mailto:owner-netconf@ops.ietf.org] On B= ehalf Of ext Margaret =0A> Wasserman=0A> Sent: Wednesday, February 06, 2008= 4:29 PM=0A> To: Romascanu, Dan (Dan)=0A> Cc: ops-dir@ietf.org; ops-area@ie= tf.org; netconf@ops.ietf.org=0A> Subject: Re: [PEPPERMINT] potenntial chart= er for PEPPERMINT=0A> =0A> =0A> By "NETCFG", does Richard mean NETCONF?=0A>= =0A> I would prefer to see the line removed that states that "bias =0A> wi= ll be =0A> given" to particular solutions. I think it is okay to charter = a =0A> group with restrictions on the solution space, such as "will =0A> b= e based =0A> on XML" if there is consensus to do so, but I'm not sure what= it =0A> would mean to charter a group and require that they be "biased" = =0A> towards certain solutions. If there isn't consensus that the =0A> so= lution must be based on one of the technologies listed, I think =0A> that = line should be removed and the choice of technology should be a =0A> group= consensus decision.=0A> =0A> Margaret=0A> =0A> =0A> =0A> On Feb 6, 2008, a= t 5:30 AM, Romascanu, Dan (Dan) wrote:=0A> =0A> >=0A> > Comments are welcom= e.=0A> >=0A> > Dan=0A> >=0A> >=0A> >=0A> >=0A> > -----Original Message-----= =0A> > From: peppermint-bounces@ietf.org =0A> [mailto:peppermint-bounces@ie= tf.org]=0A> > On Behalf Of Richard Shockey=0A> > Sent: Wednesday, February = 06, 2008 2:06 AM=0A> > To: PEPPERMINT@ietf.org=0A> > Subject: [PEPPERMINT] = potenntial charter for PEPPERMINT=0A> >=0A> >=0A> > Folks ..we had a succes= sful BOF in Vancouver in order to =0A> progress the=0A> > work towards a fu= ll charter by the IETF it is necessary to reach=0A> > consensus on a charte= r.=0A> >=0A> > I have a proposal for a charter here below. I welcome =0A> c= omments public=0A> > private etc.=0A> >=0A> >=0A> > PROPOSED CHARTER FOR PE= PPERMINT=0A> >=0A> > The IETF has been working on various aspects of Multi-= Media=0A> > Interconnection among administrative domains.=0A> >=0A> > ENUM = is specifically chartered to develop protocols that involve the=0A> > trans= lation of E.164 numbers to URI's.=0A> >=0A> > SPEERMINT has been chartered = to develop best current practices among=0A> > real-time application service= providers and how such services=0A> > interconnect across administrative b= oundaries.=0A> >=0A> > These forms of interconnection will require various = forms of data =0A> > to be=0A> > exchanged among administrative domains ou= tside the normal scope of=0A> > establishing various SIP sessions.=0A> >=0A= > > The IETF has, in the past done, significant work on data exchanges =0A= > > among=0A> > various network elements. PROVREG and NETCFG being the most= =0A> prominent=0A> > recent examples.=0A> >=0A> > Data exchanges to facili= tate Multi-Media Interconnection =0A> are typically=0A> > between various C= lient User Agents and Registries containing =0A> > mappings of=0A> > phone= numbers to URI's, policies surrounding admission to points of=0A> > networ= k interconnection and various types of trunking data. In =0A> > addition= =0A> > there is a specific need for redistribution of Registry data to =0A= > > various=0A> > types of network databases.=0A> >=0A> > The proposed PEPP= ERMINT working group will build upon the =0A> knowledge =0A> > and=0A> > e= xpertise of the PROVREG, ENUM and SPEERMINT working groups. The =0A> > goa= l of=0A> > the WG is to find a provisioning solution for interconnection to= be=0A> > ultimately used by SPEERMINT. The working group may also reuse = =0A> > elements=0A> > of RFC 4114 if possible.=0A> >=0A> > The final work p= roduct(s) from this working group will be based upon=0A> > XML.=0A> >=0A> >= Additionally, bias will be given to using, HTTP/REST, =0A> HTTP/XML-RPC, o= r=0A> > HTTP/SOAP.=0A> >=0A> > The working group will draw upon expert advi= ce and ongoing =0A> > consultation=0A> > from the ENUM, SPEERMINT and PROV= REG working groups.=0A> >=0A> >=0A> > PROPOSED GOALS AND MILESTONES=0A> >= =0A> >=0A> > Requirements for Interconnection data exchanges. July 08= =0A> >=0A> > Provisioning of Interconnection data registries. Sep 08= =0A> >=0A> > Provisioning of Interconnection data caches. Dec 08= =0A> >=0A> >=0A> > Richard Shockey=0A> > Director, Member of the Technical = Staff=0A> > NeuStar=0A> > 46000 Center Oak Plaza - Sterling, VA 20166 PSTN = Office +1 =0A> > 571.434.5651=0A> > PSTN Mobile: +1 703.593.2683 =0A> > =0A> >= =0A> >=0A> >=0A> >=0A> > _______________________________________________=0A= > > PEPPERMINT mailing list=0A> > PEPPERMINT@ietf.org=0A> > http://www.ietf= .org/mailman/listinfo/peppermint=0A> >=0A> > --=0A> > to unsubscribe send a= message to netconf-request@ops.ietf.org with=0A> > the word 'unsubscribe' = in a single line as the message text body.=0A> > archive: =0A> =0A> =0A> --=0A> to unsubscribe send a message to n= etconf-request@ops.ietf.org with=0A> the word 'unsubscribe' in a single lin= e as the message text body.=0A> archive: =0A> =0A=0A=0A=0A=0A Lesen Sie Ihre E-Mails jetzt einfach von unterw= egs.=0Awww.yahoo.de/go --0-196080041-1202314497=:62822 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi All,

I fully agree with Margaret that the choice of t= he technology needs
to be a group consensus.

Since IETF and IESG= are always interested to use already existing
protocols if they are su= itable to do the job I'm pretty much interested to
hear the concrete ar= guments why the gateway configuration cannot be
done with NETCONF over = SOAP.

NETCONF is a suitable protocol for network element configurati= on and
configuration data exchange. NETCONF is also reliable and suppor= ts
notification and transaction mechanisms. BTW: NETCONF over SOAP
= is not heavy-weight.

=0ANETCONF is already available as a standard a= nd has been implemented
many times. Already different companies are usi= ng it in their products.

You don't get all these functionalities for= free. It takes usually many years
of hard work to develop the standard= documents and get them stable based
on implementations.

This is= the reason why IESG is usually keen of using already existing IETF
tec= hnologies instead of starting another overlapping work which takes yearsto finalize.

So, please tell me, what are the hard-reasons for not = using an existing
technology?

Cheers,
Mehmet Ersue
 =

> -----Original Message-----
> From: owner-netconf@ops.iet= f.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Margare= t
> Wasserman
> Sent: Wednesday, February 06, 2008 4:29 PM
= > To: Romascanu, Dan (Dan)
> Cc: ops-dir@ietf.org; ops-area@ietf.o= rg; netconf@ops.ietf.org
> Subject: Re: [PEPPERMINT] potenntial charter = for PEPPERMINT
>
>
> By "NETCFG", does Richard mean NET= CONF?
>
> I would prefer to see the line removed that states t= hat "bias
> will be 
> given" to particular solutions.&n= bsp; I think it is okay to charter a 
> group with restrictions= on the solution space, such as "will
> be based 
> on X= ML" if there is consensus to do so, but I'm not sure what it 
>= would mean to charter a group and require that they be "biased" 
= > towards certain solutions.  If there isn't consensus that the&nbs= p;
> solution must be based on one of the technologies listed, I thi= nk 
> that line should be removed and the choice of technology = should be a 
> group consensus decision.
>
> Marga= ret
>
>
>
> On Feb 6, 2008, at 5:30 AM, Romascanu, Dan (Dan) wrote:
>
> >
> > Comments ar= e welcome.
> >
> > Dan
> >
> >
> = >
> >
> > -----Original Message-----
> > From= : peppermint-bounces@ietf.org
> [mailto:peppermint-bounces@ietf.org]=
> > On Behalf Of Richard Shockey
> > Sent: Wednesday, Fe= bruary 06, 2008 2:06 AM
> > To: PEPPERMINT@ietf.org
> > S= ubject: [PEPPERMINT] potenntial charter for PEPPERMINT
> >
>= >
> > Folks ..we had a successful BOF in Vancouver in order to=
> progress the
> > work towards a full charter by the IETF= it is necessary to reach
> > consensus on a charter.
> >=
> > I have a proposal for a charter here below. I welcome
>= ; comments public
> > private etc.
> >
> >
&g= t; > PROPOSED CHARTER FOR PEPPERMINT
> >
> > The IETF has been working on various aspects of Multi-Media
> > I= nterconnection among administrative domains.
> >
> > ENUM= is specifically chartered to develop protocols that involve the
> &g= t; translation of E.164 numbers to URI's.
> >
> > SPEERMI= NT has been chartered to develop best current practices among
> > = real-time application service providers and how such services
> > = interconnect across administrative boundaries.
> >
> > Th= ese forms of interconnection will require various forms of data 
&= gt; > to be
> > exchanged among administrative domains outside = the normal scope of
> > establishing various SIP sessions.
>= >
> > The IETF has, in the past done, significant work on data= exchanges 
> > among
> > various network elements.= PROVREG and NETCFG being the most
> prominent
> > recent examples.
> >
> > Data exchanges to facilitate Mu= lti-Media Interconnection
> are typically
> > between vario= us Client User Agents and Registries containing 
> > mapping= s of
> > phone numbers to URI's, policies surrounding admission to= points of
> > network interconnection and various types of trunki= ng data.  In 
> > addition
> > there is a spec= ific need for redistribution of Registry data to 
> > variou= s
> > types of network databases.
> >
> > The pr= oposed PEPPERMINT working group will build upon the
> knowledge = ;
> > and
> > expertise of the PROVREG, ENUM and SPEERMI= NT working groups. The 
> > goal of
> > the WG is t= o find a provisioning solution for interconnection to be
> > ultim= ately used by SPEERMINT. The working group may also reuse 
> > elements
> > of RFC 4114 if possible.
> ><= br>> > The final work product(s) from this working group will be base= d upon
> > XML.
> >
> > Additionally, bias will = be given to using, HTTP/REST,
> HTTP/XML-RPC, or
> > HTTP/S= OAP.
> >
> > The working group will draw upon expert advi= ce and ongoing 
> > consultation
> > from the ENUM,= SPEERMINT and PROVREG working groups.
> >
> >
> &g= t; PROPOSED GOALS AND MILESTONES
> >
> >
> > Req= uirements for Interconnection data exchanges.     =   July 08
> >
> > Provisioning of Interconnection da= ta registries.       Sep 08
> >
&= gt; > Provisioning of Interconnection data caches.   &nbs= p;       Dec 08
> >
> >
> > Richard Shockey
> > Director, Member of the Tec= hnical Staff
> > NeuStar
> > 46000 Center Oak Plaza - Ste= rling, VA 20166 PSTN Office +1 
> > 571.434.5651
> >= ; PSTN Mobile: +1 703.593.2683 <mailto:richard(at)shockey.us>
>= > <mailto:richard.shockey(at)neustar.biz>
> >
> &g= t;
> >
> >
> > _________________________________= ______________
> > PEPPERMINT mailing list
> > PEPPERMINT= @ietf.org
> > http://www.ietf.org/mailman/listinfo/pepper= mint
> >
> > --
> > to unsubscribe se= nd a message to netconf-request@ops.ietf.org with
> > the word 'un= subscribe' in a single line as the message text body.
> > ar= chive: <http://ops.ietf.org/lists/netc= onf/>
>
>
> --
> to unsubscribe sen= d a message to netconf-request@ops.ietf.org with
> the word 'unsubscr= ibe' in a single line as the message text body.
> archive: <= http://ops= .ietf.org/lists/netconf/>
>

=0A =
=0A =0ALese= n Sie Ihre E-Mails jetzt einfach von unterwegs.. --0-196080041-1202314497=:62822-- --===============0097267162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org http://www.ietf.org/mailman/listinfo/ops-area --===============0097267162==-- From ops-area-bounces@ietf.org Wed Feb 6 09:10:41 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255553A7073; Wed, 6 Feb 2008 09:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-F1dXmNRuJM; Wed, 6 Feb 2008 09:10:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7F23A6F01; Wed, 6 Feb 2008 09:10:39 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37923A7042 for ; Wed, 6 Feb 2008 09:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUusxNiSU+AI for ; Wed, 6 Feb 2008 09:10:37 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id D555D3A7029 for ; Wed, 6 Feb 2008 09:10:36 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA09.westchester.pa.mail.comcast.net with comcast id mGJS1Y00L0vyq2s5907Z00; Wed, 06 Feb 2008 17:11:37 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id mHC21Y00N4HwxpC3R00000; Wed, 06 Feb 2008 17:12:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=RvT98sDzUqoA:10 a=48vgC7mUAAAA:8 a=FCdg5C2ZMgz1w-ttZMMA:9 a=Qc0xSEunEc0YlsReHtsA:7 a=EyCJ_V9qyqIQq8_S9HlZlwOk7BUA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=shQN7GnF_WUA:10 a=ivbTfD_dPm4A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Margaret Wasserman'" , "'Romascanu, Dan \(Dan\)'" References: Date: Wed, 6 Feb 2008 12:12:06 -0500 Message-ID: <01c001c868e3$67075da0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acho1QRUxvBOizCBRfOkfDjVD1glogAB/QhA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: ops-dir@ietf.org, ops-area@ietf.org, netconf@ops.ietf.org Subject: Re: [OPS-AREA] [OPS-DIR] [PEPPERMINT] potenntial charter for PEPPERMINT X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Hi, A Google search shows NETCFG to be an open-source GUI-based application for configuring networks. I would be very concerned if the charter calls for a solution "biased" toward a vendor-specific offering, even if the vendor uses open-source and the MIT license, since we are supposed to develop vendor-neutral standards, and biased != neutral. If the intention was to reference NETCONF, then I have a concern that the expressed bias is to favor a non-mandatory-to-implement "transport" for NETCONF. I agree that the line expressing a bias for certain solutions should be removed. I would not object to a line expressing a constraint for solutions that leverage existing IETF standards for certain aspects, such as security. But I'm not sure I know what is to be delivered well enough to know how existing standards could be leveraged. Overall, I find the charter wording to be too ambiguous to adequately describe the scope of the work to be done. "find a provisioning solution for interconnection" does not seem sufficiently focused to identify the expected deliverables. Is this WG chartered to produce a protocol, some data models, functionality to manage caches? I'm just not really sure what is being proposed as deliverables, and would be hard pressed to know when the WG drifted off-topic or completed their work. I think the charter wording and scope needs to be tightened significantly to make this engineering-ready. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: ops-dir-bounces@ietf.org > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Margaret Wasserman > Sent: Wednesday, February 06, 2008 10:29 AM > To: Romascanu, Dan (Dan) > Cc: ops-dir@ietf.org; netconf@ops.ietf.org; ops-area@ietf.org > Subject: Re: [OPS-DIR] [PEPPERMINT] potenntial charter for PEPPERMINT > > > By "NETCFG", does Richard mean NETCONF? > > I would prefer to see the line removed that states that "bias > will be > given" to particular solutions. I think it is okay to charter a > group with restrictions on the solution space, such as "will > be based > on XML" if there is consensus to do so, but I'm not sure what it > would mean to charter a group and require that they be "biased" > towards certain solutions. If there isn't consensus that the > solution must be based on one of the technologies listed, I think > that line should be removed and the choice of technology should be a > group consensus decision. > > Margaret > > > > On Feb 6, 2008, at 5:30 AM, Romascanu, Dan (Dan) wrote: > > > > > Comments are welcome. > > > > Dan > > > > > > > > > > -----Original Message----- > > From: peppermint-bounces@ietf.org > [mailto:peppermint-bounces@ietf.org] > > On Behalf Of Richard Shockey > > Sent: Wednesday, February 06, 2008 2:06 AM > > To: PEPPERMINT@ietf.org > > Subject: [PEPPERMINT] potenntial charter for PEPPERMINT > > > > > > Folks ..we had a successful BOF in Vancouver in order to > progress the > > work towards a full charter by the IETF it is necessary to reach > > consensus on a charter. > > > > I have a proposal for a charter here below. I welcome > comments public > > private etc. > > > > > > PROPOSED CHARTER FOR PEPPERMINT > > > > The IETF has been working on various aspects of Multi-Media > > Interconnection among administrative domains. > > > > ENUM is specifically chartered to develop protocols that involve the > > translation of E.164 numbers to URI's. > > > > SPEERMINT has been chartered to develop best current practices among > > real-time application service providers and how such services > > interconnect across administrative boundaries. > > > > These forms of interconnection will require various forms of data > > to be > > exchanged among administrative domains outside the normal scope of > > establishing various SIP sessions. > > > > The IETF has, in the past done, significant work on data exchanges > > among > > various network elements. PROVREG and NETCFG being the most > prominent > > recent examples. > > > > Data exchanges to facilitate Multi-Media Interconnection > are typically > > between various Client User Agents and Registries containing > > mappings of > > phone numbers to URI's, policies surrounding admission to points of > > network interconnection and various types of trunking data. In > > addition > > there is a specific need for redistribution of Registry data to > > various > > types of network databases. > > > > The proposed PEPPERMINT working group will build upon the > knowledge > > and > > expertise of the PROVREG, ENUM and SPEERMINT working groups. The > > goal of > > the WG is to find a provisioning solution for interconnection to be > > ultimately used by SPEERMINT. The working group may also reuse > > elements > > of RFC 4114 if possible. > > > > The final work product(s) from this working group will be based upon > > XML. > > > > Additionally, bias will be given to using, HTTP/REST, > HTTP/XML-RPC, or > > HTTP/SOAP. > > > > The working group will draw upon expert advice and ongoing > > consultation > > from the ENUM, SPEERMINT and PROVREG working groups. > > > > > > PROPOSED GOALS AND MILESTONES > > > > > > Requirements for Interconnection data exchanges. July 08 > > > > Provisioning of Interconnection data registries. Sep 08 > > > > Provisioning of Interconnection data caches. Dec 08 > > > > > > Richard Shockey > > Director, Member of the Technical Staff > > NeuStar > > 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 > > 571.434.5651 > > PSTN Mobile: +1 703.593.2683 > > > > > > > > > > > > _______________________________________________ > > PEPPERMINT mailing list > > PEPPERMINT@ietf.org > > http://www.ietf.org/mailman/listinfo/peppermint > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > http://www.ietf.org/mailman/listinfo/ops-dir > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org http://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Feb 6 13:30:16 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34493A7239; Wed, 6 Feb 2008 13:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdOHDQ5rSv0b; Wed, 6 Feb 2008 13:30:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C0C3A710A; Wed, 6 Feb 2008 13:30:15 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292C33A706B for ; Wed, 6 Feb 2008 13:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDuXbMckXmkP for ; Wed, 6 Feb 2008 13:30:13 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id B37183A710A for ; Wed, 6 Feb 2008 13:30:12 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA03.westchester.pa.mail.comcast.net with comcast id mGFT1Y0040QuhwU530SY00; Wed, 06 Feb 2008 21:31:34 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.westchester.pa.mail.comcast.net with comcast id mMXe1Y00E4HwxpC3N00000; Wed, 06 Feb 2008 21:31:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=RfDK97qgtYIS3NsaLBkA:9 a=gNMdwU6yEHXYBh90AJ8A:7 a=IlXPqTZjh2Q62nV-1vNOo9Sd9hMA:4 a=kkUMZHjH4KkA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=znN4F27_oeKHGX7-PDwA:9 a=UCTwQEmTJ8LrUQscvCrAUc2NNSUA:4 a=6bqG61NMjcsA:10 a=7rDK_FEieXjgBJkc8gsA:9 a=-JMVFHu1ablUMD9e_KdeM56Z7_EA:4 a=Dl1AYVxUF9kfHSGiD3wA:9 a=ubNuJgxn17jHkz4dCrDniTESpZsA:4 a=61tZBHfzjhcA:10 From: "David Harrington" To: Date: Wed, 6 Feb 2008 16:31:41 -0500 Message-ID: <01fc01c86907$aa5bf560$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01FD_01C868DD.C1885E60" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchL0TbR4ZrpfcHVR9WJ7hDx2A8/SAdLOMrA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: jxzhang@cernet.edu.cn Subject: [OPS-AREA] FW: I-D ACTION:draft-jinxiang-operations-and-management-ngi-00.txt X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_01FD_01C868DD.C1885E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am not sure what the correct forum is for commenting on this draft. The draft presents itself as a BCP, but I do not believe it qualifies for BCP status. I do not mean to be hard on the author, but I think this document really is more an academic research paper, and not ready to be published as an RFC of any status. First, the draft title is "based on NGI" but I saw nothing specific to NGI in the draft. Second, the draft references SNMPv1 (RFC1157), and talks about using Get-Next, but has no consideration of whether the proposed BCP also covers SNMPv3. There are a number of mentions of the "Gauge Counter Type", but SNMP has no "Gauge Counter Type"; it has gauges and counters with different properties. It appears the author does not understand the current state and terminology of SNMP standards. Third, this draft is really about optimizing an application's approach to polling. One proposal is to implement an adaptive polling strategy. A second proposal is to implement a prefetch approach (cacheing). Some existing NMS applications already implement adaptive polling, and I am not sure this paper reflects or adds anything to the current practices used by those applications. Since adaptive polling is implementation-dependent, I am not convinced this is work that needs to be standardized, and I am not aware that the application vendors seek to standardize their proprietary algorithms for adaptive polling. The prefetch approach is about sorting repetitive requests by the dynamism of the objects being fetched, aggregating varbinds with similar timeliness properties into combined "group" requests, and cacheing the information. The document also discusses group based on self-adaptive algorithms. Some existing NMS applications already implement time-based caching. Rearranging varbind requests can be tricky, for example when requests include objects that serve as discontinuity indicators for other objects in the varbind list. I do not see adequate discussion of such issues in this document. In my experience, the best current practice for dealing with large networks is to use distributed managers to poll different sections of the network, and to make the distributed information available as needed to operators. I had great difficulty following this document, partly because the English was not as clear as needed to be effective, but also because the discussion of SNMP seemed to reveal a limited understanding of the current stat eof SNMP, and an effort to represent the information in quasi-mathematical formulae sometimes made it difficult to understand what was being proposed. I do not feel this paper should be published as a BCP. I question whether it should be published as an RFC at all, since it could be misleading to readers that the IETF in any way approves the document. I suggest that the authors might consider taking this discussion to the Network Management Research Group of the IRTF, where SNMP measurement and analysis is being discussed. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com IETF MIB Doctor co-chair of the now-closed SNMPv3 WG -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, December 31, 2007 12:15 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-jinxiang-operations-and-management-ngi-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Retriving MIB Information based on NGI Author(s) : J. Zhang, et al. Filename : draft-jinxiang-operations-and-management-ngi-00.txt Pages : 15 Date : 2007-12-31 An important task of network management is to collect and analyze MIB information of various object combinations based on the Simple Network Management Protocol (SNMP) with proper frequency. The purpose of this document is to propose two algorithms to retrieve MIB information for a large (up to exponential) number of managed objects using SNMP in Next Generation Internet (NGI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jinxiang-operations-and-mana gement-ngi-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jinxiang-operations-and-management-ngi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jinxiang-operations-and-management-ngi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_01FD_01C868DD.C1885E60 Content-Type: Message/External-body; name="ATT03545.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT03545.dat" Content-Type: text/plain Content-ID: <2007-12-31112011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jinxiang-operations-and-management-ngi-00.txt ------=_NextPart_000_01FD_01C868DD.C1885E60 Content-Type: Message/External-body; name="draft-jinxiang-operations-and-management-ngi-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-jinxiang-operations-and-management-ngi-00.txt" Content-Type: text/plain Content-ID: <2007-12-31112011.I-D@ietf.org> ------=_NextPart_000_01FD_01C868DD.C1885E60 Content-Type: text/plain; name="ATT03548.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT03548.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_01FD_01C868DD.C1885E60 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org http://www.ietf.org/mailman/listinfo/ops-area ------=_NextPart_000_01FD_01C868DD.C1885E60-- From ops-area-bounces@ietf.org Wed Feb 6 22:12:37 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541AA3A73B2; Wed, 6 Feb 2008 22:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfI2my-RJMDO; Wed, 6 Feb 2008 22:12:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2288C3A6CA1; Wed, 6 Feb 2008 22:12:36 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9663A6CA1; Wed, 6 Feb 2008 22:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPzzG+PXl81o; Wed, 6 Feb 2008 22:12:32 -0800 (PST) Received: from smtp.unijos.edu.ng (mail.unijos.edu.ng [82.206.136.75]) by core3.amsl.com (Postfix) with ESMTP id BE1073A67D5; Wed, 6 Feb 2008 22:12:30 -0800 (PST) Received: from localhost (smtp.unijos.edu.ng [127.0.0.1]) by smtp.unijos.edu.ng (Postfix) with ESMTP id 86911681A7; Thu, 7 Feb 2008 07:11:17 +0100 (WAT) X-Virus-Scanned: amavisd-new at unijos.edu.ng Received: from smtp.unijos.edu.ng ([127.0.0.1]) by localhost (smtp.unijos.edu.ng [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMSUEkjaUxw8; Thu, 7 Feb 2008 07:11:02 +0100 (WAT) Received: from imap.unijos.edu.ng (imap.unijos.edu.ng [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.unijos.edu.ng (Postfix) with ESMTP id E101668181; Thu, 7 Feb 2008 07:11:02 +0100 (WAT) Received: from mail.unijos.edu.ng (localhost [127.0.0.1]) by imap.unijos.edu.ng (Postfix) with ESMTP id 367E92858D; Thu, 7 Feb 2008 07:41:19 +0100 (WAT) Received: from 192.168.192.2 (SquirrelMail authenticated user gogwim) by mail.unijos.edu.ng with HTTP; Thu, 7 Feb 2008 07:41:19 +0100 (WAT) Message-ID: <49191.192.168.192.2.1202366479.squirrel@mail.unijos.edu.ng> In-Reply-To: <174616.62822.qm@web27810.mail.ukl.yahoo.com> References: <174616.62822.qm@web27810.mail.ukl.yahoo.com> Date: Thu, 7 Feb 2008 07:41:19 +0100 (WAT) From: "GOGWIM, JOEL GODWIN" To: "Mehmet Ersue" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ops-dir@ietf.org, peppermint@ietf.org, NETCONF , ops-area@ietf.org Subject: Re: [OPS-AREA] [PEPPERMINT] potenntial charter for PEPPERMINT X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gogwim@unijos.edu.ng List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org I share your view too. On Wed, February 6, 2008 5:14 pm, Mehmet Ersue said: > > Hi All, > > I fully agree with Margaret that the choice of the technology needs > to be a group consensus. > > Since IETF and IESG are always interested to use already existing > protocols if they are suitable to do the job I'm pretty much interested to > hear the concrete arguments why the gateway configuration cannot be > done with NETCONF over SOAP. > > NETCONF is a suitable protocol for network element configuration and > configuration data exchange. NETCONF is also reliable and supports > notification and transaction mechanisms. BTW: NETCONF over SOAP > is not heavy-weight. > > > NETCONF is already available as a standard and has been implemented > many times. Already different companies are using it in their products. > > You don't get all these functionalities for free. It takes usually many > years > of hard work to develop the standard documents and get them stable based > on implementations. > > This is the reason why IESG is usually keen of using already existing IETF > technologies instead of starting another overlapping work which takes > years > to finalize. > > So, please tell me, what are the hard-reasons for not using an existing > technology? > > Cheers, > Mehmet Ersue > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Margaret >> Wasserman >> Sent: Wednesday, February 06, 2008 4:29 PM >> To: Romascanu, Dan (Dan) >> Cc: ops-dir@ietf.org; ops-area@ietf.org; netconf@ops.ietf.org >> Subject: Re: [PEPPERMINT] potenntial charter for PEPPERMINT >> >> >> By "NETCFG", does Richard mean NETCONF? >> >> I would prefer to see the line removed that states that "bias >> will be >> given" to particular solutions. I think it is okay to charter a >> group with restrictions on the solution space, such as "will >> be based >> on XML" if there is consensus to do so, but I'm not sure what it >> would mean to charter a group and require that they be "biased" >> towards certain solutions. If there isn't consensus that the >> solution must be based on one of the technologies listed, I think >> that line should be removed and the choice of technology should be a >> group consensus decision. >> >> Margaret >> >> >> >> On Feb 6, 2008, at 5:30 AM, Romascanu, Dan (Dan) wrote: >> >> > >> > Comments are welcome. >> > >> > Dan >> > >> > >> > >> > >> > -----Original Message----- >> > From: peppermint-bounces@ietf.org >> [mailto:peppermint-bounces@ietf.org] >> > On Behalf Of Richard Shockey >> > Sent: Wednesday, February 06, 2008 2:06 AM >> > To: PEPPERMINT@ietf.org >> > Subject: [PEPPERMINT] potenntial charter for PEPPERMINT >> > >> > >> > Folks ..we had a successful BOF in Vancouver in order to >> progress the >> > work towards a full charter by the IETF it is necessary to reach >> > consensus on a charter. >> > >> > I have a proposal for a charter here below. I welcome >> comments public >> > private etc. >> > >> > >> > PROPOSED CHARTER FOR PEPPERMINT >> > >> > The IETF has been working on various aspects of Multi-Media >> > Interconnection among administrative domains. >> > >> > ENUM is specifically chartered to develop protocols that involve the >> > translation of E.164 numbers to URI's. >> > >> > SPEERMINT has been chartered to develop best current practices among >> > real-time application service providers and how such services >> > interconnect across administrative boundaries. >> > >> > These forms of interconnection will require various forms of data >> > to be >> > exchanged among administrative domains outside the normal scope of >> > establishing various SIP sessions. >> > >> > The IETF has, in the past done, significant work on data exchanges >> > among >> > various network elements. PROVREG and NETCFG being the most >> prominent >> > recent examples. >> > >> > Data exchanges to facilitate Multi-Media Interconnection >> are typically >> > between various Client User Agents and Registries containing >> > mappings of >> > phone numbers to URI's, policies surrounding admission to points of >> > network interconnection and various types of trunking data. In >> > addition >> > there is a specific need for redistribution of Registry data to >> > various >> > types of network databases. >> > >> > The proposed PEPPERMINT working group will build upon the >> knowledge >> > and >> > expertise of the PROVREG, ENUM and SPEERMINT working groups. The >> > goal of >> > the WG is to find a provisioning solution for interconnection to be >> > ultimately used by SPEERMINT. The working group may also reuse >> > elements >> > of RFC 4114 if possible. >> > >> > The final work product(s) from this working group will be based upon >> > XML. >> > >> > Additionally, bias will be given to using, HTTP/REST, >> HTTP/XML-RPC, or >> > HTTP/SOAP. >> > >> > The working group will draw upon expert advice and ongoing >> > consultation >> > from the ENUM, SPEERMINT and PROVREG working groups. >> > >> > >> > PROPOSED GOALS AND MILESTONES >> > >> > >> > Requirements for Interconnection data exchanges. July 08 >> > >> > Provisioning of Interconnection data registries. Sep 08 >> > >> > Provisioning of Interconnection data caches. Dec 08 >> > >> > >> > Richard Shockey >> > Director, Member of the Technical Staff >> > NeuStar >> > 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 >> > 571.434.5651 >> > PSTN Mobile: +1 703.593.2683 >> > >> > >> > >> > >> > >> > _______________________________________________ >> > PEPPERMINT mailing list >> > PEPPERMINT@ietf.org >> > http://www.ietf.org/mailman/listinfo/peppermint >> > >> > -- >> > to unsubscribe send a message to netconf-request@ops.ietf.org with >> > the word 'unsubscribe' in a single line as the message text body. >> > archive: >> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> > > > > > Lesen Sie Ihre E-Mails jetzt einfach von unterwegs. > www.yahoo.de/go_______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > http://www.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org http://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Sun Feb 10 10:01:46 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0113A6883; Sun, 10 Feb 2008 10:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOwczwHUfn25; Sun, 10 Feb 2008 10:01:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DEC3A67F2; Sun, 10 Feb 2008 10:01:45 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7ECE3A67D8; Sun, 10 Feb 2008 10:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VutoCfH1obHr; Sun, 10 Feb 2008 10:01:43 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id F15D33A67F2; Sun, 10 Feb 2008 10:01:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,330,1199682000"; d="scan'208";a="91852299" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Feb 2008 13:03:07 -0500 X-IronPort-AV: E=Sophos;i="4.25,330,1199682000"; d="scan'208";a="160472216" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Feb 2008 13:03:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Feb 2008 19:02:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] 2nd pass on PEPPERMINT charter. Thread-Index: Achpw30HOkC5ekpTQr6h+vtfhi9wyQCS1kvA From: "Romascanu, Dan (Dan)" To: , , Subject: [OPS-AREA] FW: [PEPPERMINT] 2nd pass on PEPPERMINT charter. X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Please see the second pass of the PEPPERMINT charter. Some of the changes are in response to issues raised by the OPS area community. Dan -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, February 07, 2008 10:10 PM To: PEPPERMINT@ietf.org Cc: 'Peterson, Jon' Subject: [PEPPERMINT] 2nd pass on PEPPERMINT charter. PROPOSED CHARTER FOR PEPPERMINT The IETF has been working on various aspects of session-based Multimedia Interconnection among administrative domains. In addition, the IETF has done significant work on data exchanges among various network elements. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across administrative boundaries. The PEPPERMINT work group is charted to define what data needs to be exchanged among Multimedia administrative domains and how that data should be structured provisioned and propagated. These protocols would be outside the normal scope of establishing various forms of a SIP session. Data exchanges to facilitate session-based Multimedia Interconnection are typically between various Client User Agents and Registries containing mappings of phone numbers to URIs, policies surrounding admission to various points of network interconnection and various types of trunk data. In addition, there is a specific need for redistribution of such Registry data to various types of network databases. The working group will draw upon expert advice and ongoing consultation from the ENUM, SPEERMINT and PROVREG working groups. The working group may also reuse elements of RFC 4114, if possible. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. PROPOSED GOALS AND MILESTONES Requirements for Interconnection data exchanges. Sept 08 Provisioning of Interconnection data registries. Nov 08 Provisioning of Interconnection data caches. Feb 09 Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org http://www.ietf.org/mailman/listinfo/peppermint _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org http://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Feb 11 00:17:21 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707283A6AB9; Mon, 11 Feb 2008 00:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.975 X-Spam-Level: X-Spam-Status: No, score=0.975 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gQZ32gAG5MY; Mon, 11 Feb 2008 00:17:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7FE3A6AC4; Mon, 11 Feb 2008 00:17:19 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E6D3A685F; Mon, 11 Feb 2008 00:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnw099tc8Dzd; Mon, 11 Feb 2008 00:17:17 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 72D0B3A6808; Mon, 11 Feb 2008 00:17:17 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1B8Igpw027296; Mon, 11 Feb 2008 03:18:42 -0500 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1B8IfM5027293; Mon, 11 Feb 2008 03:18:41 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 03:18:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Feb 2008 03:18:40 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F0277F329@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expressing SNMP SMI Datatypes in XML Schema Definition Language draft submitted Thread-Index: AchshrU9Eh9mtU+dQEyJvMbrsqa/2w== From: "Natale, Bob" To: , X-OriginalArrivalTime: 11 Feb 2008 08:18:41.0830 (UTC) FILETIME=[B6336C60:01C86C86] Cc: ops-area@ietf.org Subject: [OPS-AREA] Expressing SNMP SMI Datatypes in XML Schema Definition Language draft submitted X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1982731518==" Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org This is a multi-part message in MIME format. --===============1982731518== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86C86.B5CE20E5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86C86.B5CE20E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have submitted "Expressing SNMP SMI Datatypes in XML Schema Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt, via the Internet-Drafts submission tool, but had to do it via a "manual entry" due to administrative complications. Manual submissions can take up two business days to process. =20 In the meantime, I have posted a copy at http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi-datatypes-in-x sd-00.txt. =20 For those who might want to review the slides I presented at the Vancouver IETF for background info, you can get them at http://home.comcast.net/~bobnatale/Converting_SNMP_MIBs_to_XML_via_XSD. ppt. The I-D has updated wording relative to the slides. Slide 7 helps to narrow the focus of the current effort relative to the original MIB2RMDL scope on slide 6. =20 Apologies for cross-posting to the ops-area list -- this is an "Ops Area WG" and "MIB2RMDL" item, but just wanted to be sure to alert all interested parties without going too far afield. =20 Cheers, BobN =20 =20 ------_=_NextPart_001_01C86C86.B5CE20E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I=20 have submitted "Expressing SNMP SMI Datatypes in XML Schema = Definition=20 Language", draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt, via the=20 Internet-Drafts submission tool, but had to do it via a "manual entry" = due to=20 administrative complications.  Manual submissions can take up two = business=20 days to process.
 
In=20 the meantime, I have posted a copy at http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi= -datatypes-in-xsd-00.txt.
 
For=20 those who might want to review the slides I presented at the Vancouver = IETF for=20 background info, you can get them at http://home.comcast.net/~bobnatale/Converting_SNMP_MIBs_to_XML= _via_XSD.ppt. =20 The I-D has updated wording relative to the slides.  = Slide 7=20 helps to narrow the focus of the current effort relative to the original = MIB2RMDL scope on slide 6.
 
Apologies for cross-posting to the ops-area = list --=20 this is an "Ops Area WG" and "MIB2RMDL" item, but just wanted to be sure = to=20 alert all interested parties without going too far = afield.
 
Cheers,
BobN
 
 
------_=_NextPart_001_01C86C86.B5CE20E5-- --===============1982731518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org http://www.ietf.org/mailman/listinfo/ops-area --===============1982731518==-- From ops-area-bounces@ietf.org Tue Feb 12 06:30:42 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF9D28C32C; Tue, 12 Feb 2008 06:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPSKl-ZpZitn; Tue, 12 Feb 2008 06:30:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0671C28C292; Tue, 12 Feb 2008 06:30:42 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6B228C2BA for ; Tue, 12 Feb 2008 06:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjF4sJPgwOn7 for ; Tue, 12 Feb 2008 06:30:40 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 20C1B28C10D for ; Tue, 12 Feb 2008 06:30:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,340,1199682000"; d="scan'208";a="99071263" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 12 Feb 2008 09:32:03 -0500 X-IronPort-AV: E=Sophos;i="4.25,340,1199682000"; d="scan'208";a="161277610" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Feb 2008 09:32:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 15:31:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPSAREA meeting in Philadelphia Thread-Index: Achtg/iWDqlBBmkZTs2/JivZ5aIa5g== From: "Romascanu, Dan (Dan)" To: Subject: [OPS-AREA] OPSAREA meeting in Philadelphia X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org We will be holding a OPSAREA meeting in Philadelphia. We requested a 2.5 hours slot, but due to scheduling problems we may get only a 2-hour slot. The plan is to spend most of the time discussing NETCONF Data Modeling Language proposals, and compare them with reference to the requirements defined by the design teams. However, this is the good time to suggest other items for the agenda. Based on the proposed items we shall post a preliminary agenda in a few days. Dan and Ron _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org http://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Feb 13 08:32:16 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0255228C88C; Wed, 13 Feb 2008 08:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eb8A5YjxuK1; Wed, 13 Feb 2008 08:32:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FF728C86F; Wed, 13 Feb 2008 08:32:15 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D3528C7AC for ; Wed, 13 Feb 2008 08:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXqTd9dcE5sD for ; Wed, 13 Feb 2008 08:32:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AD64428C82F for ; Wed, 13 Feb 2008 08:32:12 -0800 (PST) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id D88E48AFA9; Wed, 13 Feb 2008 17:33:34 +0100 (CET) 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 10601-06-27; Wed, 13 Feb 2008 17:33:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2A828B06C; Wed, 13 Feb 2008 17:21:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 672A54B09E3; Wed, 13 Feb 2008 17:21:53 +0100 (CET) Date: Wed, 13 Feb 2008 17:21:53 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080213162152.GA628@elstar.local> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: Vladislav Marinov , ops-area@ietf.org Subject: Re: [OPS-AREA] OPSAREA meeting in Philadelphia X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org On Tue, Feb 12, 2008 at 03:31:35PM +0100, Romascanu, Dan (Dan) wrote: > We will be holding a OPSAREA meeting in Philadelphia. We requested a 2.5 > hours slot, but due to scheduling problems we may get only a 2-hour > slot. The plan is to spend most of the time discussing NETCONF Data > Modeling Language proposals, and compare them with reference to the > requirements defined by the design teams. However, this is the good time > to suggest other items for the agenda. Based on the proposed items we > shall post a preliminary agenda in a few days. We have submitted an updated version of the SNMP to SYSLOG mapping: http://www.ietf.org/internet-drafts/draft-marinov-syslog-snmp-01.txt If there is time (say 5-10 minutes), I can give a brief overview and then we can poll whether there is any interest to work on this in the IETF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org http://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Feb 27 04:56:18 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659F63A6A39; Wed, 27 Feb 2008 04:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.794 X-Spam-Level: X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoH64EXW-Ojj; Wed, 27 Feb 2008 04:56:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED1F3A6A1E; Wed, 27 Feb 2008 04:56:12 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632103A6A1E; Wed, 27 Feb 2008 04:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ic-BsjEZoP23; Wed, 27 Feb 2008 04:56:06 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 5E9B73A6828; Wed, 27 Feb 2008 04:56:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,413,1199682000"; d="scan'208";a="108588896" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 27 Feb 2008 07:55:59 -0500 X-IronPort-AV: E=Sophos;i="4.25,413,1199682000"; d="scan'208";a="160939986" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 27 Feb 2008 07:55:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 13:55:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Internationalized Domain Name (idn) Thread-Index: Ach4pKtFcGxIWVk+Rk+F6QdWeYZ3hQAm0FhA From: "Romascanu, Dan (Dan)" To: , , "dns directorate" Subject: [OPS-AREA] FW: WG Review: Internationalized Domain Name (idn) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Please send me or directly to the IESG list any comments or concerns. Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf Of The IESG Sent: Tuesday, February 26, 2008 8:00 PM To: new-work@ietf.org Subject: WG Review: Internationalized Domain Name (idn) A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by March 4, 2008. Internationalized Domain Name (idn) ============================= Last modified: 2008-02-18 Current Status: Proposed Working Group Chair(s): TBD Applications Area Directors: Lisa Dusseault (ldusseault@commerce.net) Chris Newman (Chris.Newman@sun.com) Applications Area Advisor: Lisa Dusseault (ldusseault@commerce.net) Mailing List: General Discussion: idna-update@alvestrand.no To Subscribe: http://www.alvestrand.no/mailman/listinfo/idna-update Archive: http://www.alvestrand.no/pipermail/idna-update/ Description: The original Internationalized Domain Name (IDN) WG set the requirements for international characters in domain names in RFC 3454, RFC3490, RFC3491 and RFC3492 in 2002. These documents were tied to Unicode version 3.2 and an update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown a number of real or perceived defects or inadequacies with the protocol. Some of them are described in an IAB review (RFC4690), which also provides a good introduction to the subject matter. IDNA is currently tied to an obsolete version of Unicode. This WG is chartered to untie IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts would be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time, vs. at resolution time - Revise bi-directional algorithms to produce a deterministic answer whether a label is allowed or not - Determine whether bi-directional algorithm should allow additional mnemonics labels - Permit effective use of some scripts that were inadvertently excluded by the original protocols. The constraints of the original IDN WG still apply, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name. The basic approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The WG will work to ensure practical stability of the validity algorithms for IDNs (whether based on character properties or inclusion/exclusion lists). The work is currently organized into four deliverables, all Standards Track. The WG will verify that it has consensus to adopt the proposed documents as a starting point. The Overview document with explanation and rationale is intended for Standards Track status because it has definitions and other normative text required by the other documents. The protocol specification explains how to map non-ASCII characters into ASCII DNS labels. It relies normatively on two other documents that are separate for readability: the bidirectional algorithm specification and the character validity tables. The validity of characters in IDNs is almost exclusively based on Unicode properties but is organized as tables and categories for readability. Goals and milestones: Mar 08: WG Last Call for Overview/Rationale document Apr 08: Revised Overview/Rationale document Apr 08: WG Last Call for Protocol, Bidi and Tables documents May 08: Revised Protocol, Bidi and Tables documents May 08: Review Overview document again if needed Jul 08: Request for publication for all documents Documents: http://tools.ietf.org/html/draft-klensin-idnabis-issues http://tools.ietf.org/html/draft-klensin-idnabis-protocol http://tools.ietf.org/html/draft-faltstrom-idnabis-tables http://tools.ietf.org/html/draft-alvestrand-idna-bidi _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Feb 27 07:18:05 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28C63A6E18; Wed, 27 Feb 2008 07:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etaEgn+3b5qG; Wed, 27 Feb 2008 07:18:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC3528C6F7; Wed, 27 Feb 2008 07:17:57 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48FE28C291; Wed, 27 Feb 2008 07:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgLt2QvX1L4M; Wed, 27 Feb 2008 07:17:54 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7EEF53A6D6D; Wed, 27 Feb 2008 07:17:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,413,1199682000"; d="scan'208";a="94427179" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Feb 2008 10:17:31 -0500 X-IronPort-AV: E=Sophos;i="4.25,413,1199682000"; d="scan'208";a="168146019" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Feb 2008 10:17:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 16:17:17 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] OPSAREA meeting in Philadelphia Thread-Index: Achtg/iWDqlBBmkZTs2/JivZ5aIa5gLzqk8Q References: From: "Romascanu, Dan (Dan)" To: Cc: NGO Subject: Re: [OPS-AREA] OPSAREA meeting in Philadelphia X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org An update on this: 1. We have two hours allocated for the meeting - Wednesday 3/12 1300-1500 2. Please submit all requests for DML solutions presentations to me until tomorrow 2/28 COB. I think that I know what to expect but I need to have a committed confirmation and the name of presenters. 3. Please submit all other request for agenda items until tomorrow 2/28 COB I will post a preliminary agenda by Friday based on what I will receive until then. Dan > -----Original Message----- > From: ops-area-bounces@ietf.org > [mailto:ops-area-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Tuesday, February 12, 2008 4:32 PM > To: ops-area@ietf.org > Subject: [OPS-AREA] OPSAREA meeting in Philadelphia > > We will be holding a OPSAREA meeting in Philadelphia. We > requested a 2.5 hours slot, but due to scheduling problems we > may get only a 2-hour slot. The plan is to spend most of the > time discussing NETCONF Data Modeling Language proposals, and > compare them with reference to the requirements defined by > the design teams. However, this is the good time to suggest > other items for the agenda. Based on the proposed items we > shall post a preliminary agenda in a few days. > > Dan and Ron > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > http://www.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Feb 27 09:49:08 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E543A6C48; Wed, 27 Feb 2008 09:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFlrwWqELGpr; Wed, 27 Feb 2008 09:49:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98723A6A1D; Wed, 27 Feb 2008 09:49:06 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345143A6AF2 for ; Wed, 27 Feb 2008 09:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmX3H955L3fs for ; Wed, 27 Feb 2008 09:49:00 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id BEBD43A6B94 for ; Wed, 27 Feb 2008 09:49:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,414,1199682000"; d="scan'208";a="108661448" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 27 Feb 2008 12:48:53 -0500 X-IronPort-AV: E=Sophos;i="4.25,414,1199682000"; d="scan'208";a="161073539" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 27 Feb 2008 12:48:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 18:48:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Timing over IP Connection and Transfer of Clock (tictoc) Thread-Index: Ach5YG2yyibPUvyaTrClXnFlxD3DcAACGtGA From: "Romascanu, Dan (Dan)" To: , Subject: [OPS-AREA] FW: WG Review: Timing over IP Connection and Transfer of Clock (tictoc) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Please let me know if there are any questions or concerns or send these directly to the IESG list until 3/5 the latest. Thanks and Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Wednesday, February 27, 2008 6:39 PM To: IETF Announcement list Cc: tictoc@ietf.org Subject: WG Review: Timing over IP Connection and Transfer of Clock (tictoc) A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by March 5, 2008. Timing over IP Connection and Transfer of Clock (tictoc) ======================================================== Last Modified: 2008-02-12 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Mailing list: General Discussion: https://www1.ietf.org/mailman/listinfo/tictoc To Subscribe: TICTOC-request@ietf.org In Body: subscribe your_email_address Archive: http://www1.ietf.org/mail-archive/web/tictoc Description of Working Group: The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is concerned with highly accurate time and frequency distribution over native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While this need arises from a variety of sources (see draft-bryant-tictoc-probstat-01.txt), the application areas of focus for this WG are: (1) Network infrastructures with the need for highly accurate time and frequency distribution within well-engineered service provider or enterprise campus networks. On-path support with specialized hardware may be expected to be available at one or more hops on a given path. (2) Individual hosts and devices on the public Internet requiring functionality or performance not currently available in NTP. On-path support may be utilized if available, but is not expected. This application brings additional requirements beyond improved accuracy, for example, the traceable and authenticated distribution of UTC time, including correct handling of leap seconds. The NTP Working Group is currently standardizing the fourth version of NTP for time distribution over IP networks. The NTP WG has focused its deliverables largely on standardizing the currently deployed NTPv4, while collecting requirements for future extensions. These requirements will transition to the tictoc WG for further development. Meeting those requirements may include revision of the protocol to a new version level. However, in all cases backwards compatibility and coexistence with currently deployed NTPv4 is a paramount concern. An applicability statement will describe the use cases for which any extension of NTP is targeted. The IEEE Test and Measurement Society is in the closing stages of standardizing a second version of IEEE1588. This is unofficially known as IEEE1588v2 and is expected to be published as IEEE1588-2008. IEEE1588v2 is emerging as a viable solution for time transfer over service provider and campus Ethernet networks, and for which on-path hardware support is becoming available. IEEE1588v2 specifically encourages other standards organizations to adapt it to their requirements, and provides guidelines for doing so. TICTOC will determine whether a profile for IEEE1588v2 over IP or MPLS-enabled IP networks would be suitable for (1), and if so will produce a profile within the guidelines provided in the IEEE1588v2 specification. An applicability statement will describe the use cases for which any profile of IEEE1588v2 is targeted. Time and Frequency distribution is considered by many to be a complex and often esoteric subject area. The WG will develop a modular framework in order to map out components within the solution space, define terminology, and identify common areas of protocol work that can be capitalized upon. TICTOC will also consider the co-existence of IEEE1588v2 and NTP in the same network. In doing so, TICTOC will first verify that the data model of NTP can be accommodated by IEEE1588v2 protocol operation and document any deficiencies compared to NTP. If there is a need to map the data models, it will produce a specification for how to utilize IEEE 1588 in a localized region as one portion of an NTP-based system. TICTOC protocols will be applicable to a variety of link layer technologies. To get the highest quality time and frequency transfer the user should take advantage of two types of on-path service where they are available: Link based frequency transfer, and hop-by-hop delay correction (for time). Examples of link based frequency support are SONET/SDH, TDM, Synchronous Ethernet and DSL with timing reference support. The main types of support that can be provided by a network element are boundary clock (where the clock is regenerated at the node in a multistage master slave relationship) and transparent clock where corrections are applied to time transfer packets as they pass through to compensate for the queuing delay, and where known for asymmetry in the link delay. Transparent clock (queue delay correction) requires routers to identify a time transfer packet, record the queuing delay, and either apply an on the fly correction to the packet, or to generate a follow-up packet with the necessary time correction information. TICTOC will ensure that any transparent clock design is acceptable in an Internet environment. On-path support is not a given, and TICTOC will investigate methods for automatically discovering when this support is available and when it is not. TICTOC will transfer time and frequency over both IP and IP enabled MPLS PSNs. One of the major users of TICTOC technology is the service provider community, where MPLS enabled IP networks are common. If necessary, TICTOC may take advantage of the path control properties of MPLS and the ability to signal modifications to per packet forwarding behavior. The security of time transfer, including the authentication of the time reference is an important consideration and must be designed in from the beginning. The ultimate system-level accuracy of time and frequency transfer depends on a number of factors outside the scope of the protocols themselves. Thus, even if it is possible for TICTOC to make a number of improvements at the protocol level to facilitate more accurate time and frequency transfer, it is impossible for the WG to provide system-level accuracy guarantees on its own. The TICTOC WG will co-ordinate with the PWE3 and NTP WGs in the IETF, as well as IEEE1588, IEEE 802.1AS and ITU-T SG15 Q13. It is also expected that active individuals in the TICTOC WG will propose the formation of an IRTF RG to study more advanced aspects of time and frequency distribution. First phase Objectives: - To develop a time and frequency distribution requirements document for the two cases listed above, including coexistence of the two as appropriate. - To develop a document defining the modular breakdown of functionality within the solution space. - To determine the extent to which these requirements can be satisfied using IEEE1588v2 and NTPv4 within each use case, along with an associated gap analysis for what requirements are not met without adaptation or extension of these protocols. - To develop an IEEE1588v2 profile as necessary for time and frequency distribution, with primary focus on (1). This profile will include a MIB module for IEEE1588v2. - To develop extensions to NTPv4 as necessary for time and frequency distribution, with primary focus on (2). - If required, to develop mechanisms for coexistence of IEEE1588v2 and NTP. - To document threat analyses and security mechanisms for all protocols developed by the WG. - To document media mappings for link layer technologies of interest. Second phase Objectives (requiring re-charter of the WG): To propose and document algorithms, protocols and mechanisms for transport, frequency acquisition, ranging, and packet selection/discard, master clock selection, path selection, OAM, synchronization status messaging, performance monitoring, security, and network management. Goals and Milestones: Dates are for documents exiting WG last call, and entering "Publication Requested" with the shepherding Area Director. September 08 - Problem statement November 08 - Modular Framework documentation January 09 - Requirements analysis for use cases, including gap analysis for NTPv4 and 1588v2 April 09 - 1588v2 profile, if needed April 09 - NTPv4 extensions, if needed April 09 - Security document(s) August 09 - MIB for IEEE 1588v2 profile and NTPv4 extensions (TICTOC MIB) August 09 - Prioritize second phase deliverables and add milestones or re-charter Internet Drafts 1. Problem Statement draft-bryant-tictoc-probstat-01.txt 2. Modularization Draft draft-stein-tictoc-modules-00.txt 3. Framework Draft draft-frost-packet-timing-framework-00.txt 4. RAN Synchronization Requirements draft-zhou-tictoc-ran-sync-req-00.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Feb 29 01:14:53 2008 Return-Path: X-Original-To: ietfarch-ops-area-archive@core3.amsl.com Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9E528C882; Fri, 29 Feb 2008 01:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=-3.449, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI88t41cczdE; Fri, 29 Feb 2008 01:14:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076EC28C21E; Fri, 29 Feb 2008 01:14:48 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D7E28C320; Fri, 29 Feb 2008 01:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5gFTLbMFaFs; Fri, 29 Feb 2008 01:14:45 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) by core3.amsl.com (Postfix) with ESMTP id 4C21A28C3A6; Fri, 29 Feb 2008 01:14:45 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 0F48876F77; Fri, 29 Feb 2008 10:14:37 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id F0E5E76F4F; Fri, 29 Feb 2008 10:14:36 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA Date: Fri, 29 Feb 2008 10:14:27 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Cc: tf-emc2@terena.org, mobility@terena.org, GN2-JRA5 Subject: [OPS-AREA] Discussion about Federated Roaming X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1310682449==" Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org --===============1310682449== Content-Type: multipart/signed; boundary="nextPart12680601.yoertAlbvm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart12680601.yoertAlbvm Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello! My name is Stefan Winter of the National Research and Education Network in= =20 Luxembourg, RESTENA. We are an ISP for academia and take the lead in resear= ch=20 and development of a global academic wireless LAN federated roaming=20 consortium: "eduroam". This is based on EAP and 802.1X exclusively. In the course of development, prototyping and rollout of eduroam, we have=20 discovered that some areas of the relevant standards required some tweaking= =20 or workarounds. After following IETF work for some time, we also saw that=20 some of the efforts exclude roaming use cases from their agenda. So far I've heard that we are by far the biggest federated 802.1X roaming=20 consortium at all, and I wonder if we are the only ones seeing some items=20 that could use a second thought when considering roaming between independen= t=20 administrative domains. I will be at IETF71, and would like to invite anyone who is interested in=20 federated roaming scenarios for an informal get-together to exchange ideas.= I=20 was planning to do this on Monday evening, at a location that is still TBD,= =20 I'll follow up.=20 Below I've put together the most prominent items that are on our radar righ= t=20 now to give you a glimpse of the issues we in eduroam are dealing with. The most prominent issue is the uneasy fact that RADIUS doesn't provide a=20 reliable transport and only basic security, while Diameter has no=20 implementations and NAS support in the wireless LAN area. With an EAP=20 conversation requiring multiple, usually around eight, roundtrips, and a=20 packet path that may literally span the whole world, this is a major concer= n.=20 It also didn't particularly help that in a recent discussion on dime, it wa= s=20 stated that Diameter doesn't offer significant advances regarding roaming=20 compared to RADIUS.=20 We tried to mitigate this by proposing RadSec, RADIUS over TCP+TLS [1], and= =20 are pursuing this in the radext wg right now. Another thing is that we have no sufficient signalling mechanism to reach t= he=20 end user if the 802.1X login couldn't be completed because of an intermedia= ry=20 RADIUS proxy being down - due to the lack of possibility to provide error=20 messages in the 802.1X protocol, most supplicants provide the unhelpful=20 advice that "Probably the password is wrong", which is wrong and generates= =20 user frustration. Some kind of "hijacking" the EAP conversation by the last= =20 responsive proxy to inject EAP-Notifications would be needed probably, but= =20 this is not thought through in its entirety yet. I'm aware that there is a= =20 security argument: not disclosing the reason for a failure may make attacks= =20 more difficult, but still: it would then be desirable to at least have the= =20 *option* of providing the info - right now it is impossible. Then, encapsulating EAP in RADIUS may sometimes lead to RADIUS packets bein= g=20 so big that they have to be fragmented - not a conceptual problem, but a=20 practical one, because out-of-order fragements, or even even in-order UDP=20 fragments generate problems on unclever firewalls more often than not.=20 Especially EAP-TLS, where both server and supplicant need to send large=20 amounts of (certificate) data turned out to be a real challenge. A draft=20 about that problem and a sketch of a possible solution is in the works. Another thing that bugged us about RADIUS is the inability to contact new a= uth=20 servers "on the fly", for example when a new user realm is observed. So far= ,=20 we stacked together RADIUS servers in a realm-based aggregation hierarchy. = A=20 better approach, in combination with the TCP+TLS nature of RadSec, would be= =20 to use a dynamic lookup mechanism (e.g. DNS NAPTR/SRV) that allows to=20 discover the authoritative home server for a user's realm and to verify tha= t=20 server's eligibility by examining the certificate. This is a concept we wil= l=20 try out in semi-production use in eduroam soon, but it may have implication= s=20 also out of the eduroam community, since it will allow arbitrary service=20 providers to create an authentication fabric very easily on the technical=20 side - making the *paperwork* of bootstrapping a roaming consortium the onl= y=20 big challenge. We have been looking at the work of the NEA wg with a bit of concern, since= =20 its charter excludes the federated roaming case deliberately. For example,= =20 putting posture information into EAP will always convey the posture info to= =20 the home server, while it is the service provider that needs the posture=20 information to make its admission decision. We understand though that there= =20 is work going on to make the use of NEA roaming-agnostic, which we would ve= ry=20 much like to see. =46inally, there is a more exotic area in connection to roaming scenarios:= =20 converging roaming on the network layer (802.1X+EAP) with Single-Sign On on= =20 the application layer (SAML et al), with the ultimate goal that using a set= =20 of credentials to log into the network also generates an application layer= =20 token to use for signing into services - without the need to re-authenticat= e. I realise that some of the points above may not fit perfectly into the IETF= =20 scope, either interfacing downwards to layer 2 and IEEE work (EAPoL) or=20 upwards to the application layer. Still, these are points not tackled=20 sufficiently so far and they at least have partial relevance to the IETF=20 work, so I hope that there are some folks out there to discuss this over a= =20 beer or two, in a "bar BoF" style. Greetings, Stefan Winter [1] http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt =2D-=20 Stefan WINTER RESTENA Foundation - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education = Nationale et de=20 la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0=C2=A0+352= 424409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax:= =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart12680601.yoertAlbvm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHx8z8+jm90f8eFWYRAkTVAJ99V8SRcE6lDHgpZmPSQlSiYo9ppACfWycg h6rWQVMlqp8NJhif35NH4y8= =jWtc -----END PGP SIGNATURE----- --nextPart12680601.yoertAlbvm-- --===============1310682449== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area --===============1310682449==--